1953951 - Scrolling hitches/jitter with Hardware acceleration Enabled (high res images)

Status: UNCONFIRMED

(Core :: Graphics: WebRender, defect)

Description

[:hello]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0

Steps to reproduce:

Looked up any big high res pictures and started scrolling in all direction by clicking the middle mouse button and smooth scrolling.

Actual results:

Was looking at high res gallery photos and noticed when side scrolling the picture was hitching/jittering every couple of seconds.Does not happen with Hardware acceleration disabled.

Expected results:

For smooth scrolling to be smooth with Hardware acceleration ON.
Used Nvidia driver 561.09-566.33.
Windows 10 22h2
Only extension is ublock origin.
https://share.firefox.dev/3DC6C4D Took this log while I was zooming around on a high res picture where some jitter/hitchiness happened.

Comment 1

[Glenn Watson [:gw]]

That profile may be hiding what's happening as all the time in the renderer thread is taking profiler screenshots. Could you take another profile but with screenshots disabled in the profiler options?

Comment 2

[:hello]

(In reply to Glenn Watson [:gw] from comment #1)

That profile may be hiding what's happening as all the time in the renderer thread is taking profiler screenshots. Could you take another profile but with screenshots disabled in the profiler options?

https://share.firefox.dev/422QP8a there you go.

Comment 3

[:hello]

Forgot to @ you.
Seems someone else got the issue aswell
https://www.reddit.com/r/firefox/comments/1jutffy/choppy_scroll_when_i_open_large_res_images/

Comment 4

[Glenn Watson [:gw]]

Thanks for supplying that profile. There's nothing obvious happening in that from what I can see, which may mean that it's a GPU issue rather than something occurring inside the driver on the CPU side. Could you try enable gfx.webrender.debug.profiler and gfx.webrender.debug.gpu-time-queries and attach a screenshot of the profiler overlay when it seems particularly glitchy? That may offer some other clues to what is happening.

Comment 5

[:hello]

I used these pictures as an example https://www.pexels.com/photo/light-bulb-turned-on-in-tilt-shift-lens-10528767/ they're high res and big and I was getting frame skipping/fps drops/stutter (whatever you wanna call them) when middle mouse scrolling up and down on them.Especially obvious when opening an image.The stutter dies down after a few seconds but there's still the odd random hitch.

Here is the screenshot of the overlay. https://imgur.com/a/d3PCSKg

Comment 6

[Glenn Watson [:gw]]

The overlay does show some expensive texture upload frames, worst case around 16 ms (1 frame hitch if running at 60fps). That's definitely noticeable to those sensitive to latency, but shouldn't be causing a major frame glitch.

What frame rate do you run your display(s) at? Does the glitching feel like it could be a single frame, or is it much more severe than that? It's possible there is something going on inside the driver during one of those uploads that is far more expensive that we're not catching in the overlay or profiler.

Comment 7

[:hello]

What frame rate do you run your display(s) at

I have a single monitor (S2721DGFA) which is a 1440p 165hz monitor.
I've been running it for years at 144hz tho since I saw no point in anything higher when playing games since I lock my FPS waay to lower then 165hz.

Does the glitching feel like it could be a single frame, or is it much more severe than that?

It's mostly subtle hitches when scrolling around (90% of the time)
Sometimes il get a bigger hitch and incase of these images.
https://www.pexels.com/photo/light-bulb-turned-on-in-tilt-shift-lens-10528767/ if I scroll down and open a new image>zoom (makes image larger) and start middle mouse scrolling up and down it sometimes almost freeze frames for a split second then it dies down and scrolling becomes somewhat "smoother".It's still not actually smooth smooth because you can kinda tell the image is a bit jumpy/jittery if you go up and down.

Comment 8

[Mayank Bansal]

On clicking on an image and then clicking again to zoom it, and then moving the mouse, I see some time spent on the main thread ion decoding the image. Maybe that causes jank? Subjectively, I did not notice any jank though.
Profile: https://share.firefox.dev/3ReqiyI / https://share.firefox.dev/3XV7QPp

Comment 9

[:hello]

Oddly enough I noticed another site displaying subtle scrolling jitter/graphical jitters.

It's Twitch.
Video stats for twitch say's there's 0 frame skipping when I'm watching so I dunno if that could be related to scrolling jitter

https://imgur.com/a/ZO59QBp The easiest way to spot it on twitch seems to be when there's some sort of white text.
When scrolling the white letters sometimes do this wierd subtle warping when the subtle hitch from scrolling happens.

Youtube on the other hand is smooth No matter what kind of crazy scrolling movement I do even with a 60fps video playing at the same time.

Comment 10

[Glenn Watson [:gw]]

I haven't been able to reproduce which makes it tricky to know exactly what's going on. Adding to gfx-triage, we'll see if anyone else from the gfx team is able to reproduce with local hardware.

Comment 11

[:hello]

Well,Hopefully someone else can reproduce it because I can make it happen pretty consistently :/

If you need to know anything else about my system/drivers just ask me any time.

Comment 12

[Ashley Hale [:ahale]]

Can you go to about:support and copy the text (using one of the buttons at the top) to a new attachment on this bug? I'd like to see more details about the GPU.

Repro efforts often depend on matching hardware rather precisely, so it helps to know more.

Comment 13

[:hello]

Attachment: about_support.txt

Attached.Done.

Comment 14

[Brad Werth [:bradwerth]]

(In reply to :hello from comment #3)

Forgot to @ you.
Seems someone else got the issue aswell
https://www.reddit.com/r/firefox/comments/1jutffy/choppy_scroll_when_i_open_large_res_images/

Thank you for filing. This other report you found is also very interesting. That reporter is saying that the issue isn't happening with older versions of Firefox. We can work with this! We have a tool called MozRegression that can identify the piece of code that caused the problem. Since you can consistently reproduce, would you please try using MozRegression so you can find where we went wrong? If you need to use login credentials (on Twitch?) or any thing else that is associated with your profile, you will find useful the command-line option --profile-persistence clone-first.

Comment 15

[:hello]

(In reply to Brad Werth [:bradwerth] from comment #14)

(In reply to :hello from comment #3)

Forgot to @ you.
Seems someone else got the issue aswell
https://www.reddit.com/r/firefox/comments/1jutffy/choppy_scroll_when_i_open_large_res_images/

Thank you for filing. This other report you found is also very interesting. That reporter is saying that the issue isn't happening with older versions of Firefox. We can work with this! We have a tool called MozRegression that can identify the piece of code that caused the problem. Since you can consistently reproduce, would you please try using MozRegression so you can find where we went wrong? If you need to use login credentials (on Twitch?) or any thing else that is associated with your profile, you will find useful the command-line option --profile-persistence clone-first.

The user in that thread does say 91.13.0esr was the last version without any issues and when I switched to firefox (normal version) around 60+ days ago the issue was there already.I don't know where to even start patch wise.

He also says
Firefox 91.13.0esr was fine and the switch to 115.22.0esr is when he started to get the issue if this is of any help.

Only difference between me and that user seems to be hes using esr version of firefox while im using the standard version.

Comment 16

[Brad Werth [:bradwerth]]

(In reply to :hello from comment #15)

He also says
Firefox 91.13.0esr was fine and the switch to 115.22.0esr is when he started to get the issue if this is of any help.

Only difference between me and that user seems to be hes using esr version of firefox while im using the standard version.

No need to worry about ESR versus regular Firefox. They have similar code in them. Please try this invocation mozregression --good 91 --bad 115 and go through the bisection to find the point where it breaks.

Comment 17

[:hello]

(In reply to Brad Werth [:bradwerth] from comment #16)

(In reply to :hello from comment #15)

He also says
Firefox 91.13.0esr was fine and the switch to 115.22.0esr is when he started to get the issue if this is of any help.

Only difference between me and that user seems to be hes using esr version of firefox while im using the standard version.

No need to worry about ESR versus regular Firefox. They have similar code in them. Please try this invocation mozregression --good 91 --bad 115 and go through the bisection to find the point where it breaks.

I'm not familiar on how to use mozregression and I honestly don't have much time irl to bug hunt.Granted,I did reported it here in the hopes someone else with more time/motivation would look into it since it's apparently been an ongoing issue for 50+ days.(I don't usually come to these bug hunting sites)

And honestly after 30 days of no progress I lost any motivation to try and fix it.For now il just put up with it or il just use another browser.

Kind regards and thanks for trying.

Comment 18

[Brad Werth [:bradwerth]]

Okay, back to triage, keep looking for somebody who can replicate.

Comment 19

[Pasquale Jordan]

Hi everyone, I am experiencing the same issue with high-resolution background images. They cause a noticeable stutter during scrolling.
As I am interested in fixing this issue, I have run the mozregression tool as described above (mozregression --good 91 --bad 115).

It returned me the following URL after allocating the two versions that introduced the "breaking changes":
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=abda04d0bfe3304e216ac64e2848e9867d9f494b&tochange=e7f3e1f5b6253d91b5eeb60ac23a35cb12bafa5a

Additionally, I noticed that in the newer "broken" versions, the background images seemingly appear faster, while in the older releases, they would tend to load over a longer time and also visibly from top to bottom (sometimes even being stuck during loading, so that parts of the background remained white, while the UI still stayed responsive).

I hope this description helps you find the issue.
If needed, I can provide further system information or debug logs.
I am running ArchLinux on the newest kernel release (6.14.4.arch1-1), which is up to date at the time of this writing.

I can probably also try to build a test page that suffers from this issue. Currently, I am only experiencing this issue on my self-hosted customized Jellyfish instance, where we heavily rely on high-resolution background images to show a diashow-like banner in the background.

Comment 20

[Pasquale Jordan]

I have created a minimal example that hopefully makes it easier to determine the underlying issue.
During that I noticed that in my case the lag is likely related to a opacity transition, which causes significant slow downs during rendering.
These slowdowns are not nearly as pronounced with version 92.01a (although they exist) and do not happen at all in the newest version of chrome, for any of the variants.

It's made up of multiple versions:

1. Main version: Auto scrolling, with a single element that changes opacity every second, with transitions: http://laggy.pjordan.net/
2. Full version: Same as main version, but background images also change every 4s, with transitions: http://laggy.pjordan.net/full.html
3. Opacity version: No auto scrolling, otherwise same as Main: http://laggy.pjordan.net/opacity-only.html
4. Scroll version: Baseline version, only autoscrolling, otherwise only static html: http://laggy.pjordan.net/scroll-only.html
5. Transition version: Only background images change every 4s: http://laggy.pjordan.net/transition-only.html

The slow downs occur whenever an animation is taking place and are especially bad on starts.
I am not sure if the issue I found is the same as this issue, however they are likely related.
To me it seems that a change after 92.01a introduced something that made opacity changes/transitions significantly more laggy, which is especially noticeable during scrolling.

Comment 21

[Jannes]

(In reply to Pasquale Jordan from comment #20)

I can confirm the same slow downs, most noticable on https://laggy.pjordan.net/ and https://laggy.pjordan.net/opacity-only.html and to a smaller degree during transitions https://laggy.pjordan.net/transition-only.html

I am running Firefox 137.0.2 (64-bit) on MacOS Ventura Version 13.7.5 (22H527).

Using Safari (Version 18.4 (18621.1.15.111.1, 18621)) the lagging is not noticable.

Comment 22

[Brad Werth [:bradwerth]]

(In reply to Pasquale Jordan from comment #19)

It returned me the following URL after allocating the two versions that introduced the "breaking changes":
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=abda04d0bfe3304e216ac64e2848e9867d9f494b&tochange=e7f3e1f5b6253d91b5eeb60ac23a35cb12bafa5a

Wonderful! This, and the test page you've built, are very valuable for solving this Bug. I can reproduce a little on my macOS system, and I'll try to narrow down this Mozregression range further and we'll find the specific Bug that causes this problem. Thank you.

Comment 23

[Pasquale Jordan]

(In reply to Brad Werth [:bradwerth] from comment #22)

(In reply to Pasquale Jordan from comment #19)

It returned me the following URL after allocating the two versions that introduced the "breaking changes":
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=abda04d0bfe3304e216ac64e2848e9867d9f494b&tochange=e7f3e1f5b6253d91b5eeb60ac23a35cb12bafa5a

Wonderful! This, and the test page you've built, are very valuable for solving this Bug. I can reproduce a little on my macOS system, and I'll try to narrow down this Mozregression range further and we'll find the specific Bug that causes this problem. Thank you.

Perfect! Thanks a lot :)
If you need anything else, feel free to ask!

Another note: The larger the window (and therefore the background image) the more pronounced the lag is for me.

Comment 24

[Pasquale Jordan]

After some further investigation I have determined that there are two components to lag.

First of all a opacity transition of images, seems to create a slow down.
Additionally the image-mask in combination with opacity on objects over images also creates slowdowns.

Therefore by avoiding image-mask and using a linear background in combination with after, as described here one can avoid lag.

Still the issue with opacity animations for images persists.

Comment 25

[Ashley Hale [:ahale]]

I can see jank easily on the first link in comment #20 on my work laptop, so I should be able to do mozregression on this.

Comment 26

[Ashley Hale [:ahale]]

On a Windows 11 laptop with Intel i9-11900H + NVIDIA RTX 3050, I tried mozregression with --good 91 and really I don't see any difference in how bad the blob rendering performance is on both 92 and 140 when the fade is happening, the performance is really bad when fullscreen, which can easily be seen with pref gfx.webrender.debug.profiler set to true in about:config, when the green bar is entirely opaque or entirely transparent but not animating, performance is fine, when its opacity is animating the performance is terrible, and that is entirely showing up as blob rendering time, and in Skia in particular.

That said, the profile shows noticeably lower CPU usage in 140 than 92, it's quite bad jank either way though.

Profile for release 92 https://share.firefox.dev/3EzLFYF
Profile for nightly 140 https://share.firefox.dev/4cVgMdG

For bonus I added a profile on 91.0a1 https://share.firefox.dev/3Sfgox1 which doesn't run any faster but the WebRender profiler overlay shows no blob rasterization time on that version.

Comment 27

[Brad Werth [:bradwerth]]

(In reply to Ashley Hale [:ahale] from comment #26)

On a Windows 11 laptop with Intel i9-11900H + NVIDIA RTX 3050, I tried mozregression with --good 91 and really I don't see any difference in how bad the blob rendering performance is on both 92 and 140

Thanks. The idea that ESR91 was working better came from the Reddit post in comment 3. That person hasn't commented directly on this Bug so there's no way to inquire about this claim. I think we have to assume that it has always been performing poorly, and our only way forward is to try to address the issues we see in the current profiler results.

Comment 28

[Ashley Hale [:ahale]]

I think the biggest problem here is that we want to avoid blob fallback more of the time - animated blobs are especially bad, but hitting blob fallback at all seems like an undesirable thing to me.

Comment 29

[Brad Werth [:bradwerth]]

(In reply to Ashley Hale [:ahale] from comment #28)

I think the biggest problem here is that we want to avoid blob fallback more of the time - animated blobs are especially bad, but hitting blob fallback at all seems like an undesirable thing to me.

Thank you. Would you please explain what you see in the profile in comment 26? I am not adept in reading profiles and I'm not sure what is leading to the conclusion that we are in the "blob fallback".

Comment 30

[Ashley Hale [:ahale]]

Correcting myself a bit here as this is not blob fallback in the Gecko sense which is visible if you use gfx.webrender.debug.blob.paint-flashing=true) but in the Skia sense inside WebRender - i.e. we're seeing animated SVG vector art here.

I believe we're seeing Skia software rasterizing of paths triggered here, which is visible as the WRWorkerLP#0 and related threads in the profile, so the fading alpha of the green bar is triggering the paths to be re-rendered and that is causing the jank. In some cases we try to hoist opacity out of paths and make it a property of the stacking context to avoid this kind of thing (i.e. we can reuse the same path image every frame if we're only varying alpha), but that is clearly not happening here (nor am I certain that it would be easy to do).

So the main takeaway here may just be "Skia rendered paths are slow in WebRender, we need to improve path rendering performance for this and other reasons", which is a concise but not entirely satisfying answer.

Comment 31

[Bob Hood [:bhood]]

Ashley will attempt to repro on an Win10 NVIDIA system.

Comment 32

[Ashley Hale [:ahale]]

Summary from triage meeting:

• The janky scrolling of the image on https://www.pexels.com/photo/light-bulb-turned-on-in-tilt-shift-lens-10528767/ (from comment #5) is likely a different root cause than the general slowness of software Skia rendering in http://laggy.pjordan.net/ (from comment #20), so while the pjordan link is quite nice and specific for testing purposes nice it isn't actually the same bug, and furthermore we know why that one is slow (i.e. we shouldn't use software Skia for path-rendering, fixing that is more of a long-term project).
• The pexels image cited is a 4000x6000 JPEG format image, and we ought to be good at scrolling around a large JPEG image, it is a common use-case and we have generally been good at this, so if there is an issue it is likely driver/gpu combination specific, or we could be failing at caching the image decode for some reason. Repro attempt and deeper digging into the profile is needed (so I'll be following up on that). Profile is helpful but looking over it hasn't been entirely fruitful in figuring out what is going on.

A further thought - I think the image is being uploaded as a single tile when using SWGL (hardware acceleration turned off), whereas in hardware we turn the image into several tiles for separate uploads, we may be failing to optimize the transform (which includes a translate3d op) for the tiled image case, which would make this a very different rendering workload in hardware vs software for reasons that are fairly arbitrary. If we're just failing to optimize the transform then that's a quick fix we can look into.

Comment 33

[Brad Werth [:bradwerth]]

Taking out of triage, assigning to Ashley. Not sure about the relative priority in her overall work, but she's got the hardware to reproduce.