The DIB engine... does anyone know how to get it into Wine?

[Chris Robinson]

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.