Re: A couple of questions about the new order

Keith Packard wrote:

>Around 16 o'clock on Nov 25, "Robert O'Callahan" wrote:
>  
>
>>We want to be able to combine updates to this whole tree of X windows,
>>geometry changes to those windows, and scrolling, all into one visually
>>atomic operation.
>>    
>>
>
>And this is what Composite with Manual update permits; the decoupling of
>sub-window rendering and geometry with the eventual visible results on the
>screen.  In this mode, all rendering to the window is pended in the 
>off-screen buffer and left for the controlling application to paint into 
>the parent.
>I'm afraid I don't quite follow your plan.  Composite just takes a window 
>heirarchy and renders it to off-screen memory, updates to the parent 
>window happen at the discretion of the Manual update client, or the server 
>when in Automatic mode.  Obviously coordinated updates require Manual 
>mode, but that shouldn't introduce additional latency in your case as the 
>timing of those updates is triggered by internal application events.
>
>  
>
I didn't explain it well. I wasn't intending to use Composite to manage 
all our child windows, but now that you mention it, it might work.

Here's the thing that I didn't manage to get across, so I'll try again: 
most of our child windows (except for plugins) don't have their own 
contents to draw. They all paint the same pixels as the parent window 
underneath them. (Because they just pull the right bits from our single 
logical canvas.) In other words, we'd just as soon treat these child 
windows as fully transparent. If we put these child windows into Manual 
mode, would there be any problems if we choose not to ever repaint these 
child windows, and never actually look at their contents? It seems that 
at least their backing buffers would be sitting there, wasting memory.

Also, can we now scroll by just copying pixels within Composite's 
backing pixmap for a window?

>>I don't see any way to avoid having separate application and XComposite 
>>backing buffers while the application is rendering. If you have just one 
>>buffer then you have a problem if XComposite wants to recompose the 
>>screen while the app is in the middle of rendering.
>>    
>>
>
>One possibility is to explore some ways of pending screen updates while 
>the application is updating its back buffer; that would likely want some 
>kind of timeouts so screen updates weren't delayed arbitrarily, but 
>pausing for a few milliseconds to ensure consistent presentation without 
>requiring yet another level of buffering might be a good tradeoff.
>
>  
>
So when a timeout fires, it just looks ugly? I guess that's OK.

Rob