Summary: | [GTK][WPE] View is locked to 60 FPS | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | grmat | ||||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | NEW --- | ||||||||||
Severity: | Normal | CC: | bugs-noreply, cgarcia, magomez, mcatanzaro, pnormand, quequotion, yalterz, zan | ||||||||
Priority: | P2 | ||||||||||
Version: | Other | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
Attachments: |
|
Description
grmat
2019-07-01 13:58:11 PDT
Created attachment 373257 [details]
vsynctester screenshot firefox
Created attachment 373258 [details]
vsynctester screenshot chromium
The same happens in WPE with vsynctester vsynctester is more of a test on performance of the panning animation. Cairo operations there are slow enough to drop the FPS rate. https://www.displayhz.com/ is a lighter test for achievable refresh rate. WPE's limit is the refresh rate established by the compositor or the embedding application. GTK's limit is I think a mix between the fallback timer (used in non-AC mode, hard-coded to 60 FPS) and what the toolkit can provide. displayhz.com also erroneously reports 60 Hz for a 144 Hz screen. The embedding application (Epiphany) redirected me to WebkitGTK, as you can see in the initial description. Are you saying the issue lies within GTK itself? Correct me if I'm wrong but Firefox also uses GTK and isn't locked to 60 FPS. No, Epiphany is not a WPE embedder. Zan is saying that we have a timer hardcoded to 60fps. *** Bug 204552 has been marked as a duplicate of this bug. *** |