1421325 - twitter.com is constantly doing painting when you view a long thread, due to offscreen spinner animated gif

Status: NEW

(Core :: Layout, enhancement, P3)

Description

[Nicolas B. Pierron [:nbp]]

page: https://twitter.com/LacesOutShow/status/934872305540399104
Profile: https://perfht.ml/2jtbOL6

The profile reports a tons of RefreshDriverTicks and a tons of Style & Reflow, while I never touch my laptop after refreshing the page.

I am opening this bug, because I *presume* that this implies that we are running code to display a still page, which might impact the battery life while reading twitter content.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

I can't reproduce this.  Do you get this behavior with a fresh profile or in safe mode?

FWIW, the URL looks like:

https://twitter.com/LacesOutShow/status/934872305540399104

Comment 2

[Nicolas B. Pierron [:nbp]]

I get this behaviour on a fresh profile, using the latest nightly.
I am using the nouveau driver, if this is in any way related to the RefreshDriverTicks.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Mark for [qf] for someone to investigate.

Comment 4

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

Hey nbp, are you still able to reproduce this reliably? The profile suggests something is animating, but (with paint flashing enabled), we can't see what that might be.

Comment 5

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

(In reply to Mike Conley (:mconley) (:⚙️) from comment #4)
> Hey nbp, are you still able to reproduce this reliably? The profile suggests
> something is animating, but (with paint flashing enabled), we can't see what
> that might be.

Actually, it turns out we can reproduce this, so no info required.

Comment 6

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

Hey :hiro, I know you've been focused on the accidental painting of hidden elements lately. Does this fall into that category? When we profile the page in comment 0, we see hints that something is painting regularly, but paint flashing doesn't reveal it.

Comment 7

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

dholbert points out that it might be the spinner that appears at the very bottom of the tweet list (usually scrolled out of view) to indicate that more tweets are loading.

Comment 8

[Daniel Holbert [:dholbert]]

I looked at this a bit and confirmed that it's that spinner.  Specifically: if I add this rule via the "Stylus" Firefox addon...
  .spinner { display: none !important}
...then those refresh driver ticks disappear from the profile.

Here's a profile without that change: https://perfht.ml/2BFWkdt (twitter is content process 3, & notice all the ticks)
Here's a profile with that change: https://perfht.ml/2BESscZ (twitter is content process 2, notice no ticks)

The spinner element is simply a 32x32 block with
> background: url(../../img/t1/spinners/spinner-rosetta-gray-32x32.gif) no-repeat 0 0;
...using this image:
https://abs.twimg.com/a/1517272936/img/t1/spinners/spinner-rosetta-gray-32x32.gif

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Yeah, that animated GIF is a culprit.  I can't see any CSS animations/transitions or script animations that keep running, I only see one CSS transition but it finishes soon (0.15s duration).

So, it's related to bug 968123 or bug 987212 more or less.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: non-testcase 1 (doesn't reproduce the bug)

Here's an *attempt* at a testcase, based very roughly on this Twitter page, but it doesn't reproduce the bug.

With this testcase, I *only* see frequent "nontrivial" refreshdriver markers if I scroll all the way to the bottom -- scrolling the animated image into view. (By "nontrivial markers", I'm talking about a full column of markers in the "marker chart" view -- including styles,reflow,rasterize,etc.)

And those markers stop after I scroll back up.  So I think we're doing the right thing on this testcase, and there must be some other wrinkle about the twitter scenario that makes it behave differently...

Comment 11

[Daniel Holbert [:dholbert]]

(oops, I midair'ed hiro; just seeing comment 9 now.)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #9)
> So, it's related to bug 968123 or bug 987212 more or less.

Right! Or possibly bug 805343 even.

Comment 12

[Daniel Holbert [:dholbert]]

(I'll obsolete my non-testcase, since I can confirm we *do* have a working testcase over on bug 805343 for example.)

Also: I imagine this is more of a power concern than a perf concern (per comment 0 and the fact that the observed refresh driver ticks are super-short). Hence, I'll mark this [qf-][Power] to get it classified as a power bug (though really possibly a dupe of one of the bugs hiro mentioned)