Stuttering smooth scrolling with mouse wheel and autoscroll
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
People
(Reporter: go.danilll, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(5 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0
Steps to reproduce:
Open https://meteologix.com/uk/weather/2643743-london and scroll.
Actual results:
Stutters happens on wide range of sites, sometimes randomly. Given example is a good one, because it's always stutters there.
With this bug I want to continue investigation in https://bugzilla.mozilla.org/show_bug.cgi?id=1761812 . Same distribution and GPU might help resolving.
Expected results:
Scroll should be smooth as it was in Firefox 97 with glx. Any further version (up to 105 - current nightly) have this bug, no matter glx or egl is used.
|
||
Comment 1•3 years ago
|
||
Can you use https://mozilla.github.io/mozregression/ to determine the commit that caused this?
(In reply to Timothy Nikkel (:tnikkel) from comment #1)
Can you use https://mozilla.github.io/mozregression/ to determine the commit that caused this?
|
||
Updated•3 years ago
|
|
||
Comment 3•3 years ago
|
||
I think this will be fixed (at least it should be mitigated) by bug 1753334.
|
||
Comment 4•2 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)
I think this will be fixed (at least it should be mitigated) by bug 1753334.
Hi, I built firefox using changes found here: https://phabricator.services.mozilla.com/D138245 and it didn't improve anything for me. I got the new pref "gfx.webrender.prefer-one-frame-delay" but it didn't fix nor mitigate the bug described above.
I have observed this bug on every Linux distribution, both with Nvidia and AMD graphics, every Firefox version since 98 is affected. It's more visible on certain sites but the stutters are present on every site that has some scroll-linked effects (at least I think so). I found that enabling "layers.gpu-process.enabled" somehow reduces the stutters a bit but it tanks the performance in gpu-rendering browser benchmarks.
I attach two videos of the same machine running respectively Linux and Windows:
|
|
||
Comment 5•2 years ago
|
||
|
|
||
Comment 6•2 years ago
|
||
|
|
||
Comment 7•2 years ago
|
||
Did you change the new pref value? Even with gfx.webrender.prefer-one-frame-delay:false the laggy scrolling you saw still persist, then it's a different issue since this bug aims to fix the issue caused by bug 1753334, and gfx.webrender.prefer-one-frame-delay:false reverts bug 1753334 basically.
|
|
||
Comment 8•2 years ago
|
||
Yes, I tried both true and false but didn't notice any difference. I am 100% sure that the issue described by OP is exactly the one I have though.
|
|
||
Comment 9•2 years ago
|
||
Can you please file a new bug for the issue you are seeing? And if it started happening recently, finding out the commit caused the issue by using mozregression (https://mozilla.github.io/mozregression/) would be super helpful. Thanks!
|
|
||
Comment 10•2 years ago
|
||
Of course I can do that but is it a good idea if it's the same issue? It started happening after update to 98 (as OP said). Wouldn't mozregression produce the same output then?
|
|
||
Comment 11•2 years ago
|
||
Sorry if it sounded rude, I didn't intend that. I will happily provide everything needed to help solve this bug, but I wonder if I should file a new bug even if what OP describes seems to be the same thing that I experience?
|
|
||
Comment 12•2 years ago
|
||
Oh okay. I missed an important part in the first your comment, that is "on every site that has some scroll-linked effects (at least I think so)". So bug 1753334 will only affect sites where there's no scroll linked effects. What you want precisely will break scroll linked effects, anyway it would be nice to open a new bug for your case. (And setting "apz.disable_for_scroll_linked_effects" to true will resolve your case I think)
|
|
||
Comment 13•2 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #12)
Oh okay. I missed an important part in the first your comment, that is "on every site that has some scroll-linked effects (at least I think so)". So bug 1753334 will only affect sites where there's no scroll linked effects. What you want precisely will break scroll linked effects, anyway it would be nice to open a new bug for your case. (And setting "apz.disable_for_scroll_linked_effects" to true will resolve your case I think)
I already tried apz.disable_for_scroll_linked_effects and sadly it didn't help, I will try again tomorrow when I get to my PC. It's only an assumption that scroll linked effects are the culprit, it's based on some info from other threads. What I know for sure is that it doesn't stutter on Windows but stutters on Linux (with Firefox 98 onward). OP described the same issue and is also using Linux (as every person that reported this).
Is there any clue to why it happens only with linux?
Do you have any suggestion how I can test if scroll-effects are the cause?
|
|
||
Comment 14•2 years ago
|
||
If setting "apz.disable_for_scroll_linked_effects" to true didn't help, it's unlikely related to scroll linked effects. Presumably it's a gfx backend issue? Anyway, filing a bug with a profile result would be a first step.
|
Reporter | |
Comment 15•2 years ago
|
||
Recently I did build Firefox with https://phabricator.services.mozilla.com/D138245 changes, the 109.0 version. It didn't fix the issue for me too. And setting "apz.disable_for_scroll_linked_effects" didn't help. So maybe this bug is initially due to the gfx backend and profile result will be appropriate here? I can also run profiling, but later.
|
|
Reporter | |
Comment 16•2 years ago
|
||
Here are the profiles. Half of the time I scrolled with the mouse wheel, the other half with autoscroll.
https://meteologix.com/uk/weather/2643743-london
https://share.firefox.dev/3HawIKV
https://svelte-native.technology
https://share.firefox.dev/3wa4NEC
|
|
||
Comment 17•2 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #14)
If setting "apz.disable_for_scroll_linked_effects" to true didn't help, it's unlikely related to scroll linked effects. Presumably it's a gfx backend issue? Anyway, filing a bug with a profile result would be a first step.
I created bug 1810874 and uploaded profiles
|
|
Reporter | |
Comment 18•2 years ago
|
||
In addition, enabling "apz.disable_for_scroll_linked_effects" make scroll even less smooth. With that setting, scrolling have periodic latency spikes, that looks like freeze. Without it, scrolling just stutters, without latency spikes.
Profile with spikes. Using autoscroll on meteologix:
https://share.firefox.dev/3iSM11s
|
|
Reporter | |
Comment 19•2 years ago
|
||
Since the proposed solutions do not help, I decided to try to go through mozregression a few more times. Strangely, the results vary. Mozregression_gui showed more wide pushlog twice. Although the terminal version of mozregression showed different pushlogs.
mozregressiongui:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=01e8e7b4512f888a96186ef1c6e5a9e5daaff154&tochange=810c8e698b78727dcce406da3c467cb05109f6e8
mozregression_2:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d67fe3d4744222155a5f3b669bfd206944216535&tochange=01e8e7b4512f888a96186ef1c6e5a9e5daaff154
mozregression_3:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0d1fca9799ac3cf0003224c960cb1a6b6ba1c068&tochange=ee9cb1095b2c72f7d834303e4a05ec45b98d1420
In mozregression_4 the result is same as in first attached mozregression.
Sorry for the flood and ambiguity. This bug is sometimes hard to see.
|
|
||
Comment 20•2 years ago
|
||
(In reply to ducaton from comment #18)
In addition, enabling "apz.disable_for_scroll_linked_effects" make scroll even less smooth. With that setting, scrolling have periodic latency spikes, that looks like freeze. Without it, scrolling just stutters, without latency spikes.
Profile with spikes. Using autoscroll on meteologix:
https://share.firefox.dev/3iSM11s
Yes, I can confirm that's exactly what I experience as well
|
|
Reporter | |
Comment 21•2 years ago
|
||
It turned out that xfce have issues with smoothness in general, so mozregressions in comment#19 are irrelevant. I ran mozregression under gnome three times and they all showed that first pushlog from comment#2 . Sorry again.
|
||
Comment 22•2 years ago
|
||
(In reply to ducaton from comment #18)
In addition, enabling "apz.disable_for_scroll_linked_effects" make scroll even less smooth. With that setting, scrolling have periodic latency spikes, that looks like freeze. Without it, scrolling just stutters, without latency spikes.
I wonder if we should consider adding a pref which forces us to take this branch even on pages with scroll-linked effects, but without actually disabling APZ on such pages.
One assumption behind the fix for bug 1571758 was that, on a page with scroll-linked effects, keeping the effects in sync (i.e. trying hard to avoid frames where something moved by script is visually out of sync with scrolling) is more important than the smoothness of scrolling over time. The feedback in this bug and bug 1810874 suggests that's not necessarily the case, and having a pref to allow users to make the opposite tradeoff (essentially restoring the behaviour prior to bug 1571758) might be nice.
|
|
Reporter | |
Comment 23•2 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #22)
One assumption behind the fix for bug 1571758 was that, on a page with scroll-linked effects, keeping the effects in sync (i.e. trying hard to avoid frames where something moved by script is visually out of sync with scrolling) is more important than the smoothness of scrolling over time.
Perhaps the bug is initially due to performance issues. Scroll-linked effects are not smooth in any case, whether they are synchronized with scrolling or not. With synchronization, it just catches the eye more. I don't recall a version of Firefox in which, when opening any channel on YouTube, the channel header would move smoothly when scrolling.
...having a pref to allow users to make the opposite tradeoff (essentially restoring the behaviour prior to bug 1571758) might be nice.
This looks like a good quick compromise.
|
|
||
Comment 24•2 years ago
|
||
(In reply to Botond Ballo [:botond] from comment #22)
(In reply to ducaton from comment #18)
In addition, enabling "apz.disable_for_scroll_linked_effects" make scroll even less smooth. With that setting, scrolling have periodic latency spikes, that looks like freeze. Without it, scrolling just stutters, without latency spikes.
I wonder if we should consider adding a pref which forces us to take this branch even on pages with scroll-linked effects, but without actually disabling APZ on such pages.
One assumption behind the fix for bug 1571758 was that, on a page with scroll-linked effects, keeping the effects in sync (i.e. trying hard to avoid frames where something moved by script is visually out of sync with scrolling) is more important than the smoothness of scrolling over time. The feedback in this bug and bug 1810874 suggests that's not necessarily the case, and having a pref to allow users to make the opposite tradeoff (essentially restoring the behaviour prior to bug 1571758) might be nice.
I agree with ducaton that what we experience are most likely performance issues with gfx on Linux. For me also pdfs stutter noticeably compared to Windows. Here is a profile (autoscrolling a pdf file):
https://share.firefox.dev/3WBWWu4
|
|
Reporter | |
Comment 25•2 years ago
|
||
(In reply to maciek4231 from comment #24)
For me also pdfs stutter noticeably compared to Windows.
Good idea. In my experience, scrolling in pdf also stutters. And since there are no scroll linked effects, mozregression should show more correct result, if the problem is not in the pdf itself. Taskcluster couldn't find any builds, so pushlog is a bit big:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c9d499871dc8c87d1f138d1a954b675df5030a43&tochange=06c7b4e2d14be1ee8050d6c1eb1ab1bab19ac3c2
|
|
Reporter | |
Comment 26•2 years ago
|
||
(In reply to ducaton from comment #25)
I forgot to write that after this change, scrolling stutters only in pdf. Meteologix scrolls smoothly on this mozregression range.
|
|
||
Comment 27•2 years ago
|
||
|
|
Reporter | |
Comment 28•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #27)
What happens if you set the pref fission.autostart to false?
Scrolling is now smooth in pdf files, even on 109 version. No changes on meteologix.
|
|
||
Comment 29•2 years ago
|
||
(In reply to ducaton from comment #28)
(In reply to Timothy Nikkel (:tnikkel) from comment #27)
What happens if you set the pref fission.autostart to false?
Scrolling is now smooth in pdf files, even on 109 version. No changes on meteologix.
That's odd, for me fission.autostart = false doesn't improve the stuttering one bit, even in pdf files.
Also, I'm not sure if it's helpful but here are profiles of scrolling on https://svelte-native.technology/ for comparison:
Windows (smooth):
https://share.firefox.dev/3Y348ke
and Linux (choppy):
https://share.firefox.dev/3WQBYYC
|
|
||
Comment 30•2 years ago
|
||
FWIW, I realized bug 1774315 can be one of sources of scroll jittering. I am not sure it's related to this bug though.
|
|
||
Comment 31•2 years ago
|
||
(In reply to ducaton from comment #28)
(In reply to Timothy Nikkel (:tnikkel) from comment #27)
What happens if you set the pref fission.autostart to false?
Scrolling is now smooth in pdf files, even on 109 version. No changes on meteologix.
Can you set
fission.autostart back to true
apz.wr.activate_all_scroll_frames_when_fission to false
restart your browser, and test and report back? Thanks!
|
|
Reporter | |
Comment 32•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #31)
fission.autostart back to true
apz.wr.activate_all_scroll_frames_when_fission to false
With these prefs, scrolling in pdf is smooth too. As with fission.autostart=false
|
|
||
Comment 33•2 years ago
|
||
(In reply to Hiroyuki Ikezoe (:hiro) from comment #30)
FWIW, I realized bug 1774315 can be one of sources of scroll jittering. I am not sure it's related to this bug though.
That looks promising! However wouldn't the jittering be os-agnostic? I still wonder why it happens with Linux only.
(In reply to ducaton from comment #32)
(In reply to Timothy Nikkel (:tnikkel) from comment #31)
fission.autostart back to true
apz.wr.activate_all_scroll_frames_when_fission to falseWith these prefs, scrolling in pdf is smooth too. As with fission.autostart=false
That's strange as I cannot see any improvement. Is this pdf: https://homepage.ntu.edu.tw/~wttsai/MathModel/Mathematical%20Formula%20Handbook.pdf smooth for you even when you autoscroll right after it loads up?
|
|
Reporter | |
Comment 34•2 years ago
|
||
(In reply to maciek4231 from comment #33)
That's strange as I cannot see any improvement. Is this pdf: https://homepage.ntu.edu.tw/~wttsai/MathModel/Mathematical%20Formula%20Handbook.pdf smooth for you even when you autoscroll right after it loads up?
With apc.wr.activate_all_scroll_frames_when_fission=true, scrolling stutters all the time.
With apc.wr.activate_all_scroll_frames_when_fission=false, scrolling stutters only the first time I scroll down and only when scrolling to a new page. The next time I scroll up and down the page, everything is perfectly smooth. I think it has to do with the new page loading.
Usually, when checking this bug, I use autoscroll.
|
|
||
Comment 35•2 years ago
|
||
(In reply to ducaton from comment #34)
(In reply to maciek4231 from comment #33)
That's strange as I cannot see any improvement. Is this pdf: https://homepage.ntu.edu.tw/~wttsai/MathModel/Mathematical%20Formula%20Handbook.pdf smooth for you even when you autoscroll right after it loads up?
With apc.wr.activate_all_scroll_frames_when_fission=true, scrolling stutters all the time.
With apc.wr.activate_all_scroll_frames_when_fission=false, scrolling stutters only the first time I scroll down and only when scrolling to a new page. The next time I scroll up and down the page, everything is perfectly smooth. I think it has to do with the new page loading.
Usually, when checking this bug, I use autoscroll.
Okay, for me it stutters when scrolling to a new page no matter the pref is true or false and stutters are worse when scrolling for the first time.
|
|
||
Comment 36•2 years ago
|
||
(In reply to ducaton from comment #34)
(In reply to maciek4231 from comment #33)
That's strange as I cannot see any improvement. Is this pdf: https://homepage.ntu.edu.tw/~wttsai/MathModel/Mathematical%20Formula%20Handbook.pdf smooth for you even when you autoscroll right after it loads up?
With apc.wr.activate_all_scroll_frames_when_fission=true, scrolling stutters all the time.
With apc.wr.activate_all_scroll_frames_when_fission=false, scrolling stutters only the first time I scroll down and only when scrolling to a new page. The next time I scroll up and down the page, everything is perfectly smooth. I think it has to do with the new page loading.
Usually, when checking this bug, I use autoscroll.
Thanks.
And if you set apz.wr.activate_all_scroll_frames to true and fission.autostart to false?
|
|
Reporter | |
Comment 37•2 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #36)
And if you set apz.wr.activate_all_scroll_frames to true and fission.autostart to false?
Past reports are partially erroneous. I noticed some peculiarity when scrolling through the pdf. If nothing is changed in about:config, then autoscrolling stutters. But scrolling with the mouse wheel is smooth and after scrolling with the wheel, autoscrolling also becomes smooth. Even when navigating to new pdf pages. This improvement in smoothness is temporary. When I set apz.wr.activate_all_scroll_frames to true and fission.autostart to false, this behavior does not change.
With apz.wr.activate_all_scroll_frames_when_fission=false, autoscrolling is immediately smooth.
|
|
||
Comment 38•2 years ago
|
||
(In reply to ducaton from comment #2)
Created attachment 9288274 [details]
mozregression_log(In reply to Timothy Nikkel (:tnikkel) from comment #1)
Can you use https://mozilla.github.io/mozregression/ to determine the commit that caused this?
I can confirm this mozregression range.
Also, it seems that a Windows user has noticed something very similar (bug 1812940)
|
|
||
Comment 39•2 years ago
|
||
(In reply to maciek4231 from comment #38)
(In reply to ducaton from comment #2)
Created attachment 9288274 [details]
mozregression_log(In reply to Timothy Nikkel (:tnikkel) from comment #1)
Can you use https://mozilla.github.io/mozregression/ to determine the commit that caused this?
I can confirm this mozregression range.
Also, it seems that a Windows user has noticed something very similar (bug 1812940)
Actually, after further testing I think it's more complicated than that. I got another mozregression range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1c19b0e1778ccd4492ca18a222ae3aa3cc27e573&tochange=5b80a12c035b401d3b25d822f613668bd84ca7bb when I was testing another website. Those commits improved scrolling on many sites but they also introduced jittering on others (like https://svelte-native.technology/).
Depending on a website jittering might be caused by solution to bug 1760222 or bug 1571758 or both
|
|
Reporter | |
Comment 40•2 years ago
|
||
(In reply to maciek4231 from comment #39)
Actually, after further testing I think it's more complicated than that.
I agree. Besides the stutter with scroll linked effects and in the pdf, there is another situation where scrolling stutters. It's so random that I can't relate it to anything. At some point the scrolling starts to stutter for a while. In gnome it lasts two seconds at most, while in xfce it can last about 10 seconds and cause screen tearing (even though xfwm is supposed to prevent it). Occurs on a site with cards that switch with the arrow keys using smooth scrolling, but this condition also affects scrolling with the mouse wheel. I was able to record profiles with this problem:
|
|
Reporter | |
Comment 41•2 years ago
|
||
I found that switching gfx.swap-interval.egl to true solves issue in comment #40. It also seems to fix all other inexplicable stutters. But only if there is no movement in other firefox windows (like videos or animations). This doesn't affect PDFs and sites with scroll-linked effects.
I think eliminating stuttering on sites with scroll-linked effects would be enough to close this bug.
Description
•