1 of 19

Off Main Thread CSS Paint

BlinkOn 10 (Toronto, Canada)

xidachen@chromium.org, smcgruer@chromium.org

2 of 19

Before CSS Paint

.box {� background-image: url(“cat.jpg”);�}

3 of 19

CSS Paint enables new possibilities

class FooPainter {� paint(ctx, geometry, properties) {� // …� }�}��registerPaint('foo', FooPainter);

4 of 19

CSS Paint enables new possibilities

Cool corner shapes

Non-rectangular separators

5 of 19

More interesting with animations

Added to static getter function in FooPainter.

6 of 19

More interesting with animations

Ripple effects

Highlighter marker

7 of 19

Behind the scene...

Main thread is very busy doing:

Style
Layout
Paint
Animation

for all the 60 frames of that animation.�

8 of 19

Jank-free vs janky main thread

On a jank-free main thread

On a janky main thread

9 of 19

Wouldn't it be great if we could...

Not add more work to the main thread that is already busy?
Make the paint worklet animation unaffected by a janky main thread?

10 of 19

Solution: move it off the main thread

High-level idea:

Blink paint creates a placeholder for paint worklet.
Commit gives this placeholder to the compositor thread.
The compositor thread:

Runs any necessary animations
Dispatches the paint callback to a worklet thread and receives the result.
Fills in the placeholder with the result.

11 of 19

A bit more technical detail

Now

Paint

Tiling,

Raster, etc.

Skia

draw

cmds

Commit

Blink (Main Thread)

Compositor (Impl Thread)

PaintWorklet context (v8)

Animations

SLOW!

12 of 19

A bit more technical detail

Future

Paint

Composited Animations

Commit

Blink (Main Thread)

Compositor (Impl Thread)

Create PaintWorkletInputs

Tiling,

Raster, etc.

PaintWorklet Thread

LayerTree

HostImpl

FAST!

PaintWorklet context (v8)

PWIs

Skia

draw cmds

Impl-side Invalidation

This is what it looks like in the future.

Blink paint doesn’t run the paint callback anymore, instead it produce a PaintWorkletInput for each paint worklet. The PaintWorkletInput is basically an identifier for the paint worklet, with enough information that compositor thread needs.
Commit happens, PaintWorkletInputs gets pushed to the compositor thread.
Animation is now running on the compositor thread, which is the main difference. When the animation is running on the main thread, the main thread needs to produce a new frame when the animation is running. For example, a 2 second animation requires 2*60 main frames. When it is running on the compositor thread, the compositor thread only need to sync with the main thread for the first and the last frames of the animation.
The compositor ticks the animation, produces a new value, request a new impl frame, then send the PaintWorkletInputs to the paint worklet thread to run the JS paint callback, which produces a set of Skia draw commands.
The Skia draw command is sent back to the compositor thread, then compositor thread activate the pending tree, and raster the the contents.

13 of 19

Deep Dive - PaintWorkletInput

Encompasses all that is needed to find + execute a PaintWorklet.
Used across many threads - thread-safe refcounted.
But contains thread-unsafe data!

PaintWorkletInput

"green"

Name

200x500

Size

{

--foo: 20,

left: 50px,

color: 'red',

}

StyleMap

14 of 19

Deep Dive - Compositor

PaintWorklet affecting

animations tick

Scheduler::Set

NeedsImplSide

Invalidation

LTHI::UpdateSync

TreeAfterCommit

OrImplSideInvalidation

Blink Commit

Dispatch paint to paint worklet thread

LTHI::HandlePaint

WorkletResults

LTHI::

PrepareTiles

Unblock activation

if no

dirty PWIs

Dirty PaintWorkletInputs

Results

Animation is ticked the same way as the composited animation such as opacity, producing a new value for each animated property. The new value will be passed to the paint worklet thread to execute the paint callback.
Once we find that there are still paint worklet affected animations running, we ask the scheduler set a bit notifying that there needs to be a new impl frame. This is done by SetNeedsImplSideInvalidation.
The UpdateSyncTreeAfterCommitOrImplSideInvalidation is invoked by both the SetNeedsImplSideInvalidation and by Blink Commits. At this point, the PaintWorkletInputs should have been dirtied, either by the compositor animation, or by Blink commits. Then we dispatch all the PaintWorkletInputs to the paint worklet thread to execute the JS paint callback, and get the results back.
The results are a set of PaintRecords, which contains skia draw commands. This set of PaintRecords will be given to compositor thread, for tiling and raster, just like what happens today.
Besides that, when we receive the results from the paint worklet thread, we need to notify the scheduler that the pending tree is ready to activate.

15 of 19

Deep Dive - PaintWorklet Thread

PaintWorklet thread

Deduplication
Minimum thread hops

16 of 19

Current Status

Basic prototype in codebase behind a flag:

--enable-blink-features=OffMainThreadCSSPaint
Almost works e2e; one CL missing to fill in a few details.

Still to do:

cc-side re-architecture to these slides (current design uses raster)
Integration with cc-animations.
Fallback to main for PaintWorklets we can't (yet) support - <image> inputs.
Testing. Testing. Testing.

17 of 19

Summary

CSS Paint hands power to developers.
But it affects, and is affected by, main thread jank!
Our goal is to move CSS Paint off the main thread.

Then animations can be smooth even if the main thread is janky. And who doesn't love a smooth animation?

18 of 19

Questions?

19 of 19

Challenges

WTF::String
Cross-thread style map
DO NOT jank the compositor thread!