The DIB engine was discussed quite a lot at WineConf. I am now trying to summarize these discussions to update bug 421 - Implement a DIB engine.
http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=421
Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers?
This was discussed quite a bit at WineConf. Ideas that were floated around are:
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).
* Is the needed API already available? * If not, are the XFree86 guys willing to export it? * Almost everyone is using XFree86, but what about people who don't (embedded devices, Wine on Solaris...). We need a fallback. * We won't have to maintain that code which is a good thing, although it is not supposed to change much once written. * Will we be able to do all that we need with that API? Probably yes since it can be expected to match the X API quite closely and we are abel to use the X API.
2. Copy the relevant X code into Wine -------------------------------------
Since X has all the code and that code is under the X11 license we could copy it all into Wine.
* This means we will have to maintain the code ourselves, although it is not supposed to change much once written.
3. Copy the relevant code from MicroWindows/NanoGUI to Wine -----------------------------------------------------------
MicroWindows/NanoGUI also has code that could help us bootstrap our DIB engine. We probably don't want Wine to depend on these projects but we could copy their code into Wine.
* Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written.
4. Copy the relevant code from GGI to Wine ------------------------------------------
GGI also has similar code. Again we probably don't want to introduce a dependency on GGI so the same questions apply:
* Are the licenses compatible? * Do they support all the bit depths and layouts we care about? * This means we will have to maintain the code ourselves, although it is not supposed to change much once written.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".
- 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 :
number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32
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.
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).
Anyway, enough of my ramblings for tonight :-)
Lionel
On Sun, 31 Mar 2002, Lionel Ulmer wrote:
- 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 wrong way.
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 for transparency). * 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 to Wine.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.
On Sat, Mar 30, 2002 at 04:57:09PM -0800, Francois Gouget wrote:
We make use of Shared Memory Pixmaps to reduce the copying (in WineX).. So we have app memory which stores the image in the mode requested by the app, this then gets copied into a SHMPixmap of the depth supported by X so X can do whatever it wants to (render to it or whatever) and it then gets copied back when needed, same method..
One of the big savers here is that the ShmPixmap means we dont have to be sending stuff between X server/client, saves alot of time..
As for X supporting multiple depths - I investigated this and talked to some of the X coders, its still not "wonderfully" supported.. ehm, it lacks alot of the most common modes - eg 8bit paletted - its not really worth it from what I can see.. The X developers suggested that if I wanted to go down this road to first write an X extension, ShmPixmaps were nicer and almost as fast...
Maybe you would have been able to see this if AoE2 didn't crash on Gav ;-).
Cheers David
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 to Wine.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient ? demander si un sous-marin peut nager.
-- David Hammerton Programmer, TransGaming Technologies http://www.transgaming.com/
I don't expect my comments will add much to this discussion because of my lack of coding ablity but this something ReactOS is going to need also.
Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers?
I will help with documentation/testing on this if that is needed.
- Have X export the required API
This wont help ReactOS out but it seems to me this is the quick/easy way to do it for you guys.
- Copy the relevant X code into Wine
I'm kinda like this idea. If this is the road you guys chose we should be able to make use of the code also.
- Copy the relevant code from MicroWindows/NanoGUI to Wine
Microwindows is GPL/MPL so Wine most likely cannot use its code. Greg might relicense some of the code for you though.
Seeing as how DIB support is in use or needed by a lot of projects, why not take the X11 code And make a independent project? One that is licensed under X11 that can then be used By Wine, WineX, ReactOS, Microwindows and anyone else that needs it.
Ok I'll shut up now Steven
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
-
David Hammerton -
Francois Gouget -
Lionel Ulmer -
Steven Edwards