1394193 - Scrolling choppiness on Ars Technica

Status: RESOLVED DUPLICATE of bug 1392453

(Core :: Graphics, defect, P1)

Description

[voracity]

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.

Comment 1

[(no longer active)]

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!

Comment 2

[Bas Schouten (:bas.schouten)]

(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.

Comment 3

[Matt Woodrow (:mattwoodrow)]

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.

Comment 4

[Mason Chang [Inactive] [:mchang]]

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.

Comment 5

[Mason Chang [Inactive] [:mchang]]

Bug 1392453 should fix this.