Patches / a proposal for the mystic DIB engine

[Rolf Kalbermatter]

Felix Nawothnig [mailto:flexo at holycrap.org] 

>Okay, I've spent the last days looking into this matter and I'd like to
>suggest a way to get it started. So. This is the plan:
>
>1. In winex11.drv:
>
>-INT X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL lossy)
>+HBITMAP X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL 
>+force)
>
>    Lossy isn't used anywhere for LockDIBSection anyway. Force means that
>    the function will only lock if the DIB is already in AppMod. The
>    returned bitmap is ofcourse physDev->bitmap->hbitmap.
>
>    Rationale: If you lock the DIB to write on it it makes sense that the
>    function actually provides you with that DIB.

I had actually a bit a different idea but didn't get around to try it yet.
I was thinking about adding an extra value to the DIB section sync state
such
as DIB_Status_Conf. With this X11DRV_DIB_Coerce would decide based on a
configuration setting if it should do DIB_Status_GdiMod (DIBDRV_NEVER in
point 5.),
DIB_Status_AppMod (DIBDRV_ALWAYS), or DIB_Status_AppMod if the DIB is
already in
DIB_Status_AppMod (DIBDRV_MIXED).
The return value would someow indicate to that driver function if it should
just
simply return with a failure leaving the rest to GDI32 to deal with or do
for the
time being the actual work as it does now.

GDI32 would on driver failure (or non-existing driver function) invoke the
according
DIBDRV function for non-meta DCs. A non-existing driver function would still
work
thanks to the exception handling for DIBs being accessed in application
mode, although
it is not the preferd way to deal with this until the DIB engine is fully
functional
(and the DIB handling could then be consequently removed from x11drv
entirely).

This would reduce the modifications to x11drv to a minimum and also GDI32
wouldn't
need much changes at all. Adding a new DIBDRV function would be a change in
GDI32
to add the DIBDRV call on failure of the driver function and then switching
the
DIB_Status value in that driver function to DIB_Status_Conf instead of
DIB_Status_GdiMod.

>2. Export LockDIBSection/Unlock to gdi32.
>
>    Adding more exports is not nice but there really is no way around
>    that, right?

That and a lot of the other points wouldn't be necessary with above
approach.

But there might be another complication with this I haven't seen yet.

Rolf Kalbermatter