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.