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!

----------------


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?  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 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.  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.

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.


-----------------

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

Received on Friday, 8 April 2011 20:13:09 UTC