x11drv, ntdll separation

[David Fraser]

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>