30 Mar
2002
30 Mar
'02
11:14 p.m.
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(a)free.fr http://fgouget.free.fr/
"Utilisateur" (nom commun) :
Mot utilisé par les informaticiens en lieu et place d'"idiot".
30 Mar
30 Mar
11:44 p.m.
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 :
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
--
Lionel Ulmer - http://www.bbrox.org/
31 Mar
31 Mar
12:57 a.m.
On Sun, 31 Mar 2002, Lionel Ulmer wrote:
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.
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 : 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(a)free.fr http://fgouget.free.fr/
Demander si un ordinateur peut penser revient à demander
si un sous-marin peut nager.
2:45 a.m.
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
--
David Hammerton
Programmer, TransGaming Technologies
http://www.transgaming.com/
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(a)free.fr http://fgouget.free.fr/
Demander si un ordinateur peut penser revient ? demander
si un sous-marin peut nager. 
12:25 a.m.
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.
1. 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.
2. 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.
3. 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
8070
days inactive
8071
days old
4 comments
4 participants
participants (4)
-
David Hammerton -
Francois Gouget -
Lionel Ulmer -
Steven Edwards