[Webkit-unassigned] [Bug 204552] [GTK] Catastrophic VSYNC failure
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Nov 25 19:33:58 PST 2019
https://bugs.webkit.org/show_bug.cgi?id=204552
--- Comment #3 from Que Quotion <quequotion at gmail.com> ---
@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.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20191126/4dcadb51/attachment.htm>
More information about the webkit-unassigned
mailing list