At 01:06 AM 30/10/2001 -0800, you wrote:
<snip lot of explanations>
First thanks for all this stuff, really enlightening.
> This probably means that you have a 16bpp rgb565 screen. Which seems
>normal. It also means that the Dib is a bgr888 Dib which does not exist
>in Windows. So something weird is happening. Here are the interesting
>kind of lines:
>
>trace:bitmap:X11DRV_DIB_SetImageBits Dib: depth=24 r=ff0000 g=ff00 b=ff
>trace:bitmap:X11DRV_DIB_SetImageBits Bmp: depth=16/16 r=f800 g=7e0 b=1f
>
> This tells us that the Dib is a 24bpp dib and that it is an RGB dib,
>the only kind of 24bit DIB in Windows. What tells us that it's an RGB
>DIB is the r,g,b masks: the red color is encoded in the high bits of the
>24bit value: 0xff0000. Then you hace the green, 0xff00, and the blue,
>0xff, hence the rgb888 shorthand.
> Similarly the 'Bmp', i.e. an XImage, is a 16bpp rgb image. Here you
>will notice that the mask for the green color, 0x7e0, uses 6 bits
>instead of just 5. This gives you the rgb565 denomination.
> Finally we are in SetImage so we are converting the Dib into a Bmp,
>i.e. from rgb888 to rgb565 so we will call Convert_888_to_565_asis
>(since both are rgb).
> Now I suspect that with your application the Dib masks don't look
>like the above
Congratulations, you are entirely right.
As in many cases, Wine does not work because it is not tolerant
to strange parameters
Actually the dib masks are all equal to 0. Probably the correct fix
is to assume an 'asis' (not reversed) conversion when the app does
not set any mask.
Gerard