(In reply to Roman Gilg from comment #6)
Since Robert made me aware of this bug: I'm currently reworking subsurfaces in KWinFT and testing with firefox-nightly. Using the default config and changing the vsync.enabled option still does not work.
I would like to help with pinpointing the issue. Are you expecting something explicitly from the compositor? Above Kenny said "committing surfaces with frame callbacks but no new buffers". Does this mean when you receive a frame callback but have no damage you commit the same buffer again?
I mean that no buffers nor damage are submitted at all in the frame callback. The flow, either run on frame callback or when starting the vsync source, is:
struct wl_callback *callback = wl_surface_frame(surface);
wl_callback_add_listener(callback, &frame_callback_listener, data);
The actual code can be seen here: https://searchfox.org/mozilla-central/source/widget/gtk/WaylandVsyncSource.cpp#107. Unfortunately, vsync in Firefox is entirely disconnected from rendering, hence this odd (although valid) construct. Listeners for vsync (https://bugzilla.mozilla.org/show_bug.cgi?id=1645528) in Firefox may then render and cause a new buffer to be submitted as part of another commit.
Based on conversations in #wayland, it was concluded that this construct is valid (although suboptimal), and should result in frame callbacks being fired as long as the surface is eligible for frame callbacks. Presence of buffers and damage does not affect the eligibility. A bug in Mutter lead to frame callbacks stopping after a set period of time if damage was not being submitted.
To the best of my knowledge, a better implementation requires at least partially redesigning frame scheduling in Firefox. possibly lining more up with what Chromium is doing.
(feel free to needinfo me or find me in #wayland on freenode if you have questions)