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. At the most granular, this would be: SwapScheduled - whatever information is available immediately on receipt of SwapRegion SwapIdle - a buffer is returned to the application for rendering SwapComplete - the swap actually happened and we know the msc/sbc/ust triple But I don't know that you need that much granularity. I think SwapIdle and SwapComplete are sufficient. 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. * 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. * 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. * 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: - SwapRegion called by another client - SwapRegionRequest is immediately generated. - SwapRegion called by redirecting client - action (either a swap or a copy) happens immediately. 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. Is this better than a more collaborative approach where the server and compositor together determine what pixmaps are idle? I think it might be a little simpler and more flexible. It also potentially allows a SwapRegion on a client window to be directly turned to a SwapRegion on the root window for a full-screen client. But there probably are a host of difficulties I'm not thinking of :-) - Owen _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel