- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 28 Jan 2011 14:58:44 +0100
- To: public-fx@w3.org
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