Closed Bug 1640779 Opened 2 years ago Closed 7 months ago

[X11][EGL] Detect (roughly) correct screen refresh rates

Categories

(Core :: Graphics: WebRender, enhancement, P5)

Unspecified
Linux
enhancement

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: rmader, Assigned: rmader)

References

(Blocks 4 open bugs)

Details

Attachments

(3 files)

In order to deprecate GLX completely, we'd need to implement VSync using EGL. It should be easy to simply use EGL primitives, but while on it we could try not using the root window as source - that would mainly benefit Xwayland, which does not have a concept of root window and therefore always falls back to a 60Hz timer.

Blocks: vsync
Blocks: wr-linux
Severity: -- → S4
OS: Unspecified → Linux
Priority: -- → P5

(In reply to Robert Mader [:rmader] from comment #0)

[...] we could try not using the root window as source - that would mainly benefit Xwayland, which does not have a concept of root window and therefore always falls back to a 60Hz timer.

It would also benefit Xorg with multiple monitors.

Comments on current GLX vsync:

(Jeff Muizelaar [:jrmuizel] from bug 1628913 comment 4)

Ok, that's sort of what I was expecting. I think we probably need to throw our Linux vsync implementation in the trash.

(Jeff Muizelaar [:jrmuizel] from bug 1592530 comment 8)

I think we should consider switching to software vsync on Linux (Perhaps check that it's what Chrome does). The current implementation seems to have too many problems.

See Also: → 1628913, 1592530

(In reply to Michel Dänzer from comment #1)

(In reply to Robert Mader [:rmader] from comment #0)

[...] we could try not using the root window as source - that would mainly benefit Xwayland, which does not have a concept of root window and therefore always falls back to a 60Hz timer.

It would also benefit Xorg with multiple monitors.

Michel, on GLX, clients like glxgears use GLX_EXT_swap_control - on EGL things appear to work differently. Do you know of any demo app implementing vsync using EGL in a similar fashion?

Flags: needinfo?(michel)

Ah never mind, it's eglSwapInterval. Will look into this today.

Flags: needinfo?(michel)
Blocks: 1588589

So if I understand things correctly, this could work roughly as follows:

  • the vsync source is supposed to fire notifyVsync() directly after the last vsync (https://searchfox.org/mozilla-central/source/gfx/thebes/VsyncSource.h#48-51)
  • eglSwapBuffers and eglSwapBuffersWithDamage block until the vsync, i.e. we need to fire exactly after (or in) GLContextEGL::SwapBuffers() https://searchfox.org/mozilla-central/source/gfx/gl/GLContextProviderEGL.cpp#519
  • that means we don't have a global sync source, but a context specific one
  • that in turn means we should probably do things similar to the Wayland vsync source, e.i. we set up the vsync source in nsWindow::WaylandStartVsync() for individual windows (and fall back to software in the remaining cases - if we then try to enhance the situation for that cases, both Wayland and X11 benefit)
  • the corresponding egl context for that window then just needs to get wired up to call notifyVsync() with the current timestamp

Does this sound reasonable? Michel, Kenny?

Flags: needinfo?(michel)
Flags: needinfo?(bugzilla)
See Also: → 1563075

p.s.: I'm not exactly sure about what GetVsyncRate() does - but at the moment AFAICS we always return the default 60 on GLX. Maybe we can track swap times and give better results here.

If eglSwapInterval(1) is called, then eglSwapBuffers/eglSwapBuffersWithDamage will synchronize to vblank somehow. On wayland, frame callbacks are used, while I believe X11 uses the DRI Present extension. Indeed, this provides a context-specific source, which is the only thing that makes sense to do.

I assume your idea is to fire the VsyncSource notifyVsync immediately after eglSwapBuffers? This would provide a vsync events as long as you keep swapping buffers, but the problem is that all VsyncSource consumers (most of which have nothing to do with rendering at all...) assume that they more or less get a continuous stream of vsync events as long as the source is active, including if no buffer swaps is occurring. Restructuring this was a big part of the FrameSource changes.

If we end up with enough of an overhaul to make this work with eglSwapInterval(1), then we might be able to share it with Wayland (if we can work around some wayland-specific issues with blocking swap-buffer - swapping a hidden window will block until it becomes visible, for example).

(Alternatively, maybe the X synchronization extension can be used to get notified of vblank counter increments.)

P.S.: GetVsyncRate was meant to return the expected tick rate, but that is never going to work in a meaningful way.

Flags: needinfo?(bugzilla)

(Note: I believe that on Wayland, swapInterval(1) might lead to basically guaranteeing that frames will be one refresh period old, but that's maybe a different topic altogether.)

(In reply to Kenny Levinsen :kennylevinsen from comment #8)

(Note: I believe that on Wayland, swapInterval(1) might lead to basically guaranteeing that frames will be one refresh period old, but that's maybe a different topic altogether.)

Yeah, trying to wrap my head around what swapInterval(1) would mean for frame callback emission in Wayland compositors, given the implicit synchronisation in drivers (see bug 1634903, https://gitlab.gnome.org/GNOME/mutter/-/issues/1162)

Edit: never mind, I guess swapInterval(1) is no option on Wayland until we find some solution to use the GPU process - which would require some new protocol in the first place.

(In reply to Robert Mader [:rmader] from comment #9)

Yeah, trying to wrap my head around what swapInterval(1) would mean for frame callback emission in Wayland compositors, given the implicit synchronisation in drivers (see bug 1634903, https://gitlab.gnome.org/GNOME/mutter/-/issues/1162)

eglSwapBuffers with eglSwapInterval(1) on Wayland is implemented in mesa as setting up a frame callback that set a flag, and dispatching the wayland connection until the flag gets set, thereby blocking the buffer swap until next frame callback (not vblank). It doesn't affect frame callbacks, it just uses them—buffer synchronization is a different issue. Although, some smarts are done so that it doesn't delay the first frame, but rather ends up throttling consecutive calls.

This is also why I said "believe" - I don't recall all the details, but frame scheduling so that you not only don't drop frames but also get frames that are fresher than a refresh period is tricky on any platform. For videos, you can use presentation feedback to calculate the delay from swap to present, but for dynamic content, you want to render as late as possible...

This is going outside the scope of Firefox's current vsync setup, which is just a "dumb" vblank ticker.

Edit: never mind, I guess swapInterval(1) is no option on Wayland until we find some solution to use the GPU process - which would require some new protocol in the first place.

I don't see why this should only work in a GPU process. Blocking a thread in the main process shouldn't be an issue. The problem is if we end up blocking an unsuspecting thread, which is the problems we had before swapInterval was set to 0.

Multi-process wayland connections would be a larger project, with defining the protocol being the smallest problem of it all.

(In reply to Robert Mader [:rmader] from comment #5)

eglSwapBuffers(WithDamage) don't block until vsync, so they can't be used for this.

(In reply to Kenny Levinsen :kennylevinsen from comment #7)

(Alternatively, maybe the X synchronization extension can be used to get notified of vblank counter increments.)

Not that I know of. The Present extension could be used though (but corresponding MSC values between that and EGL would probably be tricky).

(In reply to Michel Dänzer from comment #11)

(In reply to Robert Mader [:rmader] from comment #5)

eglSwapBuffers(WithDamage) don't block until vsync, so they can't be used for this.

Hmm, yeah, on X11 it appears that it's the next GL operation after eglSwapBuffers with eglSwapInterval(1) that blocks until vsync, rather than the buffer swap. At least in a quick local test, it's a glClear after a swap that ends up waiting a refresh period to execute.

On Wayland, it's eglSwapBuffers itself that blocks if a frame callback has not yet arrived since last swap.

(In reply to Kenny Levinsen :kennylevinsen from comment #7)

(Alternatively, maybe the X synchronization extension can be used to get notified of vblank counter increments.)

Not that I know of. The Present extension could be used though (but corresponding MSC values between that and EGL would probably be tricky).

Can't find much documentation on the Present extension. Mesa itself is using Present internally, but doesn't seem to break it out for us. I suppose the present done event would only be sent to mesa's queue when mesa is doing the xcb_present_pixmap, which would make it a little hard to access.

If we could get a duplicate of that event, then we'd have a similar setup to wayland and frame callbacks for every swap (but unlike wayland, we'd be unable to get events at all outside swaps, so again this is more FrameSource-like than VsyncSource-like).

Uneducated side note regarding Present extension: Picom compositor implemented vsync via it for its xrender backend. It works fine with Mesa, but atrociously with Nvidia.

Another idea that was brought up already somewhere would be to use compositor frame synchronization (1), i.e. _NET_WM_FRAME_DRAWN. That's what GTK4 does for its GL backend (2) and appears quite close to what Wayland does. It would only work for modern WMs, but I guess that's ok (fall back to a timer otherwise). Such a design would also fit well into bug 1563075.

1: https://fishsoup.net/misc/wm-spec-synchronization.html
2: see e.g. https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/1982

Chromium seems to use EGL_CHROMIUM_sync_control on Mesa, but proprietary Nvidia doesn't support it (bug 1640147 comment 2):
https://gitlab.freedesktop.org/mesa/mesa/-/commit/c524f3ef9155caba6cd4f9fc72485426b1da76fd

Chromium defined a new GL extension (that isn't registered with Khronos).
We need to add an EGL extension for it, so we can migrate ChromeOS on Intel systems to use EGL instead of GLX.

https://source.chromium.org/chromium/chromium/src/+/master:ui/gl/gl_surface_egl.cc;l=222;drc=912769f6ef3aaffd86632c6268ae311559ffebbe
https://source.chromium.org/chromium/chromium/src/+/master:ui/gl/EGL/eglextchromium.h;l=16;drc=5cddfb828ddd82fc741549d5ee44cd9b94bd97f5

See especially: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2930


https://github.com/freedesktop/mesa-demos/blob/master/src/egl/opengl/eglinfo.c
KDE, X11, Debian Testing, Mesa 20.0.7, Intel Iris Graphics 6100 (BDW GT3):

X11 platform:
EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES
EGL extensions string:
EGL_ANDROID_blob_cache EGL_ANDROID_native_fence_sync
EGL_CHROMIUM_sync_control EGL_EXT_buffer_age
EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import
EGL_EXT_image_dma_buf_import_modifiers EGL_IMG_context_priority
EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context
EGL_KHR_create_context_no_error EGL_KHR_fence_sync
EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace
EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap
EGL_KHR_no_config_context EGL_KHR_reusable_sync
EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float
EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image
EGL_MESA_image_dma_buf_export EGL_MESA_query_driver
EGL_NOK_texture_from_pixmap EGL_WL_bind_wayland_display

Flags: needinfo?(michel)

Bug 1650583 disables the GLX VSync for EGL so we now use the 60Hz software fallback, just like on Wayland (without experimental frame callback source).

See Also: → 1650583

Is this just until the windowing issues are ironed out, or supposed to last beyond that?

(In reply to walmartguy from comment #17)

Is this just until the windowing issues are ironed out, or supposed to last beyond that?

It's supposed to stay that way until a solution for this bug here is found and implemented.

FTR, I'll give it a try if I can make something work using EGL_CHROMIUM_sync_control + EGL_ANGLE_sync_control_rate (https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5139)

How does it look? Any success with using EGL_CHROMIUM_sync_control + EGL_ANGLE_sync_control_rate ?

Actually I didn't yet start with that :/ Having a look right now.

Another VSync / swap control related EGL extension seems to be in the works: "EGL_MESA_swap_control_tear"

extension spec: https://github.com/KhronosGroup/EGL-Registry/pull/113
mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6919

"This extension extends EGL by allowing late swaps to occur without synchronization to the video frame. This per-surface attribute reduces the visual stutter on late frames and reduces the stall on subsequent frames."

It doesn't sound like "EGL_MESA_swap_control_tear" replaces "EGL_ANGLE_sync_control_rate", but probably complements it.. not sure if Firefox needs it though.

I don't think EGL_MESA_swap_control_tear helps us much here as the main goal is to refresh at the monitors refresh rate. Having good timing would be a great next step, though :)

Depends on: 1669275
No longer depends on: 1669275
See Also: → 1669275

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.

Small update: as eglGetSyncValuesCHROMIUM works on surface base we face a couple of challenges that we also have with the Wayland Vsync source. The current implementation, on all platforms, assume a single global Vsync source - we have to fix that first. So I'll first turn to the Wayland Vsync source again.

Depends on: 1645528
Blocks: 1635186

update about "EGL_ANGLE_sync_control_rate" extension:

How does it look currently with firefox and EGL Vsync? afaik firefox currently uses either X11 specific or Wayland specific methods to do the VSync, not EGl, because, well, there's no suitable EGL extension available yet.

Recently SDL has also been working more with Wayland support, and I noticed they have this note (https://github.com/libsdl-org/SDL/pull/4306#issuecomment-889483558):

  • "EGL needs the ability to support [opaque alpha composition and] presentation timeouts"

There's also a Mesa issue related to SDL requirements: "wayland: Implement a timeout extension for eglSwapBuffers" ( https://gitlab.freedesktop.org/mesa/mesa/-/issues/4932 ).

So I was wondering if there are similar problems/requirements between the projects, and a chance to push the required EGL work forward?

No longer blocks: 1635186
Duplicate of this bug: 1728473

I've noticed Xorg EGL is enabled by default with 94b. While this should be better for Mesa users, it leaves Nvidia users with 60fps synthetic vsync timer stutter. Perhaps proprietary driver should be blacklisted for EGL until the vsync situation is sorted?

(In reply to walmartguy from comment #44)

Perhaps proprietary driver should be blacklisted for EGL until the vsync situation is sorted?

Nvidia roleout was backed out again because of bug 1731172, which will need newer drivers :/

@topic: given

  1. the problematic driver situation to implement this feature properly, especially the huge amount of work that would be required to get new extensions implemented in Mesa and the Nvidia driver
  2. the assumption that most users likely only require us to get the refresh rate roughly correct and don't care that much for perfect frame times (as we already always request compositing)
  3. the GLX vsync source does not guarantee sane timings anyway
  4. the GLX vsync source seems to be buggy for some nvidia users
  5. we already have a better solution for Wayland, which is what we care for long term

I'd like to pick up an idea from darkspirit: to use xrandr to query the required refresh rate and use it with the software vsync source. >60Hz monitor people would be happy and we would have a fully non-GLX based solution on all hardware.

Will give that a try.

That sounds like a good idea, but I have 1 question about it.

Can xrandr return correct non-integer refresh rates, like 59.95 Hz, for example? That would be necessary in my particular case, where my monitor can run at 59.95 Hz but not 60 Hz, and the 60 Hz vsync causes periodic ~2s periods every ~10s of stuttering.

(In reply to lexlexlex from comment #46)

That sounds like a good idea, but I have 1 question about it.

Can xrandr return correct non-integer refresh rates, like 59.95 Hz, for example? That would be necessary in my particular case, where my monitor can run at 59.95 Hz but not 60 Hz, and the 60 Hz vsync causes periodic ~2s periods every ~10s of stuttering.

The software timer will unfortunately in many cases not be as exact as hardware feedback, so occasional skips will be hard to avoid, depending on the setup. If that is an issue for you, you'll need to switch to Wayland.

Can we keep the GLX backend unofficially available in about:config? Unfortunately the Nvidia driver lacks lots of features on Wayland, so that'd be a bitter pill (they might support GBM soon, but lots of other things like custom EDID, GPU gamma ramps etc. are probably still far away).
I've got positive experience with hacky timer backed vsync by using a frame rate limiter for games with Vulkan mailbox vsync mode (which Nvidia of course don't support either...), so I'm not generally opposed toward it. It'd of course be a difference if it stuttered once in a few minutes or every few seconds.

Current drivers, both Mesa and prop. Nvidia, miss features on X11/EGL
to implement a proper hardware feedback based vsync. Given the focus
on Wayland by everyone involved, it's unlikely that we'll ever get
everything into a decent shape.

As a best effort alternative, subclass the SoftwareVsyncSource
to run at the refresh rate reported by xrandr. This should allow
us to render at the right refresh rate in most cases, assuming
things don't change at runtime (in which case users would need
to restart FF).

Note: tearing prevention on Linux is always left to the system
compositor, also when using the GLX-based GtkVsyncSource.

Here is a try build for the WIP patch above. If some folks with 120/144Hz monitors could give it a test run, both on Mesa or Nvidia, that would be a great help! To do that, either:

  • run mozregression --repo try --launch 733f2c8507a94dc269f6b3d0af9b3726584dfc3a
  • download the tar ball by clicking Linux x64 opt - B->Artifacts->target.tar.bz2

https://treeherder.mozilla.org/jobs?repo=try&revision=733f2c8507a94dc269f6b3d0af9b3726584dfc3a

You can check the refresh rate at about:support -> Target Frame Rate.

Notes:

  • this does not work on Xwayland because of the missing root window
  • this does not listen to changes - once FF is started, most likely the rate will stay as it is
  • this is also used on Mesa right now, but we'll likely want to stick to the GLX based hardware vsync there when landing
  • the try build includes some unrelated patches as well, shouldn't hurt though

(In reply to Robert Mader [:rmader] from comment #50)

  • this does not work on Xwayland because of the missing root window

Not sure what you mean — Xwayland has a root window (can't be an X server without one :).

(In reply to Michel Dänzer from comment #51)

Not sure what you mean — Xwayland has a root window (can't be an X server without one :).

Err, right, but IIRC it gets a 60Hz software timer from Xwayland, right?

I am not sure if XRRConfigCurrentRate can be used. It is described as legacy method: https://stackoverflow.com/a/38222346
For me (attachment 9242889 [details]), it did not report correct refresh rate on Nvidia after changing the refresh rate and not after rebooting.

https://us.download.nvidia.com/XFree86/Linux-x86_64/495.29.05/README/faq.html

Why is the refresh rate not reported correctly by utilities that use the XF86VidMode X extension and/or RandR X extension versions prior to 1.2 (e.g., xrandr --q1)?
These extensions are not aware of multiple display devices on a single X screen; they only see the MetaMode bounding box, which may contain one or more actual modes. This means that if multiple MetaModes have the same bounding box, these extensions will not be able to distinguish between them. In order to support dynamic display configuration, the NVIDIA X driver must make each MetaMode appear to be unique and accomplishes this by using the refresh rate as a unique identifier.

(In reply to Robert Mader [:rmader] from comment #52)

Err, right, but IIRC it gets a 60Hz software timer from Xwayland, right?

With swap interval != 0, yes, but Firefox uses swap interval 0 with EGL X11 AFAIK, in which case this shouldn't be an issue.

(In reply to Darkspirit from comment #53)

I am not sure if XRRConfigCurrentRate can be used. It is described as legacy method: https://stackoverflow.com/a/38222346

Right, would be better to use RandR 1.2 protocol to get per-output refresh rates. (And pick one of the refresh rates as appropriate, e.g. the highest one)

The WIP build doesn't detect my refresh rate correctly. It's 85Hz, but Firefox detects 50Hz. xrandr lists my 85Hz resolution as following: "2560x1440 85.00*+"

About "Note: tearing prevention on Linux is always left to the system
compositor, also when using the GLX-based GtkVsyncSource." :

This might be specific to GTK (just a guess though, no idea about other UI toolkits), as media players like mpv or games trigger page flipping in fullscreen and thus are free of tearing also without a compositor on Xorg. I've reported it here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1684709
Just mentioning it if chances are that the current work around EGL could be beneficial for that too. :)

Thanks for testing! Updated the patch, can you retest with this build? https://treeherder.mozilla.org/jobs?repo=try&revision=c307ff970173598a7241184396e56d550265e8cd

(In reply to Michel Dänzer from comment #54)

...
Right, would be better to use RandR 1.2 protocol to get per-output refresh rates. (And pick one of the refresh rates as appropriate, e.g. the highest one)

Agreed, did that now. Also realized that XRRConfigCurrentRate only allowed integer values. Now we get doubles for the timer, even though the value in about:support is rounded to integer.

The new test build works surprisingly well, if not perfectly: www.vsynctester.com is free of any stutter for at least one minute (probably longer) and also scrolling on heavier sites like www.ardmediathek.de is smooth too. Looks like full of win at a first glance. :)

Does WebGL require some extra treatment? The result on http://mirrorsedge.dice.se ("Explore the city") still looks like fixed 60fps to me. Though I think this was also the case with the mixed EGL backend + GXL vsync on Mesa drivers lately.

Now I wonder how situation is with decimal value refresh rates. In the wild there should be displays with all kind of weird refresh rates. My display is almost integer 85.000xxHz. With custom resolutions/modelines this should be easy to test.

Walmartguy, were you testing with multiple vsynctester.com windows open simultaneously (separate windows in the same FF instance, not tabs in the same window)? If not, can you please try that as well?

Thanks for testing. I'll also give it a try soon with my 59.95-Hz-display situation.

Flags: needinfo?(tempel.julian)

Multiple vsynctester windows stutter like crazy. However, this is also the case with old GLX backend and also Chromium exhibits this. Or more precisely: With proprietary Nvidia driver. I think the Nvidia Xorg DDX driver is very poorly limited when it comes to handling more than one GPU accelerated window at once. It is really unbelievably bad in this regard. It'd be interesting to see how multiple windows work with the timer solution on e.g. an xf86-video-amdgpu Xorg session, but I don't have such a system.

Flags: needinfo?(tempel.julian)

OK, then it isn't solving the problem. Nvidia/X11/GLX vsync works perfectly with multiple animating windows if FF is started with layout.frame_rate already set to -1 and changed to 0 while it's running. That perfect vsync across multiple windows is the expected behavior with a fix.

(In reply to Michel Dänzer from comment #54)

(In reply to Robert Mader [:rmader] from comment #52)

Err, right, but IIRC it gets a 60Hz software timer from Xwayland, right?

With swap interval != 0, yes, but Firefox uses swap interval 0 with EGL X11 AFAIK, in which case this shouldn't be an issue.

Hmm, do you know what's blocking XWayland from doing proper Vsync when EGL swap interval != 0 ? Shouldn't it be able to properly sync to backing Wayland display instead of the dummy 60 Hz timer..

lexlexlex and walmartguy: could you check if the following try build with an extra patch solves the multi-window stuttering issue? https://treeherder.mozilla.org/jobs?repo=try&revision=2e3a5714cba86486f88672f753bf75693bd266c7

Pasik: it's complicated - probably Xwayland could have some heuristic and try to do a better job in some setups based on output refresh rates. Anyway, offtopic here :)

P.S.:

Yes, it definitely was EGL.
With the new build, WebGL now runs at fluid 85fps. :)
Multi-window stuttering is not improved.

(In reply to walmartguy from comment #64)

With the new build, WebGL now runs at fluid 85fps. :)

Also in the test case where previously it would not? I.e. is there a difference for you between the builds from comment 56 and comment 62?

Turns out the old build already was smooth with the aquarium test. I think it might be that a smooth result on mirrorsedge.com when panning the camera via left/right mouse button is a bit random. Perhaps it doesn't like how rendering might be metered down in case the scene doesn't update when the camera stands still. It is smooth in Chromium and afair also Firefox Wayland/Windows.

(In reply to pasik from comment #61)

Hmm, do you know what's blocking XWayland from doing proper Vsync when EGL swap interval != 0 ? Shouldn't it be able to properly sync to backing Wayland display instead of the dummy 60 Hz timer..

This discussion is specifically about the X11 root window, for which there is no corresponding Wayland entity (with Xwayland in rootless mode). So Xwayland has to fall back somehow, and it currently does to a ~60 Hz timer.

It's working as expected for non-root X11 windows though.

Ok, thanks for the replies.

The obvious choice to get EGL VSync would be to use EGL swap interval == 1, but that doesn't seem to be possible in Firefox due to the $reasons stated in various comments above.. so hmm, I guess that means we should definitely have EGL display timing extension to use, which is cross-vendor, so available in both Mesa and Nvidia at least .. shouldn't we at least open a github issue about that to EGL-Registry? It'll take time sure, but at least the process for that would be started..

There's the existing EGL_CHROMIUM_sync_control extension (implemented in Mesa, but not in Nvidia afaik) and EGL_ANGLE_sync_control_rate extension (spec in EGL-Registry, Mesa MR still not merged / needs more work) .. and also EGL_ANDROID_presentation_time extension for reference.

Thoughts?

Isn't the ANGLE_sync_control_rate MR just using xrandr as well and provides no additional benefit?

Perfection is achieved by using Wayland.
This bug should IMHO be primarily about providing a good enough minimal solution for X11 (as recommended by Nvidia: bug 1716049 comment 63) that allows deprecation of the buggy/duplicate/feature-missing GLX code path and comment 56 seems to be that. There are obviously no resources to maintain everything with better-than-good perfection.
Less maintenance & testing burden means more time for HDR, Raspberry Pi, Wayland, GLX-independent bugs etc.

(In reply to walmartguy from comment #64)

Yes, it definitely was EGL.
With the new build, WebGL now runs at fluid 85fps. :)
Multi-window stuttering is not improved.

Multi-window stuttering seems to occur with Nvidia (bug 1736245): Please try enabling "Force composition pipeline" in Nvidia X Server Settings > X Server Display Configuration > Advanced.

Julian, could you check if the following build improves the multi-window case for you? It has a workaround for bug 1736245 https://treeherder.mozilla.org/#/jobs?repo=try&revision=602d4a93dad6682c05cfd3ae74367d0c55327736

Flags: needinfo?(tempel.julian)

Yes, much better with this build. It can be smooth in both windows at the same time for quite a while. However, it seems by pure chance it sometimes still enters "stutter mode". Both windows then report 85fps (this was not the case with the previous builds), but it's really choppy. I think this is also why randomly mirrorsedge.com WebGL is stuttery, but some other time it is not. I tried to provoke it deliberately, but no dice. When it occurs again I'll try if toggling "Force composition pipeline" helps. Though that's an ugly hack that increases latency of the whole Xorg session, including the hardware cursor. :(

Flags: needinfo?(tempel.julian)
Assignee: nobody → robert.mader
Attachment #9246153 - Attachment description: WIP: Bug 1640779 - [X11][EGL] Implement xrandr-based software vsync → Bug 1640779 - [X11][EGL] Implement xrandr-based software vsync, r=stransky,#gfx-reviewers
Status: NEW → ASSIGNED
Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/43103b364829
[X11][EGL] Implement xrandr-based software vsync, r=stransky,gfx-reviewers,jrmuizel
No longer blocks: 1588589
Duplicate of this bug: 1588589

Backed out for causing reftest and mochitest failures.

Push with failures

Failure log for reftest
Failure log for mochitest-plain

Backout link

Flags: needinfo?(robert.mader)
Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/0b588effab6c
[X11][EGL] Implement xrandr-based software vsync, r=stransky,gfx-reviewers,jrmuizel

Tested 9f92b722a1c3d41f2651123b349ac8014e1eac01:
I think situation with Nvidia multi window stutter is unchanged. I've also tested with my default 59.95Hz refresh rate: Unfortunately there is stutter every x seconds, apparently because rendering is metered to integer 60fps. So with typical 59.xxHz refresh rates, the new timer solution unfortunately doesn't improve things (makes things for Mesa Xorg users quite worse).

Imho GLX vsync for the EGL backend should be kept for Mesa users, at least the last time I checked it worked without issues for me. As an Nvidia user myself, I really wouldn't want to see situation for Mesa Xorg users worsened due to the grotesque limitations of the Nvidia driver. :(

(In reply to walmartguy from comment #79)

Tested 9f92b722a1c3d41f2651123b349ac8014e1eac01:
I think situation with Nvidia multi window stutter is unchanged. I've also tested with my default 59.95Hz refresh rate: Unfortunately there is stutter every x seconds, apparently because rendering is metered to integer 60fps.

Where did you check that an integer refresh is used?

All refresh rates, "integer" or not, will have some stutter "every x seconds" (not necessarily consistent) - the pixel clock and software timers will never run at the same speed. Plus, most "integer" refresh rates are just rounded off in the first place, as the pixel clock from a given mode rarely aligns to become an integer refresh rate. Even your 59.95 is likely rounded off and inaccurate.

That being said, unless Nvidia adds support for some of the EGL extensions needed for X it seems unlikely that we'd go for something better. Keeping GLX around is a burden.

You can check real refresh rate with vsynctester.com and GLX backend. It should ~never stutter and thus show the real refresh rate. Which in the case of my default EDID is 59.9506xxHz. Should be very representative for other devices, as it uses most common display timings. With refresh rates with decimal place like 59.95Hz, I suppose the margin for rounding without stutter is lower than with integer refresh rates (like the 85Hz via custom resolution that work much better with the new timer sync). I'd expect stutter every 5-15s with the new timer approach for a vast majority of users due to this.

(In reply to walmartguy from comment #79)

Tested 9f92b722a1c3d41f2651123b349ac8014e1eac01:
I think situation with Nvidia multi window stutter is unchanged.

Nvidia multi-window stutter is tracked in bug 1716049 and bug 1736245 and unrelated to the work here. The build from comment 70 had a workaround for bug 1736245.

Imho GLX vsync for the EGL backend should be kept for Mesa users...

That's what the patch that's currently landing does. GLX vsync is used:

  1. on GLX
  2. on EGL on Mesa
  3. not on Xwayland, as there we just get a software timer from Xwayland for the root window.

In other words: this patch should not regress cases where the GLX vsync previously worked. It only exchanged the ~60Hz vsync timer with one closely matching the highest refresh rate.

Blocks: 1737428
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch

I read the changes in the commit linked above and noticed that it says it will detect the display with the highest refresh rate, with the following comment as rationale for that:

     // Request the current refresh rate via xrandr. It is hard to find the
     // "correct" one, thus choose the highest one, assuming this will usually
     // give the best user experience.

In my case, though, the correct display is my primary display, which is 59.95 Hz and my secondary display is 60 Hz. I've tested with that commit built into Nightly (firefox-nightly-95.0a1.20211023211445+h226ea4af4493-1) with my configuration and it gave me the expected result, which is a bug. It synchronizes to 60 Hz while running on the 59.95 Hz primary display, which is incorrect, and causes periodic ~2-second periods of stuttering every ~10 seconds.

While I'm not sure about the exact implementation using the xrandr API, I argue that detecting the correct display is probably relatively easy. At least, I can find out what it is simply by typing xrandr into the terminal, so I'm sure the API can provide that information as well. Here's that output:

[alex@alex-pc ~]$ xrandr
Screen 0: minimum 8 x 8, current 5760 x 2160, maximum 32767 x 32767
DVI-D-0 connected primary 1920x1200+3840+960 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1600x1200     60.00  
   1440x900      74.98    59.89  
   1280x1024     75.02    60.02  
   1280x800      74.93    59.81  
   1280x720      60.00  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   640x480       75.00    72.81    59.94  
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
DP-3 disconnected (normal left inverted right x axis y axis)
DP-4 disconnected (normal left inverted right x axis y axis)
DP-5 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 708mm x 398mm
   1920x1080     60.00*+  59.94    29.97    23.98    60.05    60.00  
   1360x768      60.02  
   1280x1024     75.02    60.02  
   1280x768      74.89    59.99    59.87  
   1280x720      59.94  
   1024x768      75.03    70.07    60.00  
   800x600       75.00    72.19    60.32    56.25  
   720x480       59.94  
   640x480       75.00    72.81    59.94    59.93  
[alex@alex-pc ~]$

As we can see here, the primary display is clearly labelled "primary" in DVI-D-0 connected primary and the current resolution and refresh rate is indicated with an asterisk. My other display, which I have off to the left just to monitor chats, is clearly not labelled "primary".

As a result, I believe the implementation here could be improved to fix this bug by detecting which display is primary, which xrandr can do, and using that display's refresh rate as the "correct" refresh rate, instead of just whatever's highest.

Alternatively, just letting the about:config layout.frame_rate variable store and use float values might help.

This all being said, I'm sure this will help plenty of users who have less esoteric configurations as-is. Thanks for the work.

(In reply to lexlexlex from comment #84)

...
In my case, though, the correct display is my primary display, which is 59.95 Hz and my secondary display is 60 Hz. I've tested with that commit built into Nightly (firefox-nightly-95.0a1.20211023211445+h226ea4af4493-1) with my configuration and it gave me the expected result, which is a bug. It synchronizes to 60 Hz while running on the 59.95 Hz primary display, which is incorrect, and causes periodic ~2-second periods of stuttering every ~10 seconds.

Hm, I don't really see how this mismatch would result in a 2-second period of stuttering. On what DE/config is that? Too me it sounds like a compositor bug.

...
As a result, I believe the implementation here could be improved to fix this bug by detecting which display is primary, which xrandr can do, and using that display's refresh rate as the "correct" refresh rate, instead of just whatever's highest.

I ask around a bit and apparently there's no guarantee that a compositor syncs to the primary display. Do you have any source that claims otherwise? If so, I'd be happy follow up with a corresponding patch.

Alternatively, just letting the about:config layout.frame_rate variable store and use float values might help.

Note that the software timers that are available to us here are not very high in precision - were are talking milliseconds here, not microseconds[1]. AFAICS there shouldn't really be a difference between 59.95 and 60 Hz in practice - unfortunately :/

1: https://searchfox.org/mozilla-central/source/gfx/thebes/SoftwareVsyncSource.cpp#130-131

I went ahead and opened an issue in EGL-Registry anyway. Let's see if it results in discussion about how to improve the EGL vsync situation in Linux, and get it working cross-vendor.

"EGL cross-vendor Display Timing / Presentation timing extension for Linux":
https://github.com/KhronosGroup/EGL-Registry/issues/139

(In reply to lexlexlex from comment #84)

As a result, I believe the implementation here could be improved to fix this bug by detecting which display is primary, which xrandr can do, and using that display's refresh rate as the "correct" refresh rate, instead of just whatever's highest.

Can you check if it is smooth with the 59.95Hz display when the 60Hz display is not connected at all?

Flags: needinfo?(lexlexlex)

(In reply to walmartguy from comment #87)

(In reply to lexlexlex from comment #84)

As a result, I believe the implementation here could be improved to fix this bug by detecting which display is primary, which xrandr can do, and using that display's refresh rate as the "correct" refresh rate, instead of just whatever's highest.

Can you check if it is smooth with the 59.95Hz display when the 60Hz display is not connected at all?

Oh, the result is unexpected here. I tried shutting down the machine, unplugging the 60Hz display, booting with only the 59.95Hz display, then running the same Firefox Nightly (firefox-nightly-95.0a1.20211023211445+h226ea4af4493-1) version which has that change, and vsynctester.com still showed 60 Hz in 2 windows, with periodic stuttering.

For comparison, I tried the same test in Chromium and both Chromium windows vsync perfectly, with no periodic stutter and correct 59.95 Hz refreshing. So, this seems to me like evidence that it's not an Nvidia driver issue, an EGL issue, or an X11 issue. It's a Firefox issue. Firefox could vsync perfectly with multiple windows animating like Chromium can in the exact same environment if implemented correctly.

Thanks for the work so far, and I hope the investigation into what makes Firefox vsync incorrect continues to its conclusion. I'm happy to test Nightly builds with fix attempts.

Flags: needinfo?(lexlexlex)

lexlexlex: To make sure that the periodic stutters are not a rendering issue (the moving image on that site is quite heavy and AFAIK an unusual case - maybe WR does not optimize it as well as Chromium), can you also check https://www.testufo.com/animation-time-graph (if you also see stutter/frame drops there)?

Concerning the rest: it would be great to get perfect vsync like chromium but AFAICS it would require a lot of effort. It's unlikely that I personally will have time and motivation for that as I'd rather work on getting the Wayland backend shipped by default. But if somebody else is willing to look into it, please feel invited :)

lexlexlex, I was thinking about single display single window test with 59.95Hz. Is that really smooth for you for longer than a few seconds?

Well, at least with "integer" like refresh rates, the new timer sync is much better than the old fixed 60fps approach. That makes sticking around with old Xorg for the teime being much more bearable, thanks @Robert! :)

(In reply to Robert Mader [:rmader] from comment #89)

lexlexlex: To make sure that the periodic stutters are not a rendering issue (the moving image on that site is quite heavy and AFAIK an unusual case - maybe WR does not optimize it as well as Chromium), can you also check https://www.testufo.com/animation-time-graph (if you also see stutter/frame drops there)?

I performed the same test but with testufo.com/animation-time-graph instead and got a constant repeating "SYNC FAILURE: Move all apps and browser windows to primary monitor #1.". This is while no other monitors were connected.

That being said, performance is evidently not an issue on my GTX 1080 Ti on vsynctester.com. My conclusion is drawn from the fact that if I start the browser with layout.frame_rate already set to 0, each of the 2 windows running it runs uncapped at rates above 200 Hz.

Concerning the rest: it would be great to get perfect vsync like chromium but AFAICS it would require a lot of effort. It's unlikely that I personally will have time and motivation for that as I'd rather work on getting the Wayland backend shipped by default. But if somebody else is willing to look into it, please feel invited :)

This is perfectly understandable and I recognize and appreciate your charitable voluntary time and energy donation here, as I do for all FOSS development. I only aim to clarify observed behavior and help the project avoid concluding a fix incorrectly in some configurations. Thank you for what you've done and the extra energy you've spent discussing this further.

lexlexlex, I was thinking about single display single window test with 59.95Hz. Is that really smooth for you for longer than a few seconds?

From all my testing, including my most recent testing with the latest Nightly, the only 2 ways I can make it smooth and synchronize perfectly to 59.95 Hz are the following:

  1. For multiple windows, with these settings:
    • EGL force-disabled by having gfx.x11-egl.force-disabled set to true
    • Firefox started with layout.frame_rate set to -1 before closing the previous session, then set to 0 during the current session.
  2. With only a single window (even if it has multiple tabs), with these settings:
    • EGL force-disabled by having gfx.x11-egl.force-disabled set to true
    • Firefox started with layout.frame_rate set to -1

If EGL is enabled, on Firefox Developer Edition 94 or on Nightly 95 with this latest change, single or multiple windows always use exactly 60.000 Hz, and while the graph on vsynctester.com turns green as if it's synchronizing perfectly, it drops frames for about 2 seconds every 10 seconds, and I can tell because the "VSYNC" text there turns cyan and red repeatedly. All permutations of my testing with EGL enabled have had this problem.

Hm, I don't really see how this mismatch would result in a 2-second period of stuttering. On what DE/config is that? Too me it sounds like a compositor bug.

My best guess as to why this happens is that the timing happens to line up for a while (like about 8 seconds) so that perfect timing happens, and then as the timing approaches the time between frame boundaries, there's a period when the jitter is enough to sometimes cause drops and sometimes not, until there's nothing close again and it becomes smooth again. I'm sure you could imagine the 2 graphs of 60 Hz and 59.95 Hz synchronizing for a while, then becoming close enough that microsecond jitter is enough to desynchronize for a while, then synchronizing again.

Lexlexlex: can you give the following build a try? It may improve the situation for you by doing a trivial adjustment. https://treeherder.mozilla.org/jobs?repo=try&revision=334d9881d78863991d956143fc98cbbf9a0fafc3

OK, I tried that one using `mozregression --repo try --launch 733f2c8507a94dc269f6b3d0af9b3726584dfc3a`.  It seems to also run at 60.000 Hz here, and have periodic frame-drop periods.  Here's the `about:support` info from it.

Oh, I might have run the wrong build, since I copied the command from above. Let me retry that with the right hash.

OK, no, I'm pretty sure I ran the right build.  Here's the about:support info again, this time definitely with the correct hash, using `mozregression --repo try --launch 334d9881d78863991d956143fc98cbbf9a0fafc3`.

(In reply to lexlexlex from comment #95)
Please compare with Nouveau. IIUC, it should be fine.

Proprietary Nvidia:

Regressions: 1737499

Shouldn't the status of this issue be marked incomplete until the patch for bug 1737499 is applied? The fix for this issue crashes firefox in my Ubuntu 16.04 environment.

This is still not fixed in the latest Nightly as of right now. I've tested it again. It's still using a hard 60 Hz when my display is not that, causing periodic 2-second periods of many dropped frames, and there's no workaround for this issue. GLX has a workaround for its multi-window issue, so I am continuing to use that for usable synchronization.

See Also: → 1734958

Found out something weird: Panning the camera via holding down mouse buttons on the Mirror's Edge site is stuttery when website zoom level is 100% or 110%. When setting it to 120% or 130%, it is smooth. I wonder if this could be related at all to the specific EGL backend + timer vsnyc, or if it isn't entirely unrelated. It's not related to GPU power saving.

http://mirrorsedge.dice.se/#/map

Can this be reopened until it properly vsyncs? See comment 98.

(In reply to lexlexlex from comment #100)

Can this be reopened until it properly vsyncs? See comment 98.

No, this is not a meta bug. This bug's problem is solved (bug 1716049 comment 63). bug 1737499 comment 20 then allowed to get 59.95 Hz instead of enforcing 60 Hz as minimum refresh rate.

bug 1736245 is the most noticeable Nvidia EGL bug.
Nvidia confirmed another driver problem in bug 1716049 comment 70.
Filed bug 1742533 because I remembered a chat conversation about backpressure. (I'm not a developer.)
A new bug should be filed if there is a remaining Nvidia EGL bug after these.

This bug's problem is solved.

This ticket's issue is not resolved. There is no vsync with EGL here on my primary display. It is refreshing at 60 Hz without caring about when the vertical blank is happening. This is reproducible consistently, and causes many dropped frames every ~10 seconds for ~2 seconds.

bug 1736245 is the most noticeable Nvidia EGL bug.

How "noticeable" the issue is to someone else is irrelevant. The issue is that there is no vsync here. There is refreshing at a particular fixed rate, but that is not what vsync means. The refresh must happen inside the monitor's vertical blank time, and not some arbitrary time.

(In reply to lexlexlex from comment #102)

The issue is that there is no vsync here. There is refreshing at a particular fixed rate, but that is not what vsync means. The refresh must happen inside the monitor's vertical blank time, and not some arbitrary time.

That's solved by MOZ_ENABLE_WAYLAND=1 (bug 1629140).

This issue ticket is called "[X11][EGL] Add EGL VSync implementation". The "X11" part means that it uses X11, not Xwayland or wayland. Therefore, enabling Wayland is not a solution to this issue.

This bug did (for EGL/X11/proprietary Nvidia) what Nvidia recommended.

(Arthur Huillet from bug 1716049 comment #63)

I also kind of distrust the phase of the "hardware" vsync thread. Have you guys ever ensured that it was reliable? What I understand of the design makes me think that it isn't, and that could explain part of the problem here too. I'd personally expect that a software timer with the right phase is likely to be more reliable than a thread trying to get HW vsync timing every frame, because you get into overhead and scheduler woes.

Some alternatives:

  • Using X11 on Mesa Nouveau.
  • Using MOZ_ENABLE_WAYLAND=1 (bug 1629140).
  • Filing a bug and investing time for an X11-only proprietary-Nvidia-only EGL hardware vsync solution.

This bug did (for EGL/X11/proprietary Nvidia) what Nvidia recommended.

I'm sure Nvidia does not "recommend" vsync issues, and insinuating that they do is wasteful. There are other browsers in my same desktop that vsync correctly, including Chromium.

Your options:

By posting my comments, I am not looking for support. This is not a support thread. This is an issue ticket. I'm explaining that the issue is not resolved and requesting that the issue ticket be reopened. Filing a new issue about an issue that is closed incorrectly makes no sense and loses the history of the issue. Instead, this one should be reopened.

(In reply to lexlexlex from comment #106)

There are other browsers in my same desktop that vsync correctly, including Chromium.

(How) Do you have enabled EGL/X11 in Chromium and does it really provide hw vsync on proprietary Nvidia?

Filing a new issue about an issue that is closed incorrectly makes no sense and loses the history of the issue. Instead, this one should be reopened.

This bug landed a patch, it should not be re-opened.
An EGL hardware vsync solution for legacy X11 with proprietary Nvidia driver was not found, so it got a minimal solution.
Removing GLX_SGI_video_sync usage and relying on a software timer was already considered multiple times in the past in the light of problems.
It's still the default for software rendering.
comment 78 even provided the correct refresh rate. It's the best that could be done so far.

Please file a new bug for EGL hw vsync on legacy X11 with proprietary Nvidia driver and put this bug in See Also.
In case ordinary EGL/X11/proprietary Nvidia users perceive the software timer as a regression, the bug should block bug 1737428, but there haven't been other regression reports when EGL/X11 was turned on for Nightly and early Beta.

(In reply to Darkspirit from comment #107)

(In reply to lexlexlex from comment #106)

There are other browsers in my same desktop that vsync correctly, including Chromium.

(How) Do you have enabled EGL/X11 in Chromium and does it really provide hw vsync on proprietary Nvidia?

I don't use Chromium as my main browser, so I have no settings changed whatsoever, and testing in vsynctester.com shows consistent perfect vsync, regardless of the number of windows animating. Chromium also shows a vsync graph that makes more sense without the "notches" that it shows in Firefox.

Chromium clearly has a better default implementation, and Firefox could do well to adopt something like its implementation. In Firefox, the only way to get almost-perfect vsync (though still with the "notches" in the graph, showing incorrect implementation) is to force GLX and set gfx.swap-interval.glx to false.

This bug landed a patch, it should not be re-opened.

That is absolute nonsense. So if any patch was applied, regardless of whether it worked, a ticket should be closed? So if we changed 1 character in the code that didn't affect behavior or compilation whatsoever, but it was a patch, the ticket should be closed? Where do we draw the line?

The fact is that this is still not vsyncing with EGL on X11 and I can consistently see this behavior, so "[X11][EGL] Add EGL VSync implementation" is not resolved. It makes no sense to say that just because there was any patch, the ticket should be closed. That's not how issues get resolved. The patch has to address the issue it's intended to address.

I'm not saying the patch wasn't great work. It clearly had an effect and I'm almost certain it's very close to enabling vsync with EGL in X11. I have mad respect for Robert Mader and anyone else who contributed. I'm not telling anyone to do extra work or demanding any work whatsoever from anyone else. I'm only requesting that the situation be acknowledged that the issue in this ticket is not resolved and so it should be reopened instead of being closed, which makes it seem like EGL in X11 vsyncs, which I can consistently see that it doesn't.

Stop arguing - it's not productive, annoys everyone CC, and only makes it less likely that the issue gets the positive attention needed to resolve it.

Even if this issue should not have been closed, your problem would still belong in a new related issue for the sake of tracking work and discussion properly.

Telling someone to stop discussing something doesn't resolve the discussion. If someone who is CCed is annoyed, they can and should remove themselves from the CC list, since being annoyed by discussion about an issue not being resolved means they are no longer interested in the status of issue.

Tracking the work and discussion properly makes the most sense in this ticket, where some work was done and is still incomplete. It makes less sense to start a new one when this is the one that is not yet resolved. If a new one was opened, this one would still be closed, meaning the issue tracker would have this ticket closed, which communicates that the issue this ticket was tracking was resolved, which is not true.

Renamed the bug to better reflect what the actual patch ended doing.

@lexlexlex: please feel free to open a new issue for better/real vsync.

Summary: [X11][EGL] Add EGL VSync implementation → [X11][EGL] Detect (roughly) correct screen refresh rates

That makes sense. Thanks.

@lexlexlex please link the new issue here when done!

Duplicate of this bug: 1711166
See Also: → 1744896

Not sure if it was this bug in particular, but Firefox 95 broke frame rate detection on Wayland for me.
I have a 180hz monitor and Firefox 94 properly rendered at 180 fps with buttery smooth perfection (with layout.frame_rate set to the default of -1), as tested on sites such as https://www.testufo.com/.

But now, after updating to 95, it is only rendering at 120 fps with terrible results at https://www.vsynctester.com
If I try to force 180 fps in layout.frame_rate it's even worse, as I get stutters.

What can I do to get the old behavior back until this is fixed?

This is on Manjaro KDE, using Wayland.

My bad. Seems what I described has already been listed as a bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1744896

Duplicate of this bug: 1705695
Duplicate of this bug: 1389491
You need to log in before you can comment on or make changes to this bug.