Severe scroll jank/stalls with vsync-driven refresh; fixed layout.frame_rate fixes it

Bug Reports
,
1

REPRODUCIBILITY: Always (on heavy sites)
OS VERSION: 5.2.0.20
HARDWARE: Jolla Phone (2026), display 1032x2272 @ 90 Hz, Mali-G610 MC2
UI LANGUAGE: Norwegian (nb_NO)
REGRESSION: Unknown

DESCRIPTION:

sailfish-browser stutters heavily when scrolling and sometimes stalls completely on heavier sites (e.g. outland.no, warhammer.com). During the stalls CPU and GPU are mostly idle. Forcing a fixed frame rate in about:config improves it drastically, which suggests the vsync source in EmbedLite/Qt is missing or irregular on this device.
Versions: sailfish-browser 3.0.3-1.24.1, xulrunner-qt5 115.40.0

PRECONDITIONS:

STEPS TO REPRODUCE:

  1. Open outland.no in the browser with default settings (layout.frame_rate = -1)

  2. Scroll the page

EXPECTED RESULT:

Smooth scrolling at the display refresh rate (90 Hz).

ACTUAL RESULT:

Heavy stutter and stalls of up to several seconds.

Forcing a lower fixed frame rate in about:config improves it drastically. Default (vsync-driven, 90 Hz) and layout.frame_rate = 90 both stall badly; layout.frame_rate = 60 makes the same pages usable. The rendering pipeline apparently cannot sustain 90 Hz on heavier pages, and instead of dropping frames gracefully it degrades into multi-second stalls (frame backlog?) while CPU and GPU stay mostly idle.

MODIFICATIONS:

ADDITIONAL INFORMATION:

- Patchmanager: no - OpenRepos: yes - Chum: yes - Other: none affecting the browser

11 Likes
2

Can confirm: with the default value https://yle.fi has bad stuttering and sometimes freezes. With 60Hz the stutter is gone.

3 Likes
3

You are a lifesaver, honesty. This issue has been the one reason that has made me reconsider if i can daily drive this phone. The browser needs to work flawlessly to make up for the need to use browser based services more often due to the limited amount of native applications for those services.

A great demonstrator for this is the Finnish news site mtvuutiset.fi. It locks up the entire browser for multiple seconds at a time, including the browser UI outside the viewport. Setting the frame rate to 60 immediately makes the issue disappear. Edit: Well, not completely. Leisurely scrolling is alright, but i just made the entire browser lock up of over a minute by just fast scrolling the page until it stopped responding. Had to close the application and it wouldn’t start after that anymore before rebooting the whole OS. Dropping the rate to 30 reduces the lockups even more, but of course with the sacrifice of smooth scrolling overall. No doubt this is mainly due to the website just being unoptimized and an outlier from what i’ve tested, but still something to fix on the browser side.

4

Yes, a lot better with this adjustment. Great!