[Xorg] Damage/Composite + direct rendering clients

[Keith Packard]

Around 11 o'clock on May 17, Andy Ritger wrote:

> How should a direct rendering client interact with Damage/Composite?
> There seem to be two pieces to this: damage notification, and
> synchronization.

Thanks for getting this topic started.

> When a direct rendering client damages the X screen, it needs to
> communicate that information to the X server so that the X server can
> notify Damage clients of the damage.

We can easily send damage data over the wire if you like; that would 
require the active participation of the direct-rendering client.

You can do that today easily enough -- use XClearArea after setting the 
window background to None (and perhaps back again when you're done).  Oh 
wait, that doesn't actually work right now -- I've got a kludge which 
ignores background None painting to windows.  I need to fix that anyway to 
handle mapping of background None windows cleanly.

Alternatively, we can use the existing DamageDamageRegion function which 
is already exposed within the server to mark regions from the direct 
rendering clients as they modify the window pixmap.

>    1) client kicks off rendering, notifies X server of damage,
>       X server sends Damage event to composite manager, composite
>       manager sends compositing request back to server, server
>       performs composite.  There needs to be some synchronization to
>       guarantee that the composite is not performed until the client
>       rendering is completed by the hardware.

Given that most applications double buffer their output, this seems like a
pretty well constrainted problem.  The only request which can affect the
front buffer is a buffer swap, and that modifies the entire window 
contents.  So, the X server must be able to find out when the buffer swap 
actually occurs, and either be signalled or block until that point.

>   2) some damage occurs, composite manager sends composite request,
>      additional rendering is performed, part of which the composite
>      operation picks up, but the rest of the rendering is not
>      composited until the next "frame" of the composite manager,
>      and we see visible tearing.

Applications which wish to avoid tearing must double buffer their output, 
just as they do today.  Once that is true, then there is no 'partial' 
rendering, the buffer swap damages the entire window and replaces all of 
the contents.

A more efficient implementation could actually perform this buffer swap 
without copying any data around -- just flip the off-screen storage for 
front/back buffers.  That's probably easier with GL than 2D apps which 
tend to create window-sized pixmaps for 'back buffers', leaving the 
semantic mismatch between copy and swap.

> Perhaps the best solution is to introduce two new requests to the
> Composite extension: a "BeginComposite" and an "EndComposite" that
> composite managers would call, bracketing their compositing requests.

I don't think this is necessary -- the X server receives the damage 
information related to a specific drawable.  Any future requests for 
contents from that drawable must delay until that damage has actually 
occurred.

>   1) Truly double buffer the compositing system.  Keith's sample
>      xcompmgr double buffers the compositing by creating a pixmap the
>      size of the root window, compositing into that, and then after
>      each frame of compositing is complete, copying from the pixmap
>      to the visible X screen (is that accurate, Keith?)

I don't think we can avoid doing this; one of the primary goals of the 
system is to provide a clean tear-free user experience, so all screen 
updates must be performed under double buffering.

>      I can't make a strong argument for it, but if instead a back
>      buffer for the root window were automatically allocated when a
>      composite manager started redirecting windows, and compositing
>      was done into that buffer, then this might allow for various
>      minor optimizations:

A GL-based compositing manager could easily do this.  And, an X-based 
compositing manager could use the double buffering extension if it wanted 
to.  My tiny kdrive based server doesn't happen to include that extension.

>    2) An actual fullscreen mode.  This is admittedly orthogonal
>       to compositing, but the overhead of compositing suggests that
>       we should have a mode of operation that clients can request
>       where they are given exclusive access to the hardware,
>       bypassing the compositing system.

The compositing manager could recognise this case automatically if it were 
coupled with the window manager a bit more.

> - It is important that X.org maintain a binary compatible driver
>   interface, so that vendors are not required to provide multiple
>   driver binaries (how to determine which binary to install? etc...)

Absolutely.  The Composite extension is being integrated in a completely 
binary compatible fashion.  If any changes are required in the future, 
we'll have long lead times and cross-version compatibility to deal with at 
that point.

> - An X driver should be able to wrap the redirection of windows to
>   offscreen storage:

It already can -- per-window pixmaps are created and the driver notified 
before any rendering occurs; a clever driver could migrate those pixmaps 
to special offscreen storage if it wanted to.

> - An X driver should be able to call into the core X server to
>   notify X of damage done by direct rendering clients.

See DamageDamageRegion

> - A Video Overlay Xv Adaptor is obviously fundamentally incompatible
>   with Damage/Composite.  Should X drivers no longer advertise
>   Video Overlay Xv adaptors if they are running in an X server that
>   includes Composite support?

Actually, as long as the windows are aligned on the screen with their 
nominal position and are opaque, this works just fine.

However, when the windows are not so carefully positioned, the system will 
need to use a YUV texture to paint the video contents into the window 
pixmap and damage the region so the compositing manager can update the 
screen as appropriate.

> - As window managers and desktop environments start folding composite
>   manager functionality into their projects, it would be nice
>   for them to provide a way to dynamically disable/enable
>   compositing.

Yeah, I often turn off the compositing manager when doing 'odd' things.  

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040517/8b209240/attachment.pgp>