x11drv, ntdll separation

[David Hammerton]

Hi,

I wrote some documentation a while back on this when we (TransGaming) 
submitted our dibengine to rewind/winehq.

You can read the docu at:
http://www.winehq.com/hypermail/wine-devel/2002/09/0680.html

Basically its beacuse a DIBSection is like a mixture of a DIB and a HBITMAP, 
in that it has properties of both: The app can write directly to the pixel 
data while also being able to perform GDI operations on it, which we do 
through X. Because of the way X works we therefor have to have two copies of 
the DIBSection hanging around, and be able to sync them when required (eg, if 
the most 'up to date' version is in X, we need to know when the app tries to 
write to / read from the DIB so as we can sync them).

And really - the best way to get rid of it is to finish the DIB engine :)

David

On Sat, 22 Feb 2003 22:36, David Fraser wrote:
> Hi
>
> I was wanting to do some work on x11drv dll separation.
> The last remaining dll separation between x11drv and ntdll is
> VIRTUAL_SetFaultHandler.
> This is called from X11DRV_DIB_CreateDIBSection, where it tries to set
> the fault handler to X11DRV_DIB_FaultHandler, with addr=dm.dmBits and
> arg=res.
>
>  From reading the code it seems that this is done because it is not
> known whether the calling app requires read or write access to the data
> in bmp.  If the app then tries to read or write and doesn't have the
> appropriate access, this will generate an exception which will then
> raise the X11DRV_DIB_FaultHandler which would then set the appropriate
> access, in a way that ensures data gets handled correctly.
>
> I presume I'm misunderstanding this, because looking at MSDN for
> CreateDIBSection, it says:
> The CreateDIBSection function creates a device-independent bitmap (DIB)
> that applications can write to directly.
> and further down...
> Windows NT: You need to guarantee that the GDI subsystem has completed
> any drawing to a bitmap created by CreateDIBSection before you draw to
> the bitmap yourself. Access to the bitmap must be synchronized. Do this
> by calling the GdiFlush function.
>
> So it would seem apps could always be given read-write access to this
> bitmap.
>
> Why is the special fault handler needed? What is the best way to
> approach getting rid of it?
>
> David

-- 
David Hammerton
Programmer
TransGaming Technologies Inc.
david at transgaming.com