(0) Sure you can keep server-side queueing if you want it. So long as this code still has the ability to turn it off. Because having it queueing on will reintroduce the bufferbloat-nested-queuing-lag problems that are fixed here. So you probably don't want that, but up to you :)
(1) No FrameClock is not set at construction. It's set (and changes) whenever the window moves to a new monitor (different FrameClock). We may also wish to change the FrameClock depending on occlusions in future (to replace the 10Hz dropping hack)...
(2) Yes, I expect the logic to move around with Cemil's future changes but where it is right now works for what we use right now. As for a public API, yes I agree that will be wanted; already mentioned it in the description above, but also a public API will be needed by Xmir to implement https://www.opengl.org/registry/specs/OML/glx_sync_control.txt
kdub:
(0) Sure you can keep server-side queueing if you want it. So long as this code still has the ability to turn it off. Because having it queueing on will reintroduce the bufferbloat- nested- queuing- lag problems that are fixed here. So you probably don't want that, but up to you :)
(1) No FrameClock is not set at construction. It's set (and changes) whenever the window moves to a new monitor (different FrameClock). We may also wish to change the FrameClock depending on occlusions in future (to replace the 10Hz dropping hack)...
(2) Yes, I expect the logic to move around with Cemil's future changes but where it is right now works for what we use right now. As for a public API, yes I agree that will be wanted; already mentioned it in the description above, but also a public API will be needed by Xmir to implement https:/ /www.opengl. org/registry/ specs/OML/ glx_sync_ control. txt