Re: Fw: Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D Context

On Tue, 07 Jul 2009 01:55:33 +0200, Cameron McCormack <cam@mcc.id.au> wrote:

> In a thread about using SVG filters on <canvas> on the WHATWG list:
>
> ----- Forwarded message from Robert O'Callahan <robert@ocallahan.org> -----
>
> From: Robert O'Callahan <robert@ocallahan.org>
> Date: Tue, 7 Jul 2009 11:45:58 +1200
> To: Hans Schmucker <hansschmucker@gmail.com>
> Cc: whatwg@lists.whatwg.org
> Subject: Re: [whatwg] Adding SVG Filter-like functionality to Canvas 2D
>  Context
>
> …
>
> Hans Schmucker:
>> > But do you really want to explain to everybody who wants to use
>> > it that the colorspace is not normal RGBA32, but some strange....
>> > something?
>
> Robert O'Callahan:
>> I think we should change the SVG spec so that the default value of
>> color-interpolation-filters is sRGB.

That might be a bit of pain, but yes, it's indeed something implementations stumble on when implementing filters (Opera did, Inkscape too I think).

It'd be nice if we could avoid breaking content.

Also related mentioned in that thread on the whatwg list, adding a way of filtering <canvas> is something sketched in the filters module, however after having played with it for a bit I think the interface needs to be redefined slightly.

This is what's in the filter module at the moment:

interface SVGFilterElement {
   ImageData apply(in ImageData source);
}

That doesn't let you have multiple input images, and the result can be unnecessarily large e.g in the case of feOffset. At minimum we need to add an offset attribute to the returned object. Also it's not clear how filterUnits / primitiveUnits are resolved in this case, so additional parameter(s) for the boundingbox(es) might be needed.

Question is if it makes sense to list all of the input generators, like this for example:

   SVGFilterResult apply(in SVGFilterInputImageGenerator sourcegraphic [, in SVGFilterInputImageGenerator backgroundimage, in SVGFilterInputImageGenerator fillpaint, in SVGFilterInputImageGenerator strokepaint])

In my experience SourceGraphic/SourceAlpha are the most commonly used (external) filter inputs, so it might be ok to leave the others as optional. However it might be bad if we want to add other input images in the future. An option could be to define a configuration interface that you pass in.

Another thing to consider is whether reading out the resulting filter output is worthwhile in all cases. It can certainly be faster to not read it out (yes, I'm looking at you ImageData), but instead just allow it to be drawn somewhere without actually touching the contained data (this will be context-dependent).

interface SVGFilterResult {
   SVGRect getAffectedRect(); // or getOffset perhaps
   ImageDataOffset getImageData(x,y,w,h);
}

Possibly it's better to split it in two methods, one that returns data that you can play with, another that simply draws the result:

   void apply(<context-element>, in SVGFilterInputImageGenerator sourcegraphic [, in SVGFilterInputImageGenerator backgroundimage, in SVGFilterInputImageGenerator fillpaint, in SVGFilterInputImageGenerator strokepaint])
   SVGFilterResult apply(in SVGFilterInputImageGenerator sourcegraphic [, in SVGFilterInputImageGenerator backgroundimage, in SVGFilterInputImageGenerator fillpaint, in SVGFilterInputImageGenerator strokepaint])

The context-element interface would have to describe things like what it's boundingboxes for unit resolving are etc, and should allow other specs to extend this to give the appropriate context (might be an element, might be something else).

Cheers
/Erik

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

Received on Tuesday, 7 July 2009 08:54:14 UTC