Re: SVG Compositing

Hi Dirk,

Dirk Schulze wrote:
> 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.
> 

For the most part SVG is object based which works fine right up until you need 
to combine the rasters of the objects in a particular way whilst ensuring what 
has already been rendered has correctly been taken into account. You are right 
in that you could use a <compositing> object, the problem is all the results it 
produces would be incorrect.

The compositing specification is not about pushing objects through a processing 
chain like you would filters. The compositing specification is about how to 
combine an object at render time with what has already been rendered.

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

The problem is it is impossible to get the correct result if compositing works 
the same way as filters. If compositing did operate the same way as filters the 
background would be included twice in the operation which produces the wrong 
colour in the result. The reason for this is whatever had been rendered up to 
the compositing operation point would have to be placed into a new buffer the 
compositing steps would occur and then the image would be composited back with 
the original background. Hence, the background is included twice and there's 
been an additional composting step which can potentially effect the final result.

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

I have to admit the enable-background feature in compositing is tricky because 
of the way it operates. However, you can achieve some amazing results when it is 
used correctly. In terms of description of enable-background in the 
specification I plan to add some diagrams that illustrate its behaviour. This 
should hopefully make it a bit easier to understand and implement.

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

What Alex means is when filters operations occur they use a buffer that is 
rendered into in addition to rendering into the device canvas. This intermediate 
store has the final result before it is composited back to the canvas or 
alternatively is passed on to the next filter in the chain.

The compositing specification works directly on the device canvas. The only time 
a temporary buffer is created is when a group is encountered and 
enable-background='accumulate'. Even then the temporary buffer is just that 
because the operation is short and that case is not always encountered.

Hope this helps.

Cheers,

Anthony

> Dirk
> 
>

Received on Thursday, 15 April 2010 08:21:09 UTC