[ros-dev] [ros-diffs] [jgardou] 48359: [WIN32K] - Rewrite NtGdiGetDIBitsInternal, with WINE as a reference. - Get back DIB Section creation to classic BITMAPINFO. This si the beginnig of the end for all this BITMAPV5INFO stuff. It is horrible, BITMAPCOREINFO->

[Jérôme Gardou]

Timo Kreuzer wrote:
> Jérôme Gardou schrieb:
>    
>> That's why I began to revert all of this stuff, which is horrible :-)
>>      
> While I completely agree on removing BITMAPCOREHEADER support, I don't
> really like other parts.
>
> - Probing the BITMAPINFO and then passing the usermode buffer to the
> internal and unprotected function is not enough. The buffer must be copied.
>    
OK, it's safer this way.
> - The BITMAPV5HEADER is only ~120 bytes and only used once per function
> call, so putting the safe buffer on the stack is appropriate. The buffer
> needs be large enough for V5 anyway, so why not fixup some values and
> make it a full V5 header?
>    
No, all values added by V4/V5 headers are for ICM. If there is only a 
BITMAPINFOHEADER there, then we don't have to care about ICM. If we 
"convert" it to a V5 header, all values will be 0, that's not worth the 
effort.
> - The ProbeAndConvert function was added to simplify the code and move
> all code that handles the small differences into one central place
> instead of having a bunch of if (size>  bla) checks in multiple places
> just to check whether I can or can not access some member of the
> BITMAPINFO or where to get the color masks from. With the conversion all
> of the internal code can work the same simple way assuming a full
> BITMAPV5INFO is available.
>    
The only "effort" to make here is to take care of where the color buffer 
is : bmi + bmi->bmiHeader.biSize and not bmi->bmiColors. Then check in 
some functions if we have a V4/V5 header to take care of the features 
they have. If we're good enough, we'll just need to call 
DIB_CreateDIBSection, and work with this bitmap created here. That's 
what I did in NtGdiStretchBitmapInternal, NtGdiGetDIBits and 
IntGdiSetDIBits. The major problem is to get the palette created properly.
> - When support for BITMAPCOREHEADER gets removed the code become much
> less "horrible"
>    
Agree.
> Timo
>
>    
Jérôme.