Re: [css-compositing] group invariance

Thanks for your reply!
Comments inline


>
> --Original Message--:
> >All,
> >
> >we've been discussing my proposal internally. One of my coworkers brought
> up an issue with group invariance in my proposal and I wanted to see if
> people believe that this is an issue.
> >
> >One of the principles of the Adobe imaging model is that adding a default
> group should not change the appearance of the artwork. (Changing group's
> parameters to isolate:true or knockout: true will change appearance)
> >In SVG which uses the <g> operator for grouping, this is also the case.
> >
> >However, with my proposal, things will render differently.
>
> No, I believe these will both render the same and provide group-invariance.
>
> The issue I think you are having is imagining Porter-Duff as a node in a
> binary
> tree of objects. It isn't. It is a property of the object that takes effect
> when the object is rendered, not as a second-pass as is the case with
> filters.
>
> >For instance, this example:
> >
> ><circle>
> ><circle alpha-compositing='dst-in'>
> >will render differently from:
> >
> ><circle>
> >
> ><g>
> >
> >
> ><circle alpha-compositing='dst-in'>
> >
> >
> ></g>
>
> No they render identically.


> The <g> does not create a new backing store and so when the circle
> is rasterized onto the existing background (containing a circle) the
> Porter-Duff composition will happen between the pixels of the second
> and first circles using the alpha channel of the backing store. The <g>
> has no effect as it doesn't do anything.
>

>From the current SVG spec:
‘enable-background’: accumulate (= default)
A group image <http://www.w3.org/TR/SVGCompositing/#term-group_image> buffer
is established which is initialized with corresponding area of the current
canvas copied into it. Additionally, a group
alpha<http://www.w3.org/TR/SVGCompositing/#term-group_alpha> buffer
is established which is initialized to be opaque. The group
alpha<http://www.w3.org/TR/SVGCompositing/#term-group_alpha> is
used to store the percentage of background in the group
image<http://www.w3.org/TR/SVGCompositing/#term-group_image>.
All children of the current element shall be rendered into the group
image<http://www.w3.org/TR/SVGCompositing/#term-group_image>.
This is the lacuna
value<http://www.w3.org/TR/2008/REC-SVGTiny12-20081222/intro.html#TermLacunaValue>
.

According to this, <g> will create a temporary buffer.
If you follow the logic for enable-background: accumulate, you can tell
that it is trying to make sure that P-D is group invariant. However,
because the bounds of the group image buffer don't include the entire
background image, the result will differ.

This can be fixed, but it is expensive.


>
> >You can rewrite the second section as:
> >
> ><circle>
> >
> ><g alpha-compositing='src-over'> // src-over is the default
> >
> >
> >
> ><circle alpha-compositing='dst-in'>
> >
> >
> ></g>
> >
> >This code will do a 'dst-in' of the circle with an empty buffer. This
> empty buffer is then composited over the first circle.
>
> No again. There is no enable-background="new" that would create a backing
> store.
>

If you reread my proposal, alpha-compositing other than src-over would only
work within the same group. (Effectively implying enable-background="new").
I'm not covering the existing spec but the drawbacks of my proposal.


>
> >My question is:
> >a. Do people believe that group invariance is an important feature to
> have?
>
> It's a nice to have and I don't believe the P-D operators violate that
> anyway.
>

Given my example above and the current SVG spec, I believe they already
violate it.
I agree with you that group invariance is great but we need to consider the
cost of implementation and runtime performance.


>
> >b. If so, do you want to see this fixed in the first spec or can we
> address this in a later version?
>
> I think it's important to stop thinking about the filter model and P-D as
> being a post-processing
> step after an object is rasterized. The P-D operator determines the
> functions applied during
> rasterization and this was always the case (and reason it works better
> than filters).
>
> >Making alpha-compositing group invariant is quite complex. The math is
> comparable to how 'enable-background' works.
>
> Setting 'opacity' on the group will force a backing store to be generated,
> but there's
> no way to represent that with just the 2 circles anyway (e.g.
> fill-opacity/stroke-opacity bleed
> if you try to use those as an equivalent).
>

True. However, supporting group invariance for P-D would create many more
buffers and computations than just simple alpha. (just look at all the
logic for enable-background)


>
> The complexity arises if you try to put a P-D operator on the group itself
> without
> an enable-background set. That case was solved with the background removal
> maths in the spec. so is not an issue technically. Group invariance is
> preserved
> if you implement to the spec.
>
> Personally I think it'd be easier to just drop P-D for groups without
> enable-background
> set but that's just my opinion.
>

I agree. That is why I proposed that every p-d apart from src-over implies
a new background.

Rik