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.
The question is whether the SwapCount is the count of swaps on the window, or the count of swaps to the final screen image. I think it's just the former, in which case the presence of a compositor doesn't have any effect on the correctness. The effect of the compositor is strictly in holding a reference to the window buffer and potentially delaying the reuse of that buffer within the application. > 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: We're really trying to avoid using events here -- they're quite messy on the client side as you must capture them deep within the X library implementation and shovel them over to the correct context within the Mesa library. Using replies makes it all quite simple; the correct context will be present automatically to receive the reply from SwapRegion. > * 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. With the current pixmap ID referencing technique, that ID will be freed when the compositor exits (I mentioned this would be required before) which will reduce the reference count to the point where the SwapIdle event would get sent. > 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 :-) Oh. Having the compositor just take the new window buffer and send a SwapRegion from that to the root window. I hadn't thought of that, as I was still assuming we'd be 'unredirecting' full screen windows, but this sure looks like a compelling alternative plan that should simplify the compositor fairly nicely. Let's stick that one on the list of 'it sure would be nice if this were possible' list and see what it will take to make it work. -- [email protected]
pgp0TjY1M2fjo.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
