[Xorg] Damage/Composite + direct rendering clients

[Keith Packard]

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

> Even for front buffered flushes I would be inclined to just say that it
> damages the whole drawable, rather than try to compute a smaller bounding
> region.

That's certainly fine for now; if people really get excited about 
optimizing this case, they can fix it themselves.  I don't know of too 
many applications which draw to the front buffer...

> The tricky part here is that the damage event shouldn't be sent to
> Damage clients until the hardware has completed the damage, but
> that is the vendor's problem... I'm just trying to make sure
> everything that is needed is in place so that vendors can solve that.

It can't even be seen by the X server until the rendering is complete.
When using 'automatic' update mode, there isn't an external application 
waiting for the event; the X server updates the screen directly.

> One solution would be for the direct rendering client to send private
> protocol to the X server as soon as the rendering is sent to the hw.

Sure; just as long as the X server could then block awaiting completion.

> BeginComposite/EndComposite bracketing would facilitate that (it
> would be BeginComposite's job to make sure the hw had completed).

There's no need for these extra requests -- the X server just needs to
block when using the indicated source window buffer.  This way, the X 
server can actually pend lots of other parts of the compositing operation 
and only when the affected window finally comes into play will the X 
server block.

I just thought of another case here -- we want to allow for direct 
rendering compositing managers as well.  That will require inter-client
synchronization along the same lines...

>     glxgears is then redrawn (and swapped) before the compositing
>     is performed.  When the compositing is performed, the xterm
>     and the portion of the glxgears window beneath the xterm are
>     recomposited into the backing pixmap, which is then blitted to
>     the visible screen.  At this point, we have a tear between the
>     portion of the glxgears window that is not beneath the xterm
>     and the part that is (the part that is beneath the xterm is
>     from glxgear's new frame, while the part not beneath the xterm
>     is from the old frame).

The window of vulnerability isn't as long as you fear -- the compositing 
manager can always use the damaged region of each window precisely at the 
time of the compositing operation, without reference to any events it has 
received.  That's because the damage accumulates inside X server regions
where it can be used to compute correct updates.

As long as the compositing manager holds the server grabbed (which
presumably locks out direct clients as well) while it updates the screen,
there shouldn't be any tearing.  No need to drain the event queue or 
anything else so dramatic.

> > information related to a specific drawable.  Any future requests for 
> > contents from that drawable must delay until that damage has actually 
> > occurred.
> 
> Right, but how is that enforced?  Who delays until the damage has
> actually occurred?

The X server would have to stall waiting for the swap to complete. It 
would "know" to do this because the direct client would have indicated 
that the swap was queued to the hardware.

> True, but window managers can't cause video memory to be freed,
> which would be really nice to do when you are transitioning into a
> fullscreen application.

They can free the extra buffers used for Composite, and the X server can 
migrate less used pixmaps from the video card.

> Even the RandR implementation naively leaves the video memory allocated for
> the largest possible root window size.

Not in kdrive.

> OK; how does a driver differentiate the per-window pixmaps from
> regular pixmaps?

The driver can see them associated with windows by wrapping 
SetWindowPixmap.

> So if the X server might start compositing, then the driver can't advertise
> the overlay port; is that correct?

It could pretend the overlay port was busy for new apps and silently
translate an existing overlay application to textures.  I don't quite 
know; I use overlay video with composite now and it works as long as the 
windows are aligned on the screen correctly.  I'd like to make that 
possible in the future as well, but I'm not quite sure how to do that.

-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/2942e969/attachment.pgp>