W3C home > Mailing lists > Public > www-svg@w3.org > April 2011

Re: Comments on SVG Compositing

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 6 Apr 2011 15:03:44 -0700
Message-ID: <BANLkTi=-R9p-UO0UCnT-YgrA5+OdAxPJuQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: www-svg <www-svg@w3.org>
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
- 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
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.

Received on Wednesday, 6 April 2011 22:04:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:47 UTC