1375218 - Slow painting on israelnationalnews.com

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

http://www.israelnationalnews.com/ has a "News Briefs" scroller that causes us to more or less peg a CPU, at least on Mac.  I see 60% usage from the web content process and another 30% from the chrome one.

Profile at https://perf-html.io/public/e1c4971483f18018b7022c8379a9df51e8b6b88b/calltree/?invertCallstack&thread=3 and one interesting thing is that we're spending 1/6 of the time or so under layers::CreateBackBufferTexture allocating shmem textures and filling them with _ARGBSetRow_X86 (called by _ARGBRect called by ShmemTextureData::Create)...

Why do we keep creating new textures here?

Comment 1

[Jeff Muizelaar [:jrmuizel]]

(In reply to Boris Zbarsky [:bz] (if a patch has no decent message, automatic r-) from comment #0)
> 
> Why do we keep creating new textures here?

Usually this is because our tile pool is too small. There's a pref that let's you increase its size that you could try.

For fun, I tried out my current webrender build and it had noticeably less cpu utilization than Nightly.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Do you happen to know the pref offhand?  Nothing in about:config for "tile" or "texture" is an obvious pool size...

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Here are the prefs:

layers.tile-initial-pool-size
layers.tile-pool-unused-size


We should probably add them to all.js

Comment 4

[Boris Zbarsky [:bzbarsky]]

I bumped those to 300 and 100 respectively, but no obvious improvement.

Comment 5

[Daniel Holbert [:dholbert]]

The animation of the news-headline-scroller effect is animating "margin-top" (using JS + inline style). Every tweak to "margin-top" (every rAF animation frame) causes the whole element to be repainted, even though its contents haven't changed.  IIUC, this is unavoidable, unless we can layerize that element and interpret "margin-top" tweaks as layer-move operations.

Any chance it'd be feasible to layerize here & move the layer with "margin-top"? 

(Also, as another data point, mconley says he sees Safari giving similar performance to what bz described in comment 0 -- 50%+ CPU usage for painting, with the headline scroller being continuously repainted.)

Comment 6

[Gregory Pappas [:gregp]]

Daniel, do you think this is safe to close? I'm seeing about 10% content process, 15% parent process CPU usage in this case. https://share.firefox.dev/3m370zK

Comment 7

[Gregory Pappas [:gregp]]

Oops, I made a mistake in comment 6 and accidentally profiled a snapshot of the site from 2019. A snapshot of the site that's closer to when this bug was reported does show slightly higher CPU usage than the 2019 snapshot. About 12% content process, 17% parent process. https://share.firefox.dev/3YMLg9X

Comment 8

[Daniel Holbert [:dholbert]]

Thanks for reprofiling this, gregp!

Yeah, looking at this now (using your 2017 archive.org URL added in comment 7), I'm not seeing anything close to 60% + 30% mentioned from comment 0; and Chrome shows similar CPU usage to us when loading the same content. So I think we're on-par with the competition now and have improved from the state described in comment 0.

Let's call this worksforme.

Comment 9

[Gregory Pappas [:gregp]]

Mozregression tells me that enabling WebRender by default is what fixed this case.