Re: [css-compositing] some proposals

Hi Rik,

--Original Message--:
>All,
>
>I have some proposals for the SVG compositing spec: http://www.w3.org/TR/SVGCompositing/.
>We can have a conversation on each item and if there is a general consensus, I will start to update the compositing spec.
>
>a. split up the spec in 2 sections: Porter-Duff & Blending. 

Agreed, it separates the two concepts properly.

>Porter-Duff are compositing primitives that describes how 2 images (src+dst) can be merged.

Here, I'd agree with David Baron's comment and change the names to 'source' and 'dest' in
line with CSS spec. readability.

>Blending describes how the top image will 'blend' with its underlying colors. The result of this is a new blended image. So far, we assume that after blending, this image is composited with Porter-Duff src-over.

No it doesn't.

Blending describes how the colour channels mix. It is independent of the P-D operators.
The diagram in the existing spec. attempts to describe that. i.e. the one that has a square
with 4 sections - one multi-coloured, one blue, one yellow and one white.

Blending applies only to the multi-colour area whilst P-D manages how the different
'regions' combine. There is no reason that a blending mode can't apply to a different
P-D operator.

>I am tempted to split the spec, but keep the comp-op keyword the same for both PD and blending.

I think this is a mistake. We should split them.

For example, I have two circles as part of a Venn diagram and I want to apply a blend
to their intersection - I can P-D 'src-in' the objects and apply comp-op="overlay" or similar.
The result of that is an area which has the 'overlay' applied to just the intersection of
the objects.

I can't remember if 'Shake' was able to do that, but it did handle P-D and blending IIRC.

>This does imply that you won't be able to do xor or src-in with blended content. Does anyone believe that this is a use case?

Yes it's a use case. I think you'll find that sort of thing used in high-end video editing etc,

>b. simplify Porter-Duff
>- remove the clip-to-self property. The default behavior becomes 'clip-to-self: object'. Does anyone believe that 'clip-to-self: canvas' is useful? It feels strange to have that option in SVG.

I don't have a strong opinion on this one - the original P-D paper from 1984 applied to the canvas
whilst Java2D was effectively 'object'. Android supports P-D that I think can apply to the
canvas but I'd need to check.

Possibly the best way forward is to get rid of the property, limit it to 'object' and if future need
for the entire canvas happens we can re-add it in a future revision of the spec.

I think authors right now would find the blend modes most useful and P-D less interesting in
the short term (until authoring tools catch up).

>- 'enable-background' does not apply. Children with blending will composite up to the group with PD blending. (In effect, PD will always imply 'enable-background: new')

Oh no. PD doesn't ever imply 'enable-background:new' - that's confusing it with filters again.
P-D is a logical operation on objects not a bitblt operation into a backing store (even though
many implementations choose to implement it in a similar way).

If you 'in' two objects you can do it by generating the intersection geometry and filling it or
any other means you like. It's entirely possible with a pixel sequential renderer to rasterize
the 2 objects at the same time and emit only the intersection, etc. So there is no implied
intermediate bitmap to get created.

The effect may be the same as if 'enable-background:new' were set, but it's important to
make sure people don''t expect that bitmaps will be created, memory wasted and the
associated slowdowns of bitblts, etc. will happen. If you're P-D combining a group
then you probably need an intermediate bitmap but the whole background removal
part of the compositing spec. was aimed to handle both settings of enable-background.

The wording about enable-background was trying to nail down two different descriptions
that were in an older SVG spec. draft into one that people could understand better
but it looks like it's missed the mark.

>- 'knock-out' on the nearest ancestor with blending does not apply. If it has 'knock-out: preserve', the group with the PD compositing operator will still knock out.
>- Simon Fraser expressed concern that this compositing operator required access to the entire background image. Maybe we should specify that all PD blending should be done inside a group that has 'enable-background: new'.

My preference at this time would be to remove knock-out as well as clip-to-self.

>c. complete blend modes
>- add the following missing blend modes: hue, saturation, color & luminosity

Yes, totally agree.

>- specify that the result of blending is always composited using src-over

No, for reasons specified above. Default of 'src-over' is OK.

>- potentially: change the default of enable-background to 'new' if you specify a blend mode so a new stacking context is established. Most people want a new stacking context and it also makes it easier and less memory intensive to process for a SVG processor.

No. There's nothing different between a normal rasterization with alpha and a blend mode. The blend-mode
is just a property of the object, like colour.

The blend-modes I implemented that can do it over live video do nothing other than apply a colour
function at the rasterization stage of a polygon, just like you have to handle source and destination
alpha. There is no memory penalty and is one of the main advatnages over filters using blend modes.

>d. Add a new blend mode: 'normal'

Adding 'normal' makes sense.

>- this is the default blend mode on all groups and leafs.

Yes.

>- similar to PD's src-over except it doesn't create a new stacking context
>- 'enable-background' and 'knock-out' apply

No need for enable-background again...

>e. update knockout
>- change the value back to a boolean value from 'replace'/'preserve'. The new value is confusing.
>- provide a better description + correct the compositing formula

We don't do boolean in W3C specs, so pick more descriptive names if anything.
The description and formula do need rework indeed.

>f. update enable-background
>- remove the ability to set up x, y, width & height. I believe there's already consensus on this.
>- clarify the description and refer to the filters spec which already defines this parameter
>- maybe replace the keyword with 'isolate' which is Adobe's equivalent. 'isolate: true' = 'enable-background: new'. I think this is a little easier to grasp and it is also familiar to designers.

We really wanted 'isolate' earlier in the SVG spec development. I think the horse has
bolted but if there's any way to align the enable-background model with isolate groups
I'd be eager to hear it.

>Let me know of any concerns.

I think we may be biting off more than we can handle in a reasonable period of time
with all these changes. The only stable part of the spec. at the moment is the blend
modes and I think most developers are comfortable with them. They also have
the added bonus that they're implemented in PDF, CoreGraphics, etc. etc. so there
is basically no implementation burden for a browser to add them quickly.

So my gut feel would be to split the blend-modes from P-D/clip-to-self/enable-background/
knock-out, push it forward to CR. Drop everything apart from blend modes when nobody
bothers to implement the remainder and quickly restart an effort to clean up the
P-D/knock-out stuff etc.

If we try to cram it all in, I think the spec. will stagnate. The blend-modes are
already generated by Illustrator, etc. and designers know how to use them.

Alex

>Rik
>
>
>

Received on Wednesday, 9 November 2011 00:44:15 UTC