1367003 - Page slow to load when scrolling up and down.

Status: NEW

(Core :: Graphics: Layers, enhancement, P3)

Description

[loy heng]

Attachment: Firefox_Troubleshooting info.pdf

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170518000419

Steps to reproduce:

Open a few graphics rich pages/tabs. Suggest the following

http://www.lazada.com.my/
http://www.lazada.com.my/shop-home-appliances/?spm=a2o4k.home.0.0.W8Hqwy
http://www.lazada.com.my/philips-classic-dry-iron-1000-w-hd1172-hd117201-14274463.html

At the last tab, scroll down to the end and up to the top with the mouse's middle wheel.


Actual results:

Certain parts of the page would be blank temporarily and takes time to load back fully every details. If you switch tabs, the tab concerned would lag a bit in loading and if you switch back to the last tab, a "circle of moving rays" appeared briefly.
Actually this problem had appeared since the last few versions, especially when visiting graphics rich pages or google map. Problems persist in safe mode.


Expected results:

Pages/graphics should load as usual without lagging.
I tried googling the problem and some of the forums mentioned hardware acceleration (HWA)or graphics card driver not up to date. But the problem is still there after turning off HWA. Other browsers like Chrome has HWA turned on but don't encounter such problem. The same goes to Microsoft Edge.
I don't think this is a graphic card issue since this the same graphic card that powered all the three browsers on my PC.
I had appended a pdf file of the troubleshooting information found on about:support page.

Comment 1

[Andre Klapper]

Please see https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem for more information. Thanks!

Comment 2

[loy heng]

O.k. Andre. 
I had followed the instructions on the page you referred and obtained this url... 
https://perfht.ml/2rvOPoI

It seems the problem I reported using Firefox 53 stable release was more serious than when reproducing using Nightly build. Problems encountered in stable release had a longer lag. Hope the information furnished is sufficient for your problem identification. Thank you.

Comment 3

[Hani Yacoub, Desktop QA]

Build ID: 20170525030225
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0

Reproducible on Firefox Nightly 55.0a1(2017-05-25) Windows 10 x 64.

Comment 4

[Andrew Overholt [:overholt]]

(In reply to loy heng from comment #0)
> 
> Certain parts of the page would be blank temporarily and takes time to load
> back fully every details.

I think this is just checkerboarding.

> If you switch tabs, the tab concerned would lag a
> bit in loading and if you switch back to the last tab, a "circle of moving
> rays" appeared briefly.
> Actually this problem had appeared since the last few versions, especially
> when visiting graphics rich pages or google map. Problems persist in safe
> mode.

Mike, this is the tab switch spinner; known issue?

Comment 5

[Mike Conley (:mconley) (:⚙️)]

(In reply to Andrew Overholt [:overholt] from comment #4)
> Mike, this is the tab switch spinner; known issue?

The tab switcher spinner showing up can be a symptom of many different things. In this case, looking at the page and the profile, it looks like we're spending an awful lot of time painting. The page itself, when I turn on paint flashing, is overpainting like crazy.

So it would not surprise me if we're spending so much time painting that during a tab switch to a tab in the same content process, we run out of time to paint the layers that we actually care about because this page is still painting. A lot.

Still, I'll queue this up for analysis at Joy of Profiling tomorrow.

Comment 6

[Andrew Overholt [:overholt]]

Thanks, Mike. Is this the correct component (assuming we're tracking the tab switch spinner stuff here and not the checkerboarding)?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

I don't think so. IMO, this is us not being smart enough about the stuff we're spending time re-painting here, so tentatively throwing this into Graphics :: Layers, though I'm really just guessing that this is the right place to put invalidation bugs.

Comment 8

[Markus Stange [:mstange]]

Here's a profile of the page with symbols: https://perfht.ml/2rtpJo4

We're painting lots and lots of SVG images, and each of them takes about 11ms (7ms on my machine). For each SVG image we build a display list and run layer building for the image.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

It would be valuable to include the urls of the vector images that we're painting in the profile. That would help us better understand what's happening on this page.

Comment 10

[Markus Stange [:mstange]]

The image that's so slow to paint is this one: http://my-live-02.slatic.net/images/2014/sprites/icons-01b9339c.svg

It's a spritesheet, and it contains a CSS animation in an orange circle icon somewhere close to the bottom. The animation is probably the reason why we don't retain its pixels and paint it over and over.

Comment 11

[Timothy Nikkel (:tnikkel)]

Yeah, vector images don't cache the rasterized version if there are animations. To be able to tell that we can use a cached version we'd need to have some way of knowing that the animations in the document do not affect the rect we are drawing of the document. Which seems hard. Unless we are drawing the same part of the spritesheet multiple times on one refresh driver tick, then bug 922893 would help. Not sure what else we can do?

Comment 12

[Mike Conley (:mconley) (:⚙️)]

http://www.lazada.com.my/philips-classic-dry-iron-1000-w-hd1172-hd117201-14274463.html seems a little different.

For this one, it looks like there's a loader.gif[1] set as the background of elements with class product-card__img. Then, an image within that node overlaps the loader.gif.

Despite overlapping it, we still end up repainting the loader.gif uselessly. :/

Demo: https://www.screencast.com/t/PDL2GyRcA5

I also can't seem to find the SVG image anymore. The link that mstange has in comment 10 is 404.

At least for the .gif painting issue, is there anything we can do here, tnikkel?

[1]: http://my-live-01.slatic.net/images/2014/loader.gif

Comment 13

[Timothy Nikkel (:tnikkel)]

That's bug 968123/bug 805343. We currently don't have any way to know that the animated gif was completely covered on that last paint so we have to invalidate it. The fix is basically saving that info so we can avoid invalidating.