The DIB engine... does anyone know how to get it into Wine?
chris.kcat at gmail.com
Wed Apr 29 04:38:48 CDT 2009
On Wednesday 29 April 2009 1:58:53 am Massimo Del Fedele wrote:
> That's why I've chosen the "new approach". As a new driver it can't
> break anything, so it could (but I guess it won't) be introduced as
> an "alternative" display driver in parallel to winex11.
A problem with it being a separate driver is that the other drivers need to
know how to handle DIBs. If it's in a separate driver, I think that would
break the encapsulation the drivers are supposed to have. Alexendre also
doesn't like the idea of writing in "dead code" that's activated when
finished. It makes regression testing a nightmare.
My idea I've tossed around on IRC a couple times involves something like this:
1) Modify winex11.drv to handle DIBs using XImage, and not rely on Pixmap.
Leave the pixmaps for DDBs. An XImage struct uses a vtable of sorts, so Wine
can specify its own accessor functions, *and* provide the memory space the
image is stored in (client-side).
2) Define a struct that replicates XImage, and put it in gdi32.dll. All
display drivers would know of this struct, so winex11.drv can then use the new
struct with very little change.. just change the XImage types where
appropriate, and wrap the XImage around the DIB as needed (ie. so the new
GDI32 type and the XImage work on the same image data).
3) Move left-over DIB processing from winex11.drv to gdi32.dll. The new
XImage-like struct in GDI32 can then be modified as needed.
That's a rather basic overview, of course.. but the people that've responded
on IRC seem to think it's a good plan of attack.
More information about the wine-devel