Re: SVG Compositing

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.

> 
>  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 Wednesday, 14 April 2010 16:55:21 UTC