Re: [css compositing] clipping and isolation

Hi David,

the clipping paths in your example are all 'simple'. A complex clip
contains more than 1 path.
I see that there's a clip with a clip which does not make it complex.

Rik

On Wed, Aug 7, 2013 at 3:34 PM, David Dailey <ddailey@zoominternet.net>wrote:

> 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 ****
>
> ** **
>