Re: [css-compositing] group invariance

Sometime I wish there was a way to undo an email [?]
I was incorrect when I said the current spec is not group invariant.

So, if we follow the current specification, my 2 examples will look the
same.
With my simplified proposal, they will not.

So, how important is group invariance? Is it worth the implementation cost?

Rik

On Mon, Nov 21, 2011 at 8:45 PM, Rik Cabanier <cabanier@gmail.com> wrote:

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