[css-compositing] simplify Porter-DUFF (was: some proposals)

>
>
> >b. simplify Porter-Duff
> >- remove the clip-to-self property. The default behavior becomes
> 'clip-to-self: object'. Does anyone believe that 'clip-to-self: canvas' is
> useful? It feels strange to have that option in SVG.
>
> I don't have a strong opinion on this one - the original P-D paper from
> 1984 applied to the canvas
> whilst Java2D was effectively 'object'. Android supports P-D that I think
> can apply to the
> canvas but I'd need to check.
>
> Possibly the best way forward is to get rid of the property, limit it to
> 'object' and if future need
> for the entire canvas happens we can re-add it in a future revision of the
> spec.
>
> I think authors right now would find the blend modes most useful and P-D
> less interesting in
> the short term (until authoring tools catch up).
>

I agree.


>
> >- 'enable-background' does not apply. Children with blending will
> composite up to the group with PD blending. (In effect, PD will always
> imply 'enable-background: new')
>
> Oh no. PD doesn't ever imply 'enable-background:new' - that's confusing it
> with filters again.
> P-D is a logical operation on objects not a bitblt operation into a
> backing store (even though
> many implementations choose to implement it in a similar way).
>

I was trying to clear this up because the current SVG spec does imply that
PD should honor this keyword.
Now that we decided to split up the spec, this becomes cleaner as well
since we can state that it only applies to the 'blend' attribute.

I have to think through how 'enable-background' would work exactly with the
other PD modes.
The SVG filter spec mentions: Then, for each Ai (from i=1 to n-1),
composite BUFi into BUFi+1.
Would the layers composite with 'src-over' or their compositing operators?
It feels more natural that the PD other than 'src-over' imply a new
stacking context (but I could be wrong here).


> If you 'in' two objects you can do it by generating the intersection
> geometry and filling it or
> any other means you like. It's entirely possible with a pixel sequential
> renderer to rasterize
> the 2 objects at the same time and emit only the intersection, etc. So
> there is no implied
> intermediate bitmap to get created.
>
> The effect may be the same as if 'enable-background:new' were set, but
> it's important to
> make sure people don''t expect that bitmaps will be created, memory wasted
> and the
> associated slowdowns of bitblts, etc. will happen. If you're P-D combining
> a group
> then you probably need an intermediate bitmap but the whole background
> removal
> part of the compositing spec. was aimed to handle both settings of
> enable-background.
>
> The wording about enable-background was trying to nail down two different
> descriptions
> that were in an older SVG spec. draft into one that people could
> understand better
> but it looks like it's missed the mark.
>

Yes, it's currently very confusing but understandable since it's such a
hard concept to put down in writing.
In a design app like Illustrator, it feels very natural but the math is
hard.



>
> >- 'knock-out' on the nearest ancestor with blending does not apply. If it
> has 'knock-out: preserve', the group with the PD compositing operator will
> still knock out.
> >- Simon Fraser expressed concern that this compositing operator required
> access to the entire background image. Maybe we should specify that all PD
> blending should be done inside a group that has 'enable-background: new'.
>
> My preference at this time would be to remove knock-out as well as
> clip-to-self.
>
>
I think we would prefer to see knock-out implemented since it is part of
the PDF imaging model and use often by designers.
We can put it in, but not treat it as an important item.

Rik