gdi32: Remove call to CreateCompatibleDC() from GetDIBits() implementation (try 1)

[Alex Villací­s Lasso]

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.