On 03/06/2013 10:35 PM, Keith Packard wrote:
* PGP Signed by an unknown key
Owen Taylor <[email protected]> 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.
If I'm understanding this correctly, this requires the X server to
receive a notification from the GPU that the swap is complete so it can
send the SwapComplete event. Is there any chance this could be done
with a Fence instead? The application could specify the fence in the
Swap request, and then use that fence to block further rendering on the
GPU or wait on the fence from the CPU. We typically try to do the
scheduling on the GPU when possible because triggering an interrupt and
waking up the X server burns power and adds latency for no good reason.
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.
--
Aaron
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
