On Tue, 25 Feb 2003 01:49, David Fraser wrote:Right, but the MSDN documentation for CreateDIBSection says:
<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
<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>
