Closed Bug 1394193 Opened 2 years ago Closed 2 years ago

Scrolling choppiness on Ars Technica

Categories

(Core :: Graphics, defect, P1)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1392453
Tracking Status
firefox57 --- affected

People

(Reporter: subs, Assigned: mchang)

References

Details

(Whiteboard: gfx-noted)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20170826100418

Steps to reproduce:

Scroll the page on Ars Technica, using mousewheel and/or arrow keys.


Actual results:

As per this comment on Ehsan's blog ( https://ehsanakhgari.org/blog/2017-08-04/quantum-flow-engineering-newsletter-18#comment-3590 ), I am experiencing choppy scrolling on some sites, Ars Technica being the most common. This occurs when using either the mousewheel or up/down keys. The latter is so slow as to be essentially unusable. This has been the case for at least a year or more (I can't recall when it began being an issue).

Here is the perf-html.io log when scrolling with the scrollwheel, as requested by Ehsan: http://bit.ly/2vhnau4 . Not that I know how to read that, but the event processing delays are continuous and all 400-900ms for Ars Technica scrolling, while very rare and nothing more than 100ms for scrolling, say, Ehsan's blog ( http://bit.ly/2vhbwj9 ).

Here is the log when scrolling with the arrow keys: http://bit.ly/2vhs6zj . Arrow keys are unusably slow (mousewheel is bad, but not unusable).

System: Windows 7 (64bit), i7-2630qm, 8gb ram, Intel HD 3000 graphics (AMD hybrid off)

Doesn't seem to be an issue on my other system, which is Windows 10 (64 bit), i5-4200u, Intel HD graphics.


Expected results:

Smoother scrolling, which is what I experience on most other sites.
Component: Untriaged → Layout
Product: Firefox → Core
Flags: needinfo?(ehsan)
Thanks for filing the bug!

This seems to be related to graphics.  On the first look, this call to AcquireSync() is taking a long time in the profile <https://searchfox.org/mozilla-central/rev/18c16ebf818abb86805ce08a6e537e4cd826f044/gfx/layers/d3d11/TextureD3D11.cpp#136>.  The rasterize times also seem to be quite long.

But when I turn paintflashing on on https://arstechnica.com/, I see that we are overpainting quite a lot as one scrolls down the page, so I suspect the real reason this issue exists is perhaps due to the overpainting.

Bas, any chance you can take a look please?  Thanks!
Component: Layout → Graphics
Flags: needinfo?(ehsan) → needinfo?(bas)
(In reply to :Ehsan Akhgari (needinfo please, extremely long backlog) from comment #1)
> Thanks for filing the bug!
> 
> This seems to be related to graphics.  On the first look, this call to
> AcquireSync() is taking a long time in the profile
> <https://searchfox.org/mozilla-central/rev/
> 18c16ebf818abb86805ce08a6e537e4cd826f044/gfx/layers/d3d11/TextureD3D11.
> cpp#136>.  The rasterize times also seem to be quite long.
> 
> But when I turn paintflashing on on https://arstechnica.com/, I see that we
> are overpainting quite a lot as one scrolls down the page, so I suspect the
> real reason this issue exists is perhaps due to the overpainting.
> 
> Bas, any chance you can take a look please?  Thanks!

Hrm, so one interesting thing paintflashing shows, is that drawing is quite good at the top bit of the page, where I was initially looking, once I scroll down, the second section of the page seems to redraw very frequently as I scroll by. Fwiw, mousing over the links and thereby getting those repainted seems to cause some overdraw, but not nearly as much as scrolling does.

Mason, this may interest you, you were seeing some inconsistent perf data on here for another bug, I'm wondering if something changed recently, on the page or in gecko, that caused excessive invalidation to be reduced and may explain some of your data.

Matt, there is, at the very least, definitely an invalidation issue going on on this page. Who would be well suited to look into that bit of this bug.

Another cause of heavy graphics on this page is going to be the mixed blend modes Mason talked about, but that shouldn't be a major issue.
Flags: needinfo?(mchang)
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bas)
I'm not sure who would be best to have a go at the invalidation bug, though it's probably fairly easy to get started.

I wrote this a while back for debugging invalidation: https://wiki.mozilla.org/Gecko:DisplayListBasedInvalidation#Debugging_Invalidations_Problems

I can have a look at some point, but I've got a lot on at the moment.
Flags: needinfo?(matt.woodrow)
Whiteboard: gfx-noted
I think I fixed it in bug 1392453 if that is the right approach. Without OMTP and the patch in bug 1392453, arstechnica is super smooth for me now.
Flags: needinfo?(mchang)
Flags: needinfo?(mchang)
Depends on: 1392453
Assignee: nobody → mchang
Priority: -- → P1
Bug 1392453 should fix this.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mchang)
Resolution: --- → DUPLICATE
Duplicate of bug: 1392453
You need to log in before you can comment on or make changes to this bug.