Some thoughts about the ominous DIB Engine

[Damjan Jovanovic]

On 2/9/07, Rolf Kalbermatter <r.kalbermatter at hccnet.nl> wrote:
> I have been following this discussion for quite some time and finally
> decided to look into it a little bit. While the Wiki mentions that a
> difficult part of this would be to get any design accepted by Alexandre it
> does absolutely not say in any way what kind of approach would be likely to
> be accepted, other than it needs to be in small incremental steps.
>
> I must admit that I haven't entirely looked through the whole Wine tree yet
> so I might be missing something but from the old Transgaming patch and some
> investigation into GDI32 I would see two principal aproaches to add such an
> interface to Wine.

Look at bug 3902 (and 421) for some more ideas.

An optimization was suggested to reduce the size of the data copied
between wine and the X server, where an invalid rectangle is
set/cleared by each drawing function and only the contents of that
rectangle (if any) are copied, instead of the entire bitmap. It's not
hard to do, but it isn't an overnight thing either - each and every
drawing function has to be patched to do this for it to work, and
there is a several dozen. Preliminary tests showed some improvements
using this approach. And it would still help even if we had a DIB
engine, because the volume of data copied would still be lower.

My client-side DIB copy patch from bug 3902 was accepted into wine a
few versions back, and it already makes a huge difference for some
applications and games.

> 1) Like in the Transgaming patch hook into winex11.drv where apropriate.
> 2) Add the dib engine as a dibdrv into GDI32 directly similar to what has
>    been done for enhmfdrv and mfdrv already.

> Obviously 1) has been tried and seemed to work in some ways eventhough there
> would still need to be quite some more work to be done. What I don't like
> about this aproach is that conceptually it seems to add this functionality
> at the wrong end. If there is ever going to be another display driver than
> winex11.drv all the hooking would have to be done again and also adding new
> GDI methods to the driver as development goes always requires also some
> significant changes to winex11.drv.
>
> Not sure if someone ever attempted 2) but IMHO it would place DIB handling
> where it conceptually should be. The dibdrv function array could be added as
> extra field to the private DIB data structure and initialized on DIB
> creation. On non existing DIB methods (NULL pointer) the operation would be
> simply sent to the display driver as is done now. I believe this could be
> generalized enough to make it a single time change, with new dibdrv methods
> getting then available whenever implemented in small incremental patches.
>
> Possible problems I could see are however synchronizing with X (not sure if
> that is really a possible problem as I do not understand X so far) and maybe
> other drivers such as wine3d3.drv that seem to hook into winex11.drv too
> (not sure if for DIB related operations).

X synchronization is done in winex11.drv. Calling
X11DRV_LockDIBSection returns where the DIB is, and if it is
client-side, you just draw to it by accessing memory - otherwise you
draw by using equivalent xlib functions.

It would be pointless  and extremely difficult making a dibdrv - just
patch winex11.drv; dibdrv would need access to many internal X11DRV_
functions.

> This last one could however be gotten around by implementing the dibdrv as
> loadable driver too, so that other drivers needing to use operations from it
> could load it too.
>
> I would like to hear comments of anyone that could add something to this and
> maybe we can then add the result to the wiki page for further reference.
>
> As it is now Wiki mostly says it is rather desirable, sort of hard to do and
> the hardest part would be getting it into Wine at all. Maybe if there is a
> more clear picture as to how it could be done and what is likely to have a
> chance to pass Alexandre's critical eyes, there would be a bigger chance of
> someone trying to get it finally started the right way.

The hard part is not the X11 stuff, it is writing drawing algorithms
that not only draw in all of 1, 4, 8, 16, 24, and 32 bit colour-depth
and are pixel-for-pixel equivalent with the way Windows does them, but
the dozens of little things like patterns, brushes, raster ops, custom
region clipping, and others which affect each other and almost
everything else, making the implementation of a client-side DIB engine
a real PITA.

> Rolf Kalbermatter

Damjan Jovanovic