Initial DRI3000 protocol specs available

[Keith Packard]

Owen Taylor <otaylor at redhat.com> writes:

> A complex scheme where the compositor and the server collaborate on the
> implementation of SwapRegion seems fragile to me, and still doesn't get
> some details right - like the swap count returned from SwapRegion.
>
> What if we made SwapRegion redirectable along the lines of
> ResizeRedirectMask? Since it would be tricky to block the client calling
> SwapRegion until the compositor responded, this would probably require
> removing the reply to SwapRegion and sending everything needed back in
> events.

When I first read this a week ago, I thought this was a crazy plan; but
upon reflection, I think this is exactly the right direction. I've
written up a blog posting in more detail about that here:

        http://keithp.com/blogs/composite-swap/

>  SwapScheduled - whatever information is available immediately on
>                  receipt of SwapRegion

I think this can still be in the reply to SwapRegion itself; essentially
all we're returning is the swap-hi/swap-lo numbers and a suggestion for
future buffer allocation sizes. We could place the buffer size hints in
a separate event, but I don't think they're that critical; it's just a
hint, and we'll get it right after a couple of swaps once the user stops
moving the window around anyways.

>  SwapIdle      - a buffer is returned to the application for rendering
>  SwapComplete  - the swap actually happened and we know the
>                  msc/sbc/ust triple

Yup. The blog posting suggests how the Complete event might be delayed
until the Compositor gets the content up onto the screen itself.

I also think that SwapIdle should *not* be an event. Instead, the client
should mark its pixmap as 'becomes idle upon swap'; on redirection, the
compositor ends up holding the last 'its not idle yet' bit, and when it
does the 'becomes idle upon swap', then the buffer goes idle.

The client must then tell the server to un-idle the pixmap, and that
request will return whether the contents were preserved or not. This has
to be synchronous or huge races will persist.

> But I don't know that you need that much granularity. I think SwapIdle
> and SwapComplete are sufficient.

As above, SwapIdle isn't good enough, an explicit un-idle request is required.

> Tricky parts:
>
>  * Not leaking buffers during redirection/unredirection could be tricky.
>    What if the compositor exits while a client is waiting for a
>    SwapIdle? An event when swap is redirected/unredirected is probably
>    necessary.

When the Compositor exits, the X server will know all of the pending
SwapRegion requests and can 'unredirect' them easily enough.

I don't want to tell apps when they're getting redirected/unredirected,
and I don't think it's necessary.

>  * To make this somewhat safe, the concept of "idle" has to be one of
>    correct display not system stability. It can't take down the system
>    if the compositor sends SwapIdle at the wrong time.

See above.

>  * Because the SBC is a drawable attribute it's a little complex to
>    continue having the right value over swap redirection.
>
>     When a window is swap-redirected, we say that the SBC is
>     incremented by one every time the redirecting client calls
>     SwapRegion, and never otherwise. A query is provided for the
>     current value.

We could simply decouple these values and just have a 'swap count'
associated with the window which is used to mark pixmap contents when
'UnIdled'.

>  * It doesn't make sense to have both the server and the compositor
>    scheduling stuff. I think you'd specify that once you swap
>    redirect a window, it gets simple:

Good point. The redirected swap event should contain all of the swap
parameters so that the Compositor can appropriately schedule the window
swap with the matching screen swap.

>    Actually, from the compositor's perspective, the window's front
>    buffer doesn't matter, but you probably need to keep it current
>    to make screenshot tools, etc, work correctly.

My swap redirect plan has that pixmap getting swapped at the same time
the screen pixmap is swapped, so things will look 'right'.

> Is this better than a more collaborative approach where the server and
> compositor together determine what pixmaps are idle?

Idleness is certainly a joint prospect, but I don't think it's
cooperative. Instead, a pixmap is idle when both application and
compositor say it is idle. The SwapRedirect explicitly marks the pixmap
as 'not idle' for the compositor, and an explicit 'make it idle' call is
required by the compositor.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20130306/1d7b4a7b/attachment.pgp>