Re: SVG Compositing

Hi Dirk,

--Original Message--:
>Hi Alex,
>
>> 
>> 	There are very good reasons why it is defined the
>> way it is.
>>  Many more than I can put into an email.
>> 
>> 	Basically the compositing operator is a property
>> of an object, not 'glue' to join 2 objects together. We
>> implemented it as you suggest back around 2003 or so and
>> it doesn't work for the Porter-Duff operators proerly
>> especially when combined with background-enable='accumulate'.
>
>In my opion SVG is object based. Thats why we have DOM, SVGDOM as well
>as µDOM. And I don't see a problem in putting the background in another
>groupe and composite it with your object. In general everything should
>be possible with compositing object, what the current Specification
>wants to do.

We discussed this for a numnber of years in the WG and I do welcome your
raising the same sort of questions as were raised at the time and discussed
at length.

However - the compositing operator is like anything to do with compositing
such as opacity. It defines the way the current object mixes with the
existing background.

Would you define an <opacity> element that specifies it's inputs and
outputs? I doubt it.

Color is the same too.

The specification as defined is consistent with the graphics model of PDF as
wel as the compositing blend mode operators in Quartz2D.

This is why it is the way it is. There is no need for additional objects
to confuse things. I've implemented this three times over the years -
once with the node-style model you've proposed and we had to tear
that one up as it _didn't_ work for nested cases.

I have shown the existing compositing operators being applied
to live video in public and IMHO to add extra complexity to the model
will simply degrade rendering speed and consequently frame
rate.

Alex

>> 
>> 	Anthony may want to make some more comments.  But the
>> basic one is that it doesn't work properly if you try to represent
>> compositing as nodes in the tree - which is effectively what
>> you suggest.
>
>What is not possible?
>
>At the end we should also think about a big pro of SVG. The
>accessibility. It's muchh more difficult to discribe the current drawing
>if you use enable-background and composite it some times later. The
>current action should be discribed easily, readable and understandable.
>
>> 
>> 	Adobe's ASV3 has compositing as a property on objects,
>> via the adobe-blending-mode property. Illustrator will geberate
>> that rather than use filters. Compositing can be achieved without
>> using an intermediate store which I don't think you can expect
>> when using a filter primitive.
>
>Well, I realy doubt that we won't need intermediate buffers. The most
>graphic librarys (Qt, Cairo, Skia, Cg) don't provide some compositing
>effects mentioned in the Spec. So many viewers have to store the drawing
>and need to work with pixel manipulations, like the most platforms
>already do for filters.
>
>Dirk
>
>
>

Received on Thursday, 15 April 2010 05:25:49 UTC