Re: Comments on SVG Compositing

> Rik, thanks for the response!  I understand some of the design choices
> a little more.
>
> I still have a problem with 'clip-to-self'.  There are some operations
> in which it can be useful, but others in which it's useless and kinda
> confusing - one should instead use the appropriate normal compositing
> operation.
>
> For example, applying "clip-to-self:object" to A in "A clear B" is
> exactly equivalent to applying "clip-to-self:canvas" to A in "A
> dst-out B".  Lessee, I'll make a quick table...
>
> "object"     => "canvas"
> A clear B    => A dst-out B
> A src B      => A src-over (A dst-out B)
> A src-in B   => (A src-in B) src-over (A dst-out B)
> A dst-in B   => (A dst-in B) src-over (A dst-out B)
> A src-out B  => (A src-out B) src-over (A dst-out B) (A xor B *almost*
> works, but it's not quite the same)
> A dst-atop B => A dst-over B
>
> If I were designing this myself, I'd remove the ability of c-t-s to
> affect clear and dst-atop, since you can just use a better comp-op
> instead.
>
> The other 4 seem useful, but they also seem incomplete - if it's
> useful to use this with "A src B" (keeping the part of B outside of
> A), then wouldn't it be just as useful to use it with "A dst B"
> (keeping the part of A outside of B)?  Is there a good reason why we
> don't have this reversed capability, which we could apply to 'dst' and
> 'dst-out' (and apply to src-in and dst-in to get a different
> behavior)?  Something like "comp-clip-to: canvas | src | dst |
> intersection", with the default being 'canvas'.  The currently-defined
> value of "object" would be 'src', affecting the src, src-in, dst-in,
> and src-out operators.  'dst' would affect the dst, src-in, dst-in,
> and dst-out operators.  'intersection' would only affect src-in and
> dst-in.
>
> This is general and easy to understand - the compositing is limited to
> certain bounds, with stuff outside those bounds unaffected by the
> composition.  The name also makes clear that it's the *compositing*
> that is being clipped; the current name seems to be backwards to
> someone relatively unfamiliar with the terms of art, as it seems like
> you are "clipping to the object" when you remove the destination, and
> "clipping to the canvas" when you keep it - the opposite of what the
> values actually do!
>
>
I'm not familiar with the "clip-to-self" concept so it's better if someone
else responds to this.


> ----------------
>
>
> The 'enable-background' property still seems confusing because it
> appears to reverse the ordering of the operations, but I think that's
> just because of the way the example is laid out - we naturally assume
> that you should start by resolving operations from the inside out,
> when the actual drawing order is the opposite.  That is, the
> 'accumulate' example appears to use the following markup:
>
> <svg ...>
>  <rect ... />
>  <g enable-background='accumulate'>
>    <circle ... />
>    <polygon ... comp-op='multiply' />
>  </g>
> </svg>
>
> Is this right?


yes.


> Presenting it in such a way would, I think, make it
> easier to understand what's happening, and why the triangle is the
> only thing affected by the property in that example (the circle is
> composited over the background with 'src-over' and is fully opaque, so
> e-b doesn't make a difference here).  The presentation that the
> example uses, where the compositing operations are binary operation
> between elements, feels misleading.
>

I agree. Maybe not misleading, but it is confusing.


>
> -------------------
>
>
> >> 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.
>
> Your description makes them seem even more similar.  ^_^  From the POV
> of an author with relatively little graphics experience, there's no
> important difference between these two for me.  The fact that
> implementations might implement the two in different fashions is
> irrelevant to me, because I'm not an implementor.
>
>
> > 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.
>
> I'm not sure I understand.  'knock-out' and 'enable-background' have
> only two states each.


They also have separate 'inherit' states.


> Further, the syntax seems like it can be very
> simple; something like:
>
> comp-over: none | [ group || [ background | rect(x,y,w,h)] ]
>
> ...with 'comp-over: group background;' being the default.
>
>
Does 'group' correspond with 'knockout = false'?


> The only thing that would let me justify this being split into two
> property would be if it seems like it's useful to have these cascade
> separately.  I don't have enough experience with using these to
> understand if that's something important or not.
>

Adobe applications have the ability to control the 2
properties independently including the 'inherit' state.
I believe this was done because they are conceptually different for
designers.
ie see these articles:
http://layersmagazine.com/the-joys-of-isolation-blending.html
(enable-background
is the same property as isolate)
http://www.creativepro.com/article/illustrator-how-this-technique-a-real-knockout

In our apps, the default state of 'knockout' is 'inherit' while
'enable-background'/'isolate' is 'true'/'false' by default.
(In our imaging model, the 2 values are simple booleans. The application is
expected to resolve the 'inherit' value before exporting to PDF)


>
>
> -----------------
>
> So, to sum up, I propose reworking the 'clip-to-self',
> 'enable-background', and 'knock-out' properties into two more
> author-friendly properties:
>
> comp-clip-to: canvas | src | dst | intersection;
> comp-over: none | [group || [background | rect(x,y,w,h)]]
>
> 'comp-clip-to' limits the area that the compositing occurs within.
> I'm ambivalent on whether it affects all properties or just the
> handful that can't be easily done just by switching to a different
> comp-op.  The default is 'canvas'.
>
> 'comp-over' determines what you composite each element over when
> building a group.  'group' means to use the results of previous
> compositing within the group.  'background' means to use the nearest
> ancestor group's buffer; rect() is the same, but cuts out a specific
> rectangle of the nearest ancestor group's buffer to be used.    'none'
> just means to always run each compositing operation with a transparent
> black buffer, ignoring the ancestor buffers or previous elements in
> the group.  The default value is "group background".
>
> The 'comp-op' property in the draft seems fine.
>
> ~TJ
>