fgouget at free.fr
Sat Mar 30 18:57:09 CST 2002
On Sun, 31 Mar 2002, Lionel Ulmer wrote:
> > 1. Have X export the required API
> > ---------------------------------
> > XFree86 4 has all the needed code, for all bit depths and layouts we
> > care about. We could try to have the X guys export this in the form of
> > an API ala Xft. Wine could then link with this library to implement the
> > DIB engine (or dlopen that library).
> Well, when I look at the bug report, I see this :
> '* the X bitmap has to be in the format of the X display. So if X is
> running in 15bpp, a 32bpp DIB is converted to 15bpp, the operation is
> performed in 15bpp, and the bitmap is then converted back to 32bpp.
> Obviously this implies that each operation occurs a loss of color
> resolution (fortunately they should not accumulate).'
> This is, AFAIK, not a problem anymore on XFree 4 (at least on the drivers
> based on the 'fb' driver) as they support all Pixmap depth whatever the
> depth of the current screen. For example, on my 16bpp display, 'xdpyinfo'
> gives me this :
Yes but Wine will refuse to create a pixmap in a bit depth other than
that of the X display. So we still incur the loss. Maybe that could be
fixed but last time I played with this X was not happy about getting non
16bpp pixmaps. But I'm not an expert on this and did not have muh time
to play with it so it is entirely possible that I just did things the
> So it should support almost all 'usual' formats (except the funky non 555 /
> 565 formats or BGR ones that are pretty rare). As far as I can remember, my
> Solaris box at work does also support a lot of Pixmap formats even on a
> 32bpp screen. There may be problems with the palette for the 'depth 8'
> format though.
Well, I believe the current code already has issues with this:
* start with a paletized DIB, copy it to X and copy it back. A pixel
which had index 5 initially may end up being index 10 just because both
indexes have the same color. The image should look the same but
the index may be significant for the application (maybe 5 is the code
* copy a DIB to X and change the palette. I am not sure this is handled
very well. Can it even be handled properly? Wouldn't we have to find all
DIBs we have copied to X and update them all?
> But, as far as I can remember, the other big problem comes from the
> 'exception handler' that is needed to detect direct write from the Windows
> program to the DIB (or maybe I am thinking about something completely else
> :-) ) to be sure that the X pixmap and the Windows DIB are always in sync
> one with the other. And that cannot be solved easily with X Pixmaps at all
> (maybe hacking around with XShmPixmaps).
Yes this endless copying is a performance killer. But even if you are
not concerned about performance there are issues as I mentioned above.
I think Transgaming did some work on optimizing this to limit the
number of copies this but I don't remember the details. Some of it is
already in Wine, I don't know if they have more stuff in WineX / coming
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
Demander si un ordinateur peut penser revient à demander
si un sous-marin peut nager.
More information about the wine-devel