1094535 - offscreen animated images make us schedule a paint and build display lists to figure out to not paint

Status: RESOLVED DUPLICATE of bug 969406

(Core :: Layout, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I wrote:

I decided to investigate today while https://twitter.com/ uses so
much CPU when it's displayed.  (I'm using a debug build, and in a
session with a very large number of tabs, which can both skew
things, though probably the oddness is more likely the number of
tabs than the debug build nature, although probably 25% of the time
is debug build stuff.)

What seems to happen is that we're repainting frequently due to an
offscreen animated image,
https://abs.twimg.com/a/1415021474/img/t1/spinner-rosetta-gray-32x32.gif
, which is always near the very bottom of the page and thus very
rarely visible.

But each tick of the animated image (which I believe is a background
image) sends us through ImageLoader::DoRedraw, which in turn calls
nsIFrame::SchedulePaint, so that we do display list analysis to see
if anything changed.  (Nothing has, since the image is well
offscreen.)  But constructing and comparing the display lists takes
a good bit of time, leading to twitter using a good bit of CPU when
it's being displayed.

Is it reasonable to test that the image is offscreen (or, really,
not in the region that's painted into a layer) somewhere earlier in
the process here?  Or is there something else we should be doing to
avoid this?


roc replied:

Definitely. I think we can avoid the SchedulePaint if
InvalidateImagesCallback doesn't find anything to invalidate. Got a bug
number?

Comment 1

[Matt Woodrow (:mattwoodrow)]

I think this is a duplicate of bug 969406. I believe we need imagelib changes in order to know when we can skip the invalidation.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah, sounds like it.