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.
_______________________________________________
Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
