Re: SVGFilter and ImageData

On Wed, 12 Jan 2011 21:24:37 +0100, Dirk Schulze <vbs85@gmx.de> wrote:

> I have a lot more questions to the editors draft of SVGFilters 1.2[1], I  
> hope we can discuss this in parallel :-)
>
> The interface of SVGFilterElement takes ImageData with apply(in  
> ImageData source). Is this meant to be the SourceGraphic?

Yes. However, what's currently there isn't ideal and won't really work  
fully unless further specified. If a full model is desired where ImageData  
objects can be mapped to BackgroundImage and all other filter image inputs  
then the API needs to be redesigned. A filter input generator abstraction  
might help there (not all cases need all types of filter inputs), if one  
wishes to generate the ImageData on-the-fly as needed. An output rectangle  
might also be good thing to add, if the result is smaller than the input.

> And the result is written to the same ImageData object?

The original intent was to allocate and return a new ImageData object I  
think. Writing the result to the same object would probably be more useful  
though, and if that's done there needs to be a way to pass in a rectangle  
definining the area to filter.

> ImageData doesn't have information about the position of the source, so  
> how should it be positioned into the filter area (especially on using  
> the filter elements attributes x and y)?

Originally the thought was to make the input ImageData define the region  
through it's dimensions, and with x,y=0.

> Are x,y,width,height of the filter element relative to the size of the  
> ImageData (if relative values are choosen)?

Originally that was the intent yes, that it would allocate an output  
ImageData of the dimensions required by the filter region  
(x,y,width,height).

> What if the result is bigger or smaller than the ImageData size?

Both cases would really need to have a destination (output) rectangle  
returned. As you note, it's not defined at the moment.

> What if the result has an offset (maybe because of the offset by  
> feOffset)?

See above.

> What about the pseudo primitives BackgroundImage, StrokePaint and  
> FillPaint? We don't have information about this on calling SVGFilter via  
> JavaScript.

See above, a callback API (filter input generator) could potentially solve  
that.

> Also, do we need the SVG filter element for this? I could imagine that  
> this is used for HTML Canvas, so maybe we can find a way to use the same  
> filters with the same syntax like on CSS for Canvas?

I think that would be nice, though it might be better to provide a syntax  
more similar to how shadows are implemented in canvas?

Cheers
/Erik

[1] http://dev.w3.org/Graphics-FX/modules/filters/publish/SVGFilter.html


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Friday, 28 January 2011 13:59:19 UTC