Re: Comments on SVG Compositing

Hi Tab,

I'm not that familiar with the compositing spec either.
It seems like a mashup of the Adobe imaging model and Porter Duff which is
probably why it's confusing.


> I *really* don't like the current names of the clip-to-self property

or values.  One or both has to be changed; right now the property name

is nonsensical with the values, in my opinion.  As a not-very-good

suggestion, maybe "clip-to: src | canvas"?


I agree.


>

I don't quite understand the usage of the 'knock-out' property.  I
> understand what it does, but it seems to apply to rendered elements,
> while the property is defined to apply to grouping elements.  In the
> examples given, is 'knock-out' specified on either of the components
> (the squiggly line or the blue disc), or is it on a container that
> contains both of the components?
>

It is on the container that contains both elements.
This is a keyword from AIM (=Adobe Imaging model).
'enable-background' is also from AIM, but we called it 'isolated group' and
set it to false by default.


> It appears that all of the first three properties are simply shortcuts
> for more complex series of compositing operations.  Is this correct?
> For example, in the "knockout:replace" example, it appears that one
> could achieve the same result with "d over (d dst_out e)".


You are correct that this achieves the same effect.
However, things will get increasingly more difficult as you have more
elements within the container.
ie if you have 3 circles intersecting and each have a blend mode:
- the top circle blends with the background as always
- the next circle down needs to (d dst_out e) to get the new shape and then
blend
- the botton circle does (d dst_out e) with e being a combination of the
previous 2 shapes and then blend.

So, to get the same effect as 'knock-out' using PorterDuff blending, you
need to reverse the drawing order AND keep track of the previous shapes AND
subtract those from the current shape.
This gets quite complicated...


> Similarly,
> the "clip-to-self:canvas" example seems equivalent to "((e xor f) in
> g) over ((e xor f) dst_out g)".  It might be useful to define these
> properties explicitly in terms of virtually transforming the comp-op
> sequence.  'enable-background' is the same, down to the insertion of a
> dst_out operation.
>

This is not quite right. If e or f have alpha they will composite with g.
It's just their blending that won't interact with g.


> I don't have strong graphics experience, so there may be something I'm
> missing here, but 'enable-background' and 'knock-out' appear to be
> *exactly* identical in operation, just applying to different things:
> 'knock-out' transforms "A op B" to "A op (A dst_out B)", while
> enable-background transforms "[group image] over [background]" to
> "[group image] over ([group image] dst_out [background]".  Can these
> two properties be unified in some way?
>
> knock-out = how objects within the container blend with each other
enable-background = how objects within the container blend with the
background
The programming logic between the 2 modes is very different so I think that
this is enough for a separate attribute.

If you unify them into 1 property, it would also result in many states:
knock-out (= 3 states) * enable-background (= 3 states) = 9 different names
which is more confusing.

Rik