Open Bug 1657183 Opened 4 years ago Updated 3 years ago

Janking/stuttering while scrolling on imgur (Celeron N4000) (Geminilake)

Categories

(Core :: Graphics, defect, P3)

defect

Tracking

()

Performance Impact medium
Tracking Status
firefox81 --- disabled
firefox82 --- disabled
firefox83 --- affected

People

(Reporter: yoasif, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: perf:responsiveness)

Attachments

(2 files)

Basic information

Steps to Reproduce:

  1. load https://imgur.com/gallery/N68aoe1
  2. use mouse touchpad scroll to scroll up and down page

Expected Results:

Smooth scrolling, low CPU use.

This works very well in Microsoft Edge.

Actual Results:

Very slow janky scroll. Feels like scroll is going through molasses.


More information

Profile URL: https://share.firefox.dev/3i5okgm

Basic systems configuration:

OS version: Windows 10

GPU model: Intel(R) UHD Graphics 600

Number of cores: 2

Amount of memory (RAM): 8GB

Thanks so much for your help.

Could you also capture a performance profile the next time you see this? https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Flags: needinfo?(yoasif)

Kim, it was part of the initial report. See https://share.firefox.dev/3i5okgm

Flags: needinfo?(yoasif)

Here's one kinda-interesting snippet of that profile: https://share.firefox.dev/3gCMJc3

It looks like most of our activity on the content process is from JavaScript, so I'm classifying this as JavaScript for now.

(Also: in the zoomed-in snippet that I posted in comment 3, it looks like the content process is pretty quiet for the second ~half of the jank bar, which is odd/interesting. Maybe we're blocking on some signal?)

Component: Performance → JavaScript Engine
Whiteboard: [qf:p2:responsiveness]

56% of the zoomed-in case is main-thread blocked in mozilla::CanCreateMFTDecoder, apparently waiting for the MTA thread to run a task. Hmm. I'll try bouncing this bug to AV, in case it's easily fixable...

31% is in JavaScript, but there's nothing obvious we could fix. Maybe JIT everything more aggressively.

And, for good measure, 2.3% is under Element.getBoundingClientRect. 🤪

Component: JavaScript Engine → Audio/Video

Bryce, do you have any thoughts on this one?

Flags: needinfo?(bvandyk)

Based on the screen shots + profile we're testing if we can create decoders during the initial HTMLMediaElement(s) load rather than throughout page usage. While it's possible we could improve this, I question if it's the cause of the janky scrolling. Looking at the screen shots it appears the scrolling takes place after the 10 second mark, at which point we're not doing any decoder creation.

Comment 0 suggests that low CPU usage is expected, does this indicate that there is high CPU usage while scrolling? Does the lack of smooth scrolling coincide with high CPU usage? If you navigate to about:config and set media.use-blank-decoder to true (this will turn off a whole lot of media decoding), does the page still scroll poorly?

Flags: needinfo?(bvandyk) → needinfo?(yoasif)

Bryce, sorry, I was mistaken - the CPU use is not high - I had assumed that it would be because of the unresponsiveness of the machine.

I tried setting media.use-blank-decoder to true and the responsiveness while scrolling is basically the same - I could tell almost no difference. The page still scrolls poorly. You can find the profile here:

https://share.firefox.dev/35ND1Sm

Hope this helps!

Flags: needinfo?(yoasif)

There are some Composite and APZScroll markers with very long durations in the comment 8 profile. Pass this to gfx to see if they can help.

Component: Audio/Video → Graphics

Asif, how does Firefox compare to Chrome on this workload?

Flags: needinfo?(yoasif)
Blocks: gfx-triage

Jeff, Chrome loaded the page at a decent speed and scrolling was almost as good as Edge. Both are a lot better than Firefox - janking occurs only immediately after page load (I am not scrolling during page load on any of these trials), after that it is a lot smoother. Firefox looks really bad in comparison.

Flags: needinfo?(yoasif)
Summary: Janking/stuttering while scrolling on imgur (Celeron N4000) → Janking/stuttering while scrolling on imgur (Celeron N4000) (Geminilake)

Impacts Nightly only.

Could you visit about:support, use the 'copy text to clipboard' button, and paste it into the bug? Bugzilla should offer to make it into an attachment; please do so.

Flags: needinfo?(yoasif)
Flags: needinfo?(yoasif)

Thanks for attaching the profile - that's helpful. If you can still reproduce this problem, however, could you select "Firefox Graphics" from the menu of presets in the profiler drop-down, record a profile with those settings, and post the link here?

That will give us more detail about what the GPU process is up to.

Attached file about:support information (deleted) —

(In reply to Asif Youssuff from comment #15)

Jim, it is the same as https://bugzilla.mozilla.org/attachment.cgi?id=9167576

Perfect - thanks!

Severity: -- → S3
Priority: -- → P3

Sotaro, once we get the profile, would you like to take a look at this?

Flags: needinfo?(sotaro.ikeda.g)

Jim, I captured a new profile: https://share.firefox.dev/30EQdFF

Flags: needinfo?(jimb)
Attached file newest about:support (deleted) —

Excellent, thanks!

Flags: needinfo?(jimb)

(In reply to Asif Youssuff from comment #20)

Jim, I captured a new profile: https://share.firefox.dev/30EQdFF

From the profile, several DirectComposition and D3D apis were slow. From it, gpu task might be heavy weight for the PC.

  • DirectComposition::CVirtualSurface::BeginDraw
  • CContext::TID3D11DeviceContext_SetShaderResources
  • CDevice::CreateTexture2D
  • CContext::TID3D11DeviceContext_OMSetRenderTargets

I tested several Win10 PCs, but I did not saw such slow composite time.

Asif, can you check the performance with pref gfx.webrender.compositor=false? Thanks.

Flags: needinfo?(yoasif)

Sotaro, here's a new profile with gfx.webrender.compositor=false: https://share.firefox.dev/2GJ8Dy8

Still pretty bad, unfortunately.

Flags: needinfo?(yoasif)

Thanks!

:gw, is it possible to reduce WebRender's GPU task with the STR?

Flags: needinfo?(sotaro.ikeda.g) → needinfo?(gwatson)

I think we need to arrange for me or someone else on gfx to get access to this hardware, and do some detailed profiling and experiments. Jeff, Jim, do you have access to a device of this kind?

Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jmathies)
Flags: needinfo?(gwatson)

Yes. I'm going to try to get a machine like this.

Flags: needinfo?(jmuizelaar)
Flags: needinfo?(jmathies)

I have an n4000 machine now. I gathered a GPU view profile and can see the badness happening.

Depends on: 1671490

Fresh profile after disabling some Windows services that helped lower my idle CPU use: https://share.firefox.dev/3kNp0rI

Blocks: wr-renderer
No longer blocks: wr-perf

Let's see how this looks in GPUview

Flags: needinfo?(jmuizelaar)
Performance Impact: --- → P2
Whiteboard: [qf:p2:responsiveness]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: