> IIUC input is still driven at 60Hz but changing this is in discussion [2].

Why are inputs synchronized to the frame in Wayland? What the f---? That's just... wow.

The logic is that it doesn't make sense to deliver multiple batches of input in a single frame since the application will only get the chance to render once, maybe as well batch up a chunk of input once per frame.

The logic isn't perfect and the implementation is flawed but I see where the decision originated.

The app only gets to present one frame per compositor frame, but that doesn't restrict the app to rendering only one frame. This purely seems like a power-saving feature; it might not be entirely unreasonable in battery-powered devices, but everywhere else adding yet-another frame of input lag to systems that are generally already noticeably worse than the competition - not good.

Since the compositor is already using vsync, it's generally pointless to run graphical applications under a compositor with vsync as well, since that only adds latency. [2] Hypothetically that can result in tearing, however in practice that doesn't matter, because the scanout of the compositor is basically a copy in GPU memory, so you'd have to be rather unlucky to see tearing, let alone consistent tearing. [1]

Of course, OpenGL doesn't support triple buffering (since it has fixed definitions of exactly one GL_FRONT and exactly one GL_BACK buffer per framebuffer/output surface), and it seems like at least nVidia on Linux doesn't support it for Vulkan, either (no mailbox present mode, only FIFO).

In any case, on X11 there is a huge difference between running a 3D UI on a compositor with (A) VSync enabled, (B) running without VSync (which introduces unncessarily high GPU loads, since UIs are generally super-quick to render and if your app architecture is correct, you should be seeing thousands of frames per second), (C) running with a frame limiter (careful choice of limiting FPS to avoid common multiples of 30), (D) rendering a frame as soon as at least one event has been posted, which requires some explicit synchronization work and thought (worker threads have to post events to wake the UI, animations need a timer). (D) is what QML does and what I'm implementing currently. It works well, latency seems to be indistinguishable from B) and C), without the unnecessary power use. X11 only seems to deliver events at a rate of somewhere around 250-400 per second, so an explicit FPS limiter is unnecessary.

[1] If you are rendering to a monitor, scanout happens approx 95 % of the time, so tearing is very likely. Let's say your app's window is 1451x1400 pixels big, then its framebuffer will be about 8 MB. The "scanout" will take something like 15 µs, so at 60 Hz scanout happens about 0.1 % of the time.

[2] My angle here is primarily applications that happen to use <insert 3D API here> as their UI rendering backend. Games have slightly different considerations and should generally just run full-tilt with triple buffering.

How does mutter behave for X?

Mutter is a compositor for Wayland iirc, so it's non-applicable to X.

?? If so what's the X gnome compositor?

Did a little more research, Mutter is used on X as well it looks like, or at least used to be [0]. Sorry for the inaccuracy.

https://en.wikipedia.org/wiki/Mutter_(window_manager)

Edit: I missed the part where you were asking specifically about GNOME. Removed everything unrelated to that.