Alex Villacís Lasso escribió:
Alex Villacís Lasso escribió:
Huw Davies escribió:
On Fri, Oct 20, 2006 at 05:49:09PM -0500, Alex Villacís Lasso wrote:
This is the first attempt at a patch that will fix the debug
assertion when icons are rendered into metafiles (triggered by
Enterprise Architect 6.5, and possibly others). This patch simply
removes mentions of memdc, created by a call to
CreateCompatibleDC(), and redirects calls to GetDIBColorTable() to
use the original DC instead of memdc. Intends to fix bug #6439. Now
with patch.
This can't work, since the bitmap needs to be selected into the dc for
GetDIBColorTable to succeed and you're not allow to call GetDIBits
with the bitmap selected into the dc...
Huw.
Please correct me if the details of my understanding are wrong in any
way.
The problem is that in the wine implementation, the palette is *not*
stored anywhere inside the returned HBITMAP from CreateDIBSection().
Instead, the HDC used by CreateDIBSection must implement the
pCreateDIBSection (this already leads to loss of palette information
if it doesn't, for example in enhmfdrv), and then pCreateDIBSection
is called, and somehow associates the HBITMAP with the actual
implementation (in winex11drv, an XContext is used to save the
pointer to a X_PHYSBITMAP, indexed by the HBITMAP). The method of
getting to the palette information given an arbitrary DIB HBITMAP is
private to the driver, and the functions contained in the BITMAPOBJ
structure are not enough - a PHYSDEV is also required, usually
provided by the DC. Million dollar question: what happens in the
current implementation if a DIB created with a reference DC that
saves the palette with method A is used with GetDIBits() and a
reference HDC that expects a PHYSDEV with a different method B of
saving the palette? Also, how do we get the palette information from
GetDIBits() if the reference HDC does not support pGetDIBColorTable()?
Given that, I thought of a few solutions to get the palette
information from a DIB without CreateCompatibleDC():
- Select the HBITMAP into the reference DC inside the implementation
of GetDIBits(), then call GetDIBColorTable() on the reference DC.
Although the HBITMAP should not be selected into the reference DC
before calling GetDIBits(), MSDN says nothing about GetDIBits()
itself selecting the bitmap into the reference DC.
- Add a new field to BITMAPOBJ with the PHYSDEV from the reference
DC. Then, the corresponding function pGetDIBColorTable could be
called with the proper parameters without the need of a new DC.
Palette information is still lost if reference DC of CreateDIBSection
does not support pCreateDIBSection().
- Add a new field to BITMAPOBJ for the sole purpose of storing a copy
of the DIB palette when calling CreateDIBSection(), and use it for
GetDIBits(). Requires synchronization when calling
SetDIBColorTable(), and possibly in other places, and also a rewrite
of GetDIBColorTable(). However, this has the advantage that no
palette information will be lost when creating a DIB section with a
reference DC that does not implement pCreateDIBsection. The best
method IMHO.
What do you think of these suggestions? Any comments are welcome.
Alex Villacís Lasso
Here is a patch that implements option 3 described above.
Changelog:
* Store a copy of the DIB palette when creating a dibsection, and use
it to remove the need to use CreateCompatibleDC() in GetDIBits()
function.
------------------------------------------------------------------------
Any comment on this patch (whether it needs cleaning up or anything else)?
--
The following cryptic message was allegedly found in the inner edge of a Windows
XP installation CD:
4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420
7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074
6865206461726B6E6573732062696E64207468656D2E0A
It is rumored that only a true Unix Wizard can decypher this mysterious message,
which supposedly encodes the true nature and purpose of the software.
