Code review comment for lp:~vanvugt/mir/manual-vsync-api-v3

Yes, it can be implemented as a MirWindow function or a MirBufferStream function. However because swaps are per-stream, implementing it as a MirWindow function lacks information about past swaps, and so you lose the ability to catch up after missed frame deadlines. The result then is 1/2, 1/3, or 1/4 ... frame rate.

As a MirBufferStream function we get to use information from the last swap to determine whether we really need to wait for the next vsync or if we already missed the deadline (and so should not wait at all). So as a MirBufferStream function you avoid slow clients decimating to half/third/whatever frame rate. The MirWindow prototype of this branch lacks that ability, which is a major feature of FrameClock that would have gone to waste (although users of eglSwapBuffers with interval>=1 still get it for free).

I only just noticed recently that mir_window_get_buffer_stream is marked as deprecated. That's fine - we already knew that whoever completed the transition to MirRenderSurface would need to also port client-side vsync. So if that eventually happens a new function would be required that operates on a render surface.

If it's too contentious I can propose the MirWindow version of this, but it would be sad to drop the catch-up feature and end up decimating.