Re: A couple of questions about the new order

Around 16 o'clock on Nov 25, "Robert O'Callahan" wrote:

> Will we be able to use XDamage, XComposite etc (maybe XTest?) to fully 
> encapsulate legacy plugins that manage their own X windows? We need to 
> be able to stop them from rendering directly to the screen and directly 
> receiving input, capture their rendering into our own arbitrary 
> offscreen buffer, and poke them with input events when we feel like it.

We haven't figured out how to deal with input yet, but Composite can 
capture the output.  You'll have to hide the window somewhere (perhaps 
underneath some other window as Composite doesn't change the semantics of 
unmapped windows at all.

> We have a single logical canvas that for annoying reasons has to be 
> projected on top of a whole stack of GTK windows.

That's just regular window painting semantics; the parent window image is 
constructed from the union of the parent image and all of the child images 
with suitable clipping.

> 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 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.

Note that Composite permits redirection at every level of the window 
heirarchy, so if you need more buffering, you can easily glue in another 
redirected window, or do your own buffering with another manually 
allocated pixmap.

-keith