Patches / a proposal for the mystic DIB engine
r.kalbermatter at hccnet.nl
Thu Apr 12 09:04:21 CDT 2007
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
> 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
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
DIB_Status_AppMod (DIBDRV_ALWAYS), or DIB_Status_AppMod if the DIB is
The return value would someow indicate to that driver function if it should
simply return with a failure leaving the rest to GDI32 to deal with or do
time being the actual work as it does now.
GDI32 would on driver failure (or non-existing driver function) invoke the
DIBDRV function for non-meta DCs. A non-existing driver function would still
thanks to the exception handling for DIBs being accessed in application
it is not the preferd way to deal with this until the DIB engine is fully
(and the DIB handling could then be consequently removed from x11drv
This would reduce the modifications to x11drv to a minimum and also GDI32
need much changes at all. Adding a new DIBDRV function would be a change in
to add the DIBDRV call on failure of the driver function and then switching
DIB_Status value in that driver function to DIB_Status_Conf instead of
>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
But there might be another complication with this I haven't seen yet.
More information about the wine-devel