Janking/stuttering while scrolling on imgur (Celeron N4000) (Geminilake)
Categories
(Core :: Graphics, defect, P3)
Tracking
()
Performance Impact | medium |
People
(Reporter: yoasif, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
(Keywords: perf:responsiveness)
Attachments
(2 files)
Basic information
Steps to Reproduce:
- load https://imgur.com/gallery/N68aoe1
- 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.
Comment 1•4 years ago
|
||
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
Reporter | ||
Comment 2•4 years ago
|
||
Kim, it was part of the initial report. See https://share.firefox.dev/3i5okgm
Comment 3•4 years ago
|
||
Here's one kinda-interesting snippet of that profile: https://share.firefox.dev/3gCMJc3
Comment 4•4 years ago
|
||
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?)
Comment 5•4 years ago
|
||
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
. 🤪
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?
Reporter | ||
Comment 8•4 years ago
|
||
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!
Comment 9•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 10•4 years ago
|
||
Asif, how does Firefox compare to Chrome on this workload?
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 11•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Impacts Nightly only.
Comment 14•4 years ago
|
||
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.
Reporter | ||
Comment 15•4 years ago
|
||
Jim, it is the same as https://bugzilla.mozilla.org/attachment.cgi?id=9167576
Comment 16•4 years ago
|
||
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.
Comment 17•4 years ago
|
||
Comment 18•4 years ago
|
||
(In reply to Asif Youssuff from comment #15)
Jim, it is the same as https://bugzilla.mozilla.org/attachment.cgi?id=9167576
Perfect - thanks!
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Sotaro, once we get the profile, would you like to take a look at this?
Updated•4 years ago
|
Reporter | ||
Comment 20•4 years ago
|
||
Jim, I captured a new profile: https://share.firefox.dev/30EQdFF
Reporter | ||
Comment 21•4 years ago
|
||
Comment 23•4 years ago
|
||
(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.
Comment 24•4 years ago
|
||
Asif, can you check the performance with pref gfx.webrender.compositor=false? Thanks.
Reporter | ||
Comment 25•4 years ago
|
||
Sotaro, here's a new profile with gfx.webrender.compositor=false: https://share.firefox.dev/2GJ8Dy8
Still pretty bad, unfortunately.
Comment 26•4 years ago
|
||
Thanks!
:gw, is it possible to reduce WebRender's GPU task with the STR?
Comment 27•4 years ago
|
||
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?
Comment 28•4 years ago
|
||
Yes. I'm going to try to get a machine like this.
Updated•4 years ago
|
Comment 29•4 years ago
|
||
I have an n4000 machine now. I gathered a GPU view profile and can see the badness happening.
Reporter | ||
Comment 30•4 years ago
|
||
Fresh profile after disabling some Windows services that helped lower my idle CPU use: https://share.firefox.dev/3kNp0rI
Updated•4 years ago
|
Updated•3 years ago
|
Description
•