Bugzilla

Ok, while I find your way of communicating very annoying, I'll answer some of you questions to my knowledge. Maybe some details will be interesting to others as well.

1. the GLX backend in combination with WR (or OpenGL) is not hardcoded to 60Hz but uses `glXWaitVideoSyncSGI` to implement a global vsync source
2. Firefox does not report the archived frame rate in `about:support` because nobody bothered implementing that so far. Also, as mentioned before, that whole concept of reporting one number there only makes very limited sense nowadays.
3. that vsync source does not work on Xwayland and also has no EGL counter part
4. the "primary display" it syncs against is choosen by Xorg. Firefox or the WM/compositor have no influence on it. That means Firefox will usually sync at the rate of your WM/compositor.
5. until recently, that vsync source was also used for the experimental EGL X11 backend
6. this was changed in FF 82 to 60Hz software fallback as it caused problems on nvidia (again, only for the EGL X11 backend in combination with WR/GL, both not enabled by default yet)
7. walmartguy asked for an option to keep using the vsync source in that scenario (see bug 1669275)
8. the `_NET_WM_FRAME_DRAWN` based approach is probably harder than going for `EGL_CHROMIUM_sync_control`, for several reasons, which is why I decided to look deeper into the later. `EGL_CHROMIUM_sync_control` would work on per window basis and works on Xwayland.
9. on Wayland, there's an experimental per-window frame-callback based vsync source (`widget.wayland_vsync.enabled`, disabled by default). It's pretty much to optimal case, but will need some more tweaking (and maybe deep surgery in the shared code paths).
10. on Windows, Mac and Android, vsync is implemented differently each time. So results on testing sites may vary based on platform.
11. I'm doing this in my free time and Firefox is only one project among others I'm contributing to. The time I spent writing this could have gone into writing code.

Ok, while I find your way of communicating very annoying, I'll answer some of you questions to my knowledge. Maybe some details will be interesting to others as well.

1. the GLX backend in combination with WR (or OpenGL) is not hardcoded to 60Hz but uses `glXWaitVideoSyncSGI` to implement a global vsync source
2. Firefox does not report the archived frame rate in `about:support` because nobody bothered implementing that so far. Also, as mentioned before, that whole concept of reporting one number there only makes very limited sense nowadays.
3. that vsync source does not work on Xwayland and also has no EGL counter part
4. the "primary display" it syncs against is choosen by Xorg. Firefox or the WM/compositor have no influence on it. That means Firefox will usually sync at the rate of your WM/compositor.
5. until recently, that vsync source was also used for the experimental EGL X11 backend
6. this was changed in FF 82 to 60Hz software fallback as it caused problems on nvidia (again, only for the EGL X11 backend in combination with WR/GL, both not enabled by default yet)
7. walmartguy asked for an option to keep using the vsync source in that scenario (see bug 1669275)
8. the `_NET_WM_FRAME_DRAWN` based approach is probably harder than going for `EGL_CHROMIUM_sync_control`, for several reasons, which is why I decided to look deeper into the later. `EGL_CHROMIUM_sync_control` would work on per window basis and works on Xwayland.
9. on Wayland, there's an experimental per-window frame-callback based vsync source (`widget.wayland_vsync.enabled`, disabled by default). It's pretty much to optimal case, but will need some more tweaking (and maybe deep surgery in the shared code paths).
10. on Windows, Mac and Android, vsync is implemented differently each time. So results on testing sites may vary based on platform.
11. I'm doing this in my free time and Firefox is only one project among others I'm contributing to. The time I spent writing this could have gone into writing code. In other words: everyone is invited to propose different solutions, help finding better solutions and contribute code. I do not have more authority over what's going to happen here as everyone else.