Re: [css compositing] clipping and isolation

Hi,

On Aug 7, 2013, at 11:05 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> The blending specification currently calls out that clipping should introduce isolation [1].
> So if you have content as follows:
> <circle id="a"/>
> <g clip-path="...">
> <circle id="b" style="mix-blend-mode:difference"/>
> </g>
> circle 'b' won't blend with circle 'a'. 

I think we can not isolate this discussion just on SVG (pun). I cc'ed fxtf mailing list, since it is a problem that hopefully should be fixed for CSS clip-path in general and not just on SVG.

> 
> I added this because we were worried that graphics libraries wouldn't not be able to support this.
> Now that we started implementing the feature, it turns out that this limitation is not needed when the browser uses the clipping capabilities of the underlying graphics library.
> 
> For 'simple' clips (that are the vast majority), all browsers use the clipping code.
> However, for more complex clips, certain browsers turn the clip into a mask and this will execute a different code path that does isolate.
> 
> There are three options (from my least to most desired):
> 1. keep behavior as specified in the spec.
> 2. specify that complex clips cause isolation but not simple clips.
> 3. specify that clipping never isolates. Browsers will need to find a way (ie planarization/path collapsing) to keep using the clipping code path.
> 

As you note, it always just has been a problem of complex clip-path operations. A simple example is when you combine two paths with different clip rules (winding rules). Many browsers traditionally did not use clipping for these cases but masking operations. Masking operation usually cause isolation. In our tests we figured out that this is not always the case or not the case anymore:

* Safari (one port of WebKit) does use masking, but did not have isolation behavior.
* Blink uses a path planarizer in Skia to flatten the path and uses the real clipping operation with this planarized path (in nearly all cases).

On the other side:
* Firefox uses clipping for simple clip-path operations and isolated masking on complex clipping.
* Same for all other WebKit ports than Safari.

We could just test WebKit/Blink/Gecko based implementations where we had the access to the source code. The isolated behavior can not be experienced with simple source-over compositing as implemented today. So we could not test if IE can implement clip-path in an not-isolating way.

As a note, implementations that use masking for simulating clipping might not follow the spec that requires aliased clipping anyway. Masking is usually done drawing the mask onto an intermediate image buffer with AA.

Solutions for implementations could be to look at path planarization (as Blink does). There are some open source projects that try to do path planarization. Some are quite good some at least not bad. I was told that the Skia code is quite generic. So UAs with different graphic libraries can look into splitting Skia for their own needs.

Clipping creates a stacking context (important for HTML). However, the implementation is not different from the implementation in SVG. That is why it makes sense to look at the feature itself and don't split the discussion into HTML and SVG.

I should say that I am in favor for not-isolated behavior on clipping, but it needs some work in implementations that do masking to simulate complex clipping. 

Greetings,
Dirk

> Thoughts?
> 
> 1: http://www.w3.org/TR/compositing-1/#csscompositingrules_SVG

Received on Wednesday, 7 August 2013 12:31:41 UTC