RE: [css compositing] clipping and isolation

I'm not sure if it is relevant or not, but the notion of intersecting
clipPaths is explored a bit in this  example from about eight years ago.
IE/ASV could do it "properly" (as per this author's common sense) at the
time. After a year or two Opera did it properly. A year or two ago Chrome
finally figured out how to handle the application of one clipPath to
another, though Safari doesn't handle the JavaScript to SMIL business quite
right yet, although it and IE9 do manage the clipping okay. Firefox doesn't
render anything of the example at right.  

 

http://srufaculty.sru.edu/david.dailey/svg/newstuff/clipPath4.svg

 

cheers

David

 

From: Rik Cabanier [mailto:cabanier@gmail.com] 
Sent: Wednesday, August 07, 2013 12:59 PM
To: Dirk Schulze
Cc: www-svg; public-fx@w3.org
Subject: Re: [css compositing] clipping and isolation

 

 

On Wed, Aug 7, 2013 at 5:31 AM, Dirk Schulze <dschulze@adobe.com> wrote:

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.

 

Yes, it would be great to know if closed-source implementations can
implement this, or are willing to use a planarization library.

As you note, this will also improve the quality and speed of complex clips.

 


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.

 

If it creates a stacking context, a clip in HTML should causes isolation
according to the compositing spec. [1]

2D transforms had the same issue and people insisted that we force them into
isolation.

 

Maybe we can keep the current defintion and fix this in the next revision of
the spec where we introduce non-isolated groups.

 

 


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

 

1: http://www.w3.org/TR/compositing-1/#csscompositingrules_CSS