Some thoughts about the ominous DIB Engine

Detlef Riekenberg wine.dev at web.de
Fri Feb 9 09:21:56 CST 2007


On Fr, 2007-02-09 at 11:41 +0100, Rolf Kalbermatter wrote:

> 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.

> 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.

I suggest option 2), but without the need of a Display-Driver at all
as the long-term target.
The API for that Engine is exported by GDI32 ("Eng*" ) and when we
implement that, we can reuse the API for more drivers (OpenGL, VNC,
RDP, SDL, Printer-Drivers ...)
The API-declaration for "Eng*" is in "ddk/winddi.h"

A line from the current wine GDI-Engine as Example: 
("LineTo" from dlls/gdi32/painting.c):
---- cut ----
> ret = dc->funcs->pLineTo && dc->funcs->pLineTo(dc->physDev,x,y);
---- cut ----

We simple call the Driver, and when the Driver does not support that
painting-function, the API failed.
On windows, gdi32.dll and the Driver can fallback at any time to
"Eng*" ("EngLineTo" in the Example) and the drawing is split in more
primitive API-calls whith setting a single pixel at the end.
(You can think of a Driver, that implement "LineTo" only for horizontal
and vertical lines and fallback to "EngLineTo" for diagonal lines)

So instead of implementing a full DIB-Engine in a dibdrv, we should
split the implementation in a logical part ("Eng*" API) and a 
drawing part.

> Possible problems I could see are however synchronizing with X (not sure if

I have no Idea, what is needed here.

> 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.

When we use "Eng*", it's there for all drivers and is the same API as in
windows.

Thanks for looking at the dib-issue

-- 
 
By by ... Detlef





More information about the wine-devel mailing list