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
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(a)transgaming.com
David Hammerton wrote:
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
Hi Thanks very much, this was very clear and I understand it now...
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).
Seems to make sense except that I still have one question: the MSDN docs seem to indicate that you need to call GDIFlush() before performing any drawing operations to the bitmap yourself (at least for Windows NT). Would it be possible to keep a list of DIBSections and flush them all in GDIFlush, or is this not adequate?
And really - the best way to get rid of it is to finish the DIB engine :)
OK, that makes sense now that I understand what it does :-) David
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
On Tue, 25 Feb 2003 01:49, David Fraser wrote: <snip>
Seems to make sense except that I still have one question: the MSDN docs seem to indicate that you need to call GDIFlush() before performing any drawing operations to the bitmap yourself (at least for Windows NT). Would it be possible to keep a list of DIBSections and flush them all in GDIFlush, or is this not adequate?
I'm not familiar with GDIFlush(), but I just had a quick glance at the msdn docu for it, and it appears this is only relevent when using GDI in batch mode, (eg, do a bunch of GDI calls and then go 'render this') - and even then it still isn't required. Even if this function did what you wanted, it still wouldn't be possible to use properly because of speed issues (eg, we only coerce when we have to), and so on. (the same could be said for doing a coerce after each GDI call). David -- David Hammerton Programmer TransGaming Technologies Inc. david(a)transgaming.com
David Hammerton wrote:
On Tue, 25 Feb 2003 01:49, David Fraser wrote: <snip>
Seems to make sense except that I still have one question: the MSDN docs seem to indicate that you need to call GDIFlush() before performing any drawing operations to the bitmap yourself (at least for Windows NT). Would it be possible to keep a list of DIBSections and flush them all in GDIFlush, or is this not adequate?
I'm not familiar with GDIFlush(), but I just had a quick glance at the msdn docu for it, and it appears this is only relevent when using GDI in batch mode, (eg, do a bunch of GDI calls and then go 'render this') - and even then it still isn't required. Even if this function did what you wanted, it still wouldn't be possible to use properly because of speed issues (eg, we only coerce when we have to), and so on. (the same could be said for doing a coerce after each GDI call).
David
Right, but the MSDN documentation for CreateDIBSection says: <snip> *Windows NT/2000/XP:* 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* <http://msdn.microsoft.com/library/en-us/gdi/pantdraw_0enc.asp> function. This applies to any use of the pointer to the bitmap bit values, including passing the pointer in calls to functions such as *SetDIBits*. </snip> So internally, at least on Win NT/2000/XP, Microsoft themselves are doing this in a batched way and expecting to receive a GDIFlush before they have to update it. Speed-wise, I guess this may not be feasible because of the difference of using X, but actually, the user should call GDIFlush at exactly the points where we are picking up the page faults - when they're going to write to a bitmap that they've called GDI functions on. This might even therefore end up being quicker because there isn't the page fault handling overhead. Am I way off track? David PS The above doc is at http://msdn.microsoft.com/library/en-us/gdi/bitmaps_233i.asp further information from http://msdn.microsoft.com/library/en-us/tools/improve_77ar.asp below <snip> If you are writing an application that draws on the display, then the **CreateDIBSection** <http://msdn.microsoft.com/library/en-us/gdi/bitmaps_233i.asp> function can improve performance. This function allows you to share a memory section directly with the system, and thus avoid having it copied from your process to the system each time there is a change. Previously, a common practice was to call the *GetDIBits* <http://msdn.microsoft.com/library/en-us/gdi/bitmaps_7gms.asp> function, make the required changes, then call the *SetDIBits* <http://msdn.microsoft.com/library/en-us/gdi/bitmaps_0qk3.asp> function. These steps were often repeated on different scan lines of the bitmap before the image was ready for updating. Using **CreateDIBSection** is much simpler. One word of caution if you decide to use **CreateDIBSection**. You need to be sure that any calls that might affect your bitmap have completed before you start to draw in it. This is because the batching of GDI calls may cause their delayed execution. For example, suppose you make a *PatBlt* <http://msdn.microsoft.com/library/en-us/gdi/brushes_9vuc.asp> call to clear your bitmap, then you start to change the bits in your DIB section. If the *PatBlt* call was batched, it might not actually execute until after you start to make the bitmap changes. So, before you make changes to your DIB section, be sure to call **GdiFlush** <http://msdn.microsoft.com/library/en-us/gdi/pantdraw_0enc.asp> if you have made changes to the bitmap with earlier GDI calls. </snip>
Why is the special fault handler needed? implementation of a GDI engine... basically, both the app and X11 are used to read and write into it (each DIB is associated to an X11 pixmap, and, for example, when the app writes to the DIB section, there's a need to update the pixmap. on the other way aroud, GDI operation on the DIB, are in fact done on the X11 pixmap. then modifications have to be updated into the bits of the DIB
the fault handler is used to synchronize both accesses
What is the best way to approach getting rid of it? write a GDI engine
A+ -- Eric Pouech
Eric Pouech wrote:
Why is the special fault handler needed?
implementation of a GDI engine... basically, both the app and X11 are used to read and write into it (each DIB is associated to an X11 pixmap, and, for example, when the app writes to the DIB section, there's a need to update the pixmap. on the other way aroud, GDI operation on the DIB, are in fact done on the X11 pixmap. then modifications have to be updated into the bits of the DIB
the fault handler is used to synchronize both accesses
What is the best way to
approach getting rid of it?
write a GDI engine
And I have it in my tree :) It should be ready for submission in a few months from now. /Johan Gill <johane(a)lysator.liu.se>
participants (6)
-
David Fraser -
David Hammerton -
Dimitrie O. Paun -
Eric Pouech -
Johan Gill -
Mike Hearn