Yeah, having to synchronize multiple windows is probably a pain. I guess that's a much smaller issue with a VR application (the OpenVR compositor supports overl

Yeah, having to synchronize multiple windows is probably a pain. I guess that's a much smaller issue with a VR application (the OpenVR compositor supports overlays, but they're not used that often, and there's a clear priority to the "main" VR content) I guess a valid approach would be to double buffer all windows on the compositor side, and render the "stale" buffer of any window that fails to update within a specified frame budget (16ms - expected compositing time), that way at least well behaved apps would have no noticeable latency. There would probably need to be some level of coordination with apps that already do their own double buffering, not sure how that's currently handled. Perhaps a hybrid approach between compositing and direct rendering is also possible, where different screen regions get composited at different frame rates. (Should work as long as there's no transparency involved)