https://www.vsynctester.com/ fails miserably in epiphany; it was reported that vsync is locked at 60fps and this test fails, but the epiphany devs bounced the issue to WebKitGTK: https://gitlab.gnome.org/GNOME/epiphany/issues/833. Is there a way to improve VSYNC in WebKitGTK? By the way, I built epiphany 3.35.2 against webkit2gtk 2.26.2-2 in Archlinux to reconfirm the test results ("CATASTROPHIC VSYNC FAILURE").
For what its worth Chrome, Firefox, and WebKit all fail here (Fedora 30, GNOME-Shell, X11).
Ah I see your Epiphany report already showed that. My results for Epiphany are much more stable than yours and it never triggered the "CATASTROPHIC" warning.
@Patrick Griffis There a few layers to consider: 1. The browser and its backend. Repeating the test I performed above, *most of the time* I get "catastrophic failure", but not every time; the red/blue 'VSYNC' (which should appear gray) fails consistently. In any case, epiphany's (webkit's) performance is dismal in comparison to firefox (mozilla) (70.0.1-3 from Archlinux's [extra] repository), which never reports "catastrophic failure" and only occasionally has a performance droop on the 'VSYNC' test (gray most of the time). I haven't personally tested Chrome, but bug report linked above shows fairly recent results for Chromium (blink, v8), which passes with flying colors on a 140hz display. 2. Display server, window manager, and compositor. Probably should not matter, but I have a feeling it does. I'm using X11 and have run the tests in openbox and compiz; I have not tried Wayland. I do know what the case is for the similar results in the linked report against epiphany. 3. Drivers. Also should not matter, but probably does. I tested on proprietary nvidia drivers. I do not know if that is the case for the similar results in the linked report against epiphany. The linked bug report is more specifically focused on vsync being locked at 60fps, which is a problem for higher-frequency displays. I think trying to force a particular frame rate in WebkitGTK may be causing another, more serious, problem: epiphany suffers dismal vsync performance in comparison to other browsers. I often have serious visual lag doing other things in epiphany, such as watching a video, dragging an object, or typing in an input box. Better vsync might not be a cure-all for such issues, but it would help and at the least close one of many angles from which to investigate them.
I detected a regression in the fps numbers when testing a 2.26 build that could be explained because of this. Also, on a fast test with trunk, I'm getting around 20fps on the test page when I should be getting 60fps. Let me look into this.
I've been giving this a look. There are several things that are happening here: - The page does a lot of canvas rendering to stress the browser and check whether it's able to keep up with the display frequency. The default behavior, while works fine on chrome and firefox, is too heavy for wkgtk (or wpe). The canvas rendering operations take too long to achieve 60fps. It gets much better disabling the background images option, which disables the canvas rendering. But.. - The page doesn't trigger AC mode. In this situation, there seems to be a problem detecting the display frequency and the framerate gets stuck at ~26fps. But using the Custom framerate option and setting it to 60 works fine. There must be some problem detecting the display frequency in non AC mode. - If AC mode is forced (with WEBKIT_FORCE_COMPOSITING_MODE=1) and disabling the background images, the display frequency is detected as ~56Hz and the framerate follows that value. Using a custom value works fine as well. So, two things to look into: - why the low performance on the canvas paintings in comparison with chrome and firefox (the execution of the rAF callback takes ~45ms, which is a lot, it should be under 16ms to get to 60fps) - why the display frequency is not properly detected when in AC mode
> So, two things to look into: > - why the low performance on the canvas paintings in comparison with chrome > and firefox (the execution of the rAF callback takes ~45ms, which is a lot, > it should be under 16ms to get to 60fps) > - why the display frequency is not properly detected when in AC mode no properly detected in *non* AC mode. I'll keep looking into this, see what I can find.
*** This bug has been marked as a duplicate of bug 199376 ***