I’ve read these arguments quite a few times and always found them a bit questionable. Sure, if everything is driven by the vblank time (or any other clock that

I’ve read these arguments quite a few times and always found them a bit questionable. Sure, if everything is driven by the vblank time (or any other clock that counts in frames), it makes sense. But that’s a silly approach! There is nothing whatsoever special about allocating one full frame interval to the compositor to composite a frame — if it takes 16ms to composite reliably, it will take 16ms to composite reliably at 30Hz or 60Hz or 144Hz. So shouldn’t the system clock itself on a time basis, not a frame basis? Put another way, a system fast enough to composite at 144Hz should be able to composite at 60Hz while only allocating 1/144 seconds to the compositor, which would require offsetting the presentation times as seen by the compositor’s clients by some fraction of a frame time, which doesn’t actually seem that bad. It gets even better if variable refresh rate / frame timing works well, because then frames don’t drop even if some fraction of compositing operations are a bit too slow. I assume I’m missing some reason why this isn’t done.