Perf Audit

[paulirish]

Going to dump my notes in here an edit as I go.

Starting with the master branch as that seems preferred for ergonomics.

• Test URL: http://rawgit.com/kdzwinel/progress-bar-animation/master/index.html
• Setup: MacBook Air (to start with)

Looks like a case of heavy rasterization. SVG gets this a lot.

Let's see what we can do!

[paulirish]

I applied some absolute positioning to visually distinguish things with paint flashing on.

Okay so the SVG is rasterizing each frame. The DIV only rasterizes at the toggle.

Still I think the DIV shouldn't need to rasterize much at all. Curious if we can get rid of that.

(That said, the SVG rasterization is whats really important)

[paulirish]

Nuking the raster costs on the avatar div

will-change: transform on both the div.avatar and the .avatar-box:before take care of the rasterization flashes: Woo!

Before and After

We're looking at the exact same flip here. That raster cost in the middle is gone.

[paulirish]

raster costs of the SVG

Setting display: none !important; on the avatar, now that it's sorted, so we can look at the SVG all alone.

Yup. It's just hitting a lot of rasterization costs on every frame.

Damn. using the animation editor is a nice way to diagnose the animation itself. Pause and scrubber dragging totally kick ass:

---

Now, re-reading the project readme. The technique explored in "reverse" is my best guess for what's going have the most promise. Going to move over there.

[paulirish]

Splitting apart the SVG layers

Using the reverse branch, I again see that raster costs of the SVG during its path animation are the problem. I was curious if we could reduce that cost by getting rid of some extra stuff. So I tried splitting the white circle in the middle of the SVG out to a static SVG that doesn't change:

Comparing it to before, the rasterization costs seem much smaller.

NEVERMIND. Put back the white circle and the raster costs are still down. Maybe it was something else I did.

[paulirish]

Oh reverse is just much less rasterization than master was. That's all. :) Nice job.

[paulirish]

reverse on Android

Things are looking fine on desktop, even with CPU throttling, so over to remote debugging my nexus 5X

Raster time is bigger here. ~12ms per frame. With that time, it's possible we could still hit 60fps, but it'd be tight.

Unfortunately, the GPU is the bottleneck here. Bigtime.

Curious about Ganesh in this case....

[paulirish]

Ganesh & GPU

Ganesh is on.. I tried turning it off, but there's not a sigificant difference either way.

GPU is the bottleneck for sure.

Tracing to see if that provides any more details:

No insights here. Just taking time flushing all the work to the GPU each frame.

[paulirish]

I've exhausted my own techniques on this one.

cc @progers @fregu In case you guys are interested in a a well-optimized SVG animation that just isn't good enough. See the readme at https://github.com/kdzwinel/progress-bar-animation for details.

Repro:

1. Open http://rawgit.com/kdzwinel/progress-bar-animation/reverse/index.html on mobile
2. See that raster + GPU costs are a bit costly. Main thread compositing is also reliably expensive.
3. Try to reduce those costs.

[nathanmarks]

@paulirish this is very problematic with material design spinners when used in an application transition state. Can we expect any improvements here in the medium term?

[tigt]

@paulirish From what's public, Ganesh appears not to work at all when some SVG is involved:

Note that GPU rasterization can get vetoed based on the content itself. For example, if page contains many SVGs with non-convex paths (common for SVG icons), GPU rasterization may get disabled for that page load.

[progers]

It's not a complete veto for svg. The heuristic is based on the absolute number of non-convex paths.

There are two ongoing projects in progress now that will likely remove this heuristic/veto soon.