Moving clip-path to the compositor

[Jake Archibald]

Looking across the material design transition examples, many of them involve animating the clipping of an element.

clip-path isn't a fast-path in Chrome (it's much better in Safari) so developers have to resort to horrible hacks, or just give up.

For more details, including transition examples, I've thrown together a doc (open to comments).

Is there any chance that improving this could get some priority?

[Robert Flack]

I think our existing compositing could accelerate rectangular clip-path animations (as it is similar to the horrible hack), but it would have to be special cased for rectangles as clip-path in general requires painting a clip mask. Supporting this general case would require knowing how to interpolate the shape and paint the mask layer. Is my thinking that the use cases seem to just require a rectangle correct? I.e. some of the rectangles seem to have rounded edges but presumably during a short animation the corners could be clipped square (especially if the background was still drawn rounded separately). Also for the examples, you'd still need to create a second element which matches the clip path so that the box shadow tracks correctly otherwise you'll get a clipped shadow.

I think the most ergonomic way to do these effects would be by animating width / height on an overflow: hidden element. Making this accelerated would of course be a ways off but animating layout gives all of the semantics (keeping a constant border-radius, updating shadow, clipping contents) that the animation should do.

[Philip Rogers]

Do we know how Safari is faster? Their compositor design is similar to ours.

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+unsubscribe@chromium.org.
To post to this group, send email to pain...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAJh39TOurm1%2BqA6GM9%2BfFuaDF%3DhHt%2B_tcY7VecjZQ98v8FgbkA%40mail.gmail.com.

[Ali Juma]

They (using our terminology) create a mask_layer_ in CompositedLayerMapping for clip-path (we only use mask_layer_ for masks). See https://trac.webkit.org/r180882 and https://trac.webkit.org/r180948. 

On Mon, Jun 5, 2017 at 12:35 PM Philip Rogers <p...@chromium.org> wrote:

Do we know how Safari is faster? Their compositor design is similar to ours.

On Mon, Jun 5, 2017 at 8:38 AM, Robert Flack <fla...@chromium.org> wrote:

I think our existing compositing could accelerate rectangular clip-path animations (as it is similar to the horrible hack), but it would have to be special cased for rectangles as clip-path in general requires painting a clip mask. Supporting this general case would require knowing how to interpolate the shape and paint the mask layer. Is my thinking that the use cases seem to just require a rectangle correct? I.e. some of the rectangles seem to have rounded edges but presumably during a short animation the corners could be clipped square (especially if the background was still drawn rounded separately). Also for the examples, you'd still need to create a second element which matches the clip path so that the box shadow tracks correctly otherwise you'll get a clipped shadow.

I think the most ergonomic way to do these effects would be by animating width / height on an overflow: hidden element. Making this accelerated would of course be a ways off but animating layout gives all of the semantics (keeping a constant border-radius, updating shadow, clipping contents) that the animation should do.

On Mon, Jun 5, 2017 at 8:39 AM, Jake Archibald <jakear...@chromium.org> wrote:

Looking across the material design transition examples, many of them involve animating the clipping of an element.

clip-path isn't a fast-path in Chrome (it's much better in Safari) so developers have to resort to horrible hacks, or just give up.

For more details, including transition examples, I've thrown together a doc (open to comments).

Is there any chance that improving this could get some priority?

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.

To post to this group, send email to pain...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAJh39TOurm1%2BqA6GM9%2BfFuaDF%3DhHt%2B_tcY7VecjZQ98v8FgbkA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.

To post to this group, send email to pain...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAJgFLLvXNMSyz8GKZCyMWgq8HHKZrgorZ0v7YGCmGC5c_rb_hQ%40mail.gmail.com.

[Tien-Ren Chen]

IIRC clip-path itself is not a direct compositing trigger, but we do
composite clip-path if the element needs compositing somehow (for
other direct reasons or composited descendants).

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=745
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=2372

The problem is that the current CSS transition/animation spec doesn't
cover how clip-path should be interpolated. First we have that, so web
developer has an API to tell user agent how to animate clip-path
programatically, then we can teach blink/cc how to animate that on the
impl-thread.

> https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CANLC6v0QGwU7yU0XRtC8o71w-z6cB-%2BG_NKRVJWr8209zGsZ7Q%40mail.gmail.com.

[Ali Juma]

On Mon, Jun 5, 2017 at 7:14 PM Tien-Ren Chen <trc...@chromium.org> wrote:

IIRC clip-path itself is not a direct compositing trigger, but we do
composite clip-path if the element needs compositing somehow (for
other direct reasons or composited descendants).

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=745
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=2372

I believe that layers clips descendants, but not the CLM::MainGraphicsLayer itself. That still seems to be done at paint time.

 

The problem is that the current CSS transition/animation spec doesn't
cover how clip-path should be interpolated. First we have that, so web
developer has an API to tell user agent how to animate clip-path
programatically, then we can teach blink/cc how to animate that on the
impl-thread.

For basic-shape clip-paths (e.g. circles, ellipses, polygons), interpolation is spec'd here: https://drafts.csswg.org/css-shapes/#basic-shape-interpolation 

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAKxkHO80PQ-4rJWra_GxzPZ3gsCog%2BOh%2BjtdHhfQ9ve7fJO_mA%40mail.gmail.com.

[Tien-Ren Chen]

On Mon, Jun 5, 2017 at 4:45 PM, Ali Juma <aj...@chromium.org> wrote:
>
>
> On Mon, Jun 5, 2017 at 7:14 PM Tien-Ren Chen <trc...@chromium.org> wrote:
>>
>> IIRC clip-path itself is not a direct compositing trigger, but we do
>> composite clip-path if the element needs compositing somehow (for
>> other direct reasons or composited descendants).
>>
>>
>> https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=745
>>
>> https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=2372
>
>
> I believe that layers clips descendants, but not the CLM::MainGraphicsLayer
> itself. That still seems to be done at paint time.

There is the layer_to_apply_child_clipping_mask right next to it:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp?rcl=582feef2ec35d80ce6c16da102f7fc337f59be21&l=750
It seems to apply to the main graphics layer if a clip-path is present
(ugh, super questionable).
Nevertheless it is doubtful if we do the right thing by skip applying
clip-path in main thread...

>> The problem is that the current CSS transition/animation spec doesn't
>> cover how clip-path should be interpolated. First we have that, so web
>> developer has an API to tell user agent how to animate clip-path
>> programatically, then we can teach blink/cc how to animate that on the
>> impl-thread.
>
> For basic-shape clip-paths (e.g. circles, ellipses, polygons), interpolation
> is spec'd here:
> https://drafts.csswg.org/css-shapes/#basic-shape-interpolation

That's great info! We should think about implement it then. You
mentioned in the doc that these would be better implemented as
shaders. +1 to that.
I think raster-inducing-animation is generally difficult in our
current cc scheduling system, due to the problem of chasing a moving
target. For basic shapes we maybe able to get away with a shader.

> https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CANLC6v3ZOHsmeFu--QWW5FtSq3NhZ7MwynkLqhdDpkynQREsFQ%40mail.gmail.com.

[Jake Archibald]

On Mon, 5 Jun 2017 at 16:38 Robert Flack <fla...@chromium.org> wrote:

…it would have to be special cased for rectangles as clip-path in general requires painting a clip mask. Supporting this general case would require knowing how to interpolate the shape and paint the mask layer. Is my thinking that the use cases seem to just require a rectangle correct? I.e. some of the rectangles seem to have rounded edges but presumably during a short animation the corners could be clipped square

That would be a big step forward. The lack of rounded corners would be noticeable, but it isn't needed in all cases.

 

you'd still need to create a second element which matches the clip path so that the box shadow tracks correctly otherwise you'll get a clipped shadow.

Or you could use a filter http://jsbin.com/ticeve/edit?html,css,output - this seems pretty fast in Safari.

[Jake Archibald]

On Tue, 6 Jun 2017 at 01:47 Tien-Ren Chen <trc...@chromium.org> wrote:

On Mon, Jun 5, 2017 at 4:45 PM, Ali Juma <aj...@chromium.org> wrote:
> For basic-shape clip-paths (e.g. circles, ellipses, polygons), interpolation
> is spec'd here:
> https://drafts.csswg.org/css-shapes/#basic-shape-interpolation

That's great info! We should think about implement it then. You
mentioned in the doc that these would be better implemented as
shaders. +1 to that.
I think raster-inducing-animation is generally difficult in our
current cc scheduling system, due to the problem of chasing a moving
target. For basic shapes we maybe able to get away with a shader.

Supporting polygon() here would help us fake rounded corner animations a little more convincingly. 

FWIW we already support animating SVG paths using CSS properties http://jsbin.com/sinuqek/edit?html,css,output. Not on the compositor of course.

[Jake Archibald]

I don't suppose this is getting any attention in 2018? It's still one of the slow paths for common web transitions.

[Chris Harrelson]

On Mon, Jan 8, 2018 at 4:29 AM, Jake Archibald <jakear...@chromium.org> wrote:

I don't suppose this is getting any attention in 2018? It's still one of the slow paths for common web transitions.

It is getting some attention. In particular, Tien-Ren is doing a lot of work to clean up and improve the implementation details of clip path, in anticipation of allowing animation on the compositor in the future.

 

--

You received this message because you are subscribed to the Google Groups "paint-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+unsubscribe@chromium.org.

To post to this group, send email to pain...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAPy%3DJop6LfFLCsGuLEcfapC7j-UVi9x%2BmUExUtHTiek-74NiKw%40mail.gmail.com.

[Jake Archibald]

Great to hear! Thanks

On Mon, 8 Jan 2018, 23:54 Chris Harrelson, <chri...@google.com> wrote:

On Mon, Jan 8, 2018 at 4:29 AM, Jake Archibald <jakear...@chromium.org> wrote:

I don't suppose this is getting any attention in 2018? It's still one of the slow paths for common web transitions.

It is getting some attention. In particular, Tien-Ren is doing a lot of work to clean up and improve the implementation details of clip path, in anticipation of allowing animation on the compositor in the future.

 

On Tue, 6 Jun 2017 at 11:45 Jake Archibald <jakear...@chromium.org> wrote:

On Tue, 6 Jun 2017 at 01:47 Tien-Ren Chen <trc...@chromium.org> wrote:

On Mon, Jun 5, 2017 at 4:45 PM, Ali Juma <aj...@chromium.org> wrote:
> For basic-shape clip-paths (e.g. circles, ellipses, polygons), interpolation
> is spec'd here:
> https://drafts.csswg.org/css-shapes/#basic-shape-interpolation

That's great info! We should think about implement it then. You
mentioned in the doc that these would be better implemented as
shaders. +1 to that.
I think raster-inducing-animation is generally difficult in our
current cc scheduling system, due to the problem of chasing a moving
target. For basic shapes we maybe able to get away with a shader.

Supporting polygon() here would help us fake rounded corner animations a little more convincingly. 

FWIW we already support animating SVG paths using CSS properties http://jsbin.com/sinuqek/edit?html,css,output. Not on the compositor of course.

--

You received this message because you are subscribed to the Google Groups "paint-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.

To post to this group, send email to pain...@chromium.org.

[Tien-Ren Chen]

In case anyone is interested, I'll go into some details.

Today in SPv1 compositing system, clip-path is applied in many places:
Need to inherit a clip but the clip is not inherited by compositing
layer tree? Create a clip layer and apply clip-path to it.
Have a composited tranasform? Create a composited layer and apply
clip-path to it.
Need to clip composited descendants? Create a child clipping layer and
apply clip-path to it.

This is redundant and can actually introduce incorrect results when it
interacts with other effects such as filter and border radius. Also
make it a pain to animate in impl thread, because multiple layers need
to be mutated, and the clip-path is mixed with other contents in the
layer.

Right now I'm working on a CL to ensure composited clip-path is only
applied once, in the right order. In hope that it will improve
correctness and also simply the code.

This only removes one blocker from impl-side clip-path though. I feel
the hardest problem to solve is still the tile scheduling issue around
animation-induced raster invalidation. (Or implementing a specialized
shader. It is hard too.)