1211565 - Unnecessary repainting on sohu.com (#8 site in China) due to APZ

Status: NEW

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

Description

[Andrew McCreight [:mccr8]]

Comment 1 said the CPU usage in Firefox was clearly the worst on sohu.com. I ran a profile on the page, and most of the non-idle time is being spent on things under nsRefreshDriver::Tick, like nsCSSRendering::PaintBackground, nsDisplayImage::Paint, and various other little bits.

There is some animation on the site. In the middle of the page near the bottom of the screen, there's a little image that scrolls. (There is also a text box that changes a little to the right of it, but I'm ignoring that here.) If you turn on paint flashing for the site, then when the image switches, Firefox is repainting all of the content in that lower half of the page. By contrast, if you enable "show paint rectangles" in Chrome (the equivalent of paint flashing), then only the little box containing the image gets repainted, as you would expect.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Andrew McCreight [:mccr8] from comment #0)
> Comment 1 said the CPU usage in Firefox was clearly the worst on sohu.com.

(to clarify, mccr8 is referring to bug 984506 comment 1 here.)

Comment 2

[Daniel Holbert [:dholbert]]

The image seems to be scrolled by placing it in a wide abspos "tray", whose absolute position is animated.  Here's what it looks like at one point (and "left" changes periodically):
=======
<div style="width: 1520px; left: -760px;" id="pic-cont">
<ul> 
<li><a href="http://pic.news.sohu.com/group-687801.shtml" target="_blank"><img src="http://i2.itc.cn/20151004/2b65_d31192e6_7ac2_6ad8_a5ba_db3534b8d24a_1.jpg"></a><span><i></i><a href=" 
http://pic.news.sohu.com/group-687801.shtml" target="_blank">证清白? NASA公布8千多张照片</a></span></li>

<li><a href="http://pic.news.sohu.com/group-687795.shtml" target="_blank"><img src="http://i3.itc.cn/20151004/2b65_11c97944_e891_f85c_f8db_6cb221688eb7_1.jpg"></a><span><i></i><a href="http://pic.news.sohu.com/group-687795.shtml" target="_blank">动物园羊驼被隔离 因投喂过量</a></span></li>
[...]
</ul></div>
=======

If I make this element (#pic-cont) display:none, then the painting goes away. So it's definitely what's causing us trouble.

Comment 3

[Daniel Holbert [:dholbert]]

So on my linux system, this bug basically goes away if I disable e10s -- then, paint flashing *only* flashes the area that I'd expect it to (the image carousel).  mccr8 sees an improvement as well with his mac machine, but he still gets some over-invalidation.

So I think this may be a case where we're layerizing and causing ourselves extra work, like in bug 1211654. (though here, we don't have "opacity" involved).  (And depending on system characteristics, we layerize to a different extent -- e.g. mccr8 is getting some unfortunate-layerizing on his mac, and I'm getting less, which makes for more targeted paint flashing.)

Reclassifying as a layers bug.  mstange/mattwoodrow, any chance one of you could take a look?

Comment 4

[Daniel Holbert [:dholbert]]

[as noted in bug 984506 comment 2, Alexa says this site is #8 in china and #42 in the world]

Comment 5

[Markus Stange [:mstange]]

Somebody needs to create a reduced testcase for this invalidation. I could do it but I'm pretty swamped at the moment, so I'd appreciate it if somebody else did it.

Comment 6

[Markus Stange [:mstange]]

(In reply to Daniel Holbert [:dholbert] (less responsive Oct 9-12 & 15-18) from comment #3)
> So on my linux system, this bug basically goes away if I disable e10s

Can you try leaving e10s on and instead disabling APZ? It might be the display port that's responsible here, because it causes us to run layerization and invalidation on a larger part of the page.

Comment 7

[Daniel Holbert [:dholbert]]

You're right -- simply disabling APZ ( layers.async-pan-zoom.enabled ) has the same effect w.r.t. this bug as disabling e10s in comment 3, on my Linux laptop.  Once the page has stabilized, only the small slideshow's rect gets periodically invalidated, according to paint flashing. (which is ideal, I think)

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Since this only happens with APZ enabled, it affects 46+

Comment 9

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Attachment: Reduced_Testcase.7z

Hi,

I have attached the minimal page source in order to reproduce the problem.

Thank you.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

The 7z file in comment 9 contains a lot of stuff - it looks like sohu.com was just saved to undefined.htm along with a bunch of assets, and it doesn't appear to have been reduced very much or at all.

Comment 11

[Kartikaya Gupta (email:[e-mail])]

Oh my mistake, there is a Testcase.htm also which does appear to be somewhat reduced.

Comment 12

[huangwenjun06]

1:open link http://tv.sohu.com/20141208/n406764549.shtml,
2:right click on video, select video information to see fsp


Actual results:

3: enable e10s,  result: fps 7fps.
4: disable e10s,  result: fps 25fps

see bug1390481

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Andrew, do you still see the issue? On my MacBook the CPU load is kinda low unless I scroll through the page or have a lot of animations in the current viewport, which would be expected.

Comment 14

[Andrew McCreight [:mccr8]]

I wasn't looking at CPU load, I was looking at the results of mach power, and also looking at what happened when "paint flashing" was enabled. I don't really have time to look at this again.