So when triggering the race (i.e. without the patch from above and after trying a couple of times) I can manage to get Firefox into all kinds of odd vsync states. In a setup with one 60Hz and on 120Hz display, testufo.com (less heavy than vsynctester) sometimes gives 90FPS, sometimes ~108, sometimes 60 (on the 120Hz display). Trying with a build with the patch applied (i.e. ~nightly from tomorrow), I reliably get the right refresh rates*. Also setting `widget.wayland.vsync.enabled:false` does not trigger the bug again, but instead gives me solid 60FPS. So without digging deeper I assume what we see here something that can only happen in a mixed state where some components use `WaylandVsyncSource` and others `SoftwareVsyncSource`. And the patch should avoid that we can get into such a state. I also looked into `VsyncParent` again but couldn't find anything really wrong. Thus declaring this fixed once the patch lands. *: note: this is with https://gitlab.gnome.org/GNOME/mutter/-/issues/1971 applied to not get wrong frame callbacks from Mutter.
Bug 1744896 Comment 83 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
So when triggering the race (i.e. without the patch from above and after trying a couple of times) I can manage to get Firefox into all kinds of odd vsync states. In a setup with one 60Hz and on 120Hz display, testufo.com (less heavy than vsynctester) sometimes gives 90FPS, sometimes ~108, sometimes 60 (on the 120Hz display). Trying with a build with the patch applied (i.e. ~nightly from tomorrow), I reliably get the right refresh rates*. Also setting `widget.wayland.vsync.enabled:false` does not trigger the bug again, but instead gives me solid 60FPS. So without digging deeper I assume what we see here something that can only happen in a mixed state where some components use `WaylandVsyncSource` and others `SoftwareVsyncSource`. And the patch should avoid that we can get into such a state. I also looked into `VsyncParent` again but couldn't find anything really wrong. Thus declaring this fixed once the patch lands. *: note: this is with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2169 applied to not get wrong frame callbacks from Mutter.
So when triggering the race (i.e. without the patch from above and after trying a couple of times) I can manage to get Firefox into all kinds of odd vsync states. In a setup with one 60Hz and on 120Hz display, testufo.com (less heavy than vsynctester) sometimes gives 90FPS, sometimes ~108, sometimes 60 (on the 120Hz display). Trying with a build with the patch applied (i.e. ~nightly from tomorrow), I reliably get the right refresh rates*. Also setting `widget.wayland.vsync.enabled:false` does not trigger the bug again, but instead gives me solid 60FPS. So without digging deeper I assume what we see here something that can only happen in a mixed state where some components use `WaylandVsyncSource` and others `SoftwareVsyncSource`. And the patch should avoid that. I also looked into `VsyncParent` again but couldn't find anything really wrong. Thus declaring this fixed once the patch lands. *: note: this is with https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2169 applied to not get wrong frame callbacks from Mutter.