Colour problems with latest DIB fix

[François Gouget]

Gerard Patel wrote:
> 
> At 12:53 PM 29/10/2001 -0800, you wrote:
> 
> >> Anyway, the attached patch is displaying the failing picture correctly.
> >> What do you think ?
> >
> >   If I apply your patch, then I see that the red and blue are exchanged
> >when I run vnc as:
> >   vncserver :1 -geometry 800x600 -depth 16 -pixelformat bgr565
> 
> Could you explain a bit more what you are doing ? I would like to
> try the same but I don't see how to do it.

   I guess you don't know about VNC then. Here's a description of VNC.
VNC is a pretty cool open-source application which lets you access a
computer remotely, kind of like X but different :-) It is composed of
two parts, a server and a client.
   The command above starts an VNC X server. This X server is not using
any graphics card because it is not actually displaying anything. It
just uses a chunk of memory to store the 'screen'. Because of that you
can use about any pixel representation. In the above I specified that I
wanted a 800x600 screen in 16 bits per pixel with the red, green and
blue components in BGR order.
   Once you have this server, you can start the client as 'xvncviewer
:1'. This connects to the above VNC server and creates an 800x600 window
that shows you what is displayed in that X server. The client can be run
on the same computer or on another. Because the client/server protocol
involves exchanging bitmap chunks the client is very simple and can run
on about any platform. So you can access the above VNC server from an
Windows computer if you want. 
   There is also a VNC server for Windows. And this leads to one of the
most interesting applications of VNC: remotely controlling a Windows
computer. From another Windows computer, from any Unix platform, I
believe there's even a client for PalmOS!

   Anyway, by playing with the -depth and -pixelformat options you can
test Wine as if it were running into all sorts of X servers.


> Also, if you use vnc to test, did you consider the possibility that vnc
> could have a bug somewhere ?

   There's always that possibility but the results I get with VNC (based
on XFree 3.3.6) are consistent with those I get from the
neomagic&permedia drivers of XFree 4.1.0.


[...]
> I had (of course) a number of problems with your app.
> First on my current computer - a Mandrake 8, with Xfree 4,
> your procedure ran fine until it tried to link the thing and then it
> reported that WinMain was missing. I changed in your code
> 'main' to 'WinMain' and all was well.

   Sorry about that. By default winemaker assumes that applications are
graphical applications. So it created a .spec file with "mode guiexe"
and "init WinMain" instead of "mode cuiexe" and "init main".


> I tried then to do the same on my other computer (Suse 6.1 with
> Xfree 3.3 and a hand-compiled glibc 2.1.3). No joy. Configure
> always failed with libwine.so failing to find symbols like dlclose
> and the like. I did not figure out what is happening, I just
> copied the binary from my other box and it worked.

   That's strange. It should be investigated...


> As for the results, what I see is 11 lines of 13 blocks of 4 colors :
> black, red, green, blue. I guess that when you speak of red and
> blue exchanged, you mean that in one of these blocks the red
> and blue lines are exchanged, right ?

   Yes. 


> What is strange is that on both of my computers the display
> of your app is the same with or without my patch. No line
> exchanged that I can see.

   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.

   Actually I have a buffer overflow patch to send for the new DIB code.
I don't think it's related but then, who knows. I will try to send it
tomorrow morning.


> >   As for The Sims, if you can also check the -debugmsg +bitmap output
> >and make sure it's coherent.
> 
> I don't have The Sims... I use a little freeware app that is not available
> from the internet anymore, unfortunately :-/.

   Do you think you could send this freeware app to me? Would I be able
to run it without too much trouble?


-- 
François Gouget
fgouget at codeweavers.com