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

[Robert O'Callahan]

On Tue, Jul 7, 2009 at 9:21 AM, <hansschmucker at gmail.com> wrote:

> On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker at gmail.com> wrote:
> > SVG Filters are a relatively easy spec, where the most important parts
> can be implemented in a matter of hours.
> On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
> > Speaking as an implementor of SVG filters, I don't believe you :-).
>
> I said most parts (by which I meant the actual image manipulations, which
> are defined pretty well in the SVG spec, not the surrounding issues of when
> to do drawing updates and so on that wouldn't apply to a Canvas anyway) :) .
> OK, I made it sound simpler than it is, but when you get right down to it,
> just the drawing code isn't terribly complicated.
>

Some of the filters aren't complicated, but some are. You're also talking
about duplicating the object model. And looking forward, if we do some
JIT-based or GPU-based filter acceleration, duplicating that work would
really suck. I would say the drawing code has to be shared even if the
object model is not.

On Jul 6, 2009 10:54pm, Robert O'Callahan <robert at ocallahan.org> wrote:
> > I agree that we need a convenient way to use filters with canvas. But I
> would rather not create an entirely new object model.
> > How about a drawImageWithFilter method that takes the same set of
> parameters as drawImage plus a reference to an SVG element? The image is
> used for Source/SourceAlpha and the size of the image establishes the object
> bounding box for filter and filter primitive units. Since drawImage can draw
> a canvas, this seems completely flexible.
>
> I'm fearing that the dependency on SVG would bring a lot of problems if a
> browser vendor wants to include just Canvas, like WebKit on the Palm Pre.
>

Webkit on iPhone and I think Android, and Fennec too, support SVG. If Palm
decides differently, that's their call and they can take the consequences. I
am deeply averse to duplicating functionality across specs "just in case"
someone implements one but not the other. It punishes authors and vendors of
full-function browsers.

Also, the SVG model is pretty complex when you include all the ways to
> cross-reference data. What would happen if a filter would want to load an
> image? Canvas can't work asyc, so either the whole call would fail or we'd
> lock up the browser for ages.
>

You'd just use whatever image you've got, just like SVG filter drawing does
normally. It's no different from doing drawImage with a partially loaded
image.


> Security issues would also increase tenfold as Canvas has a pretty simple
> security model. If we'd allow normal SVG filters, we'd probably need to flag
> the Canvas as "dirty", since SVG flters allow for loading of data from many
> sources, including what's currently on the screen.
>

You mean BackgroundImage? That makes no sense for canvas usage anyway, we'd
just ignore it. Foreign image usage would taint the canvas, that's easy to
do.

Including a dedicated filter API for Canvas would keep it simple and
> self-contained, allowing for much easier implementation, wouldn't it?
>

No, not really. Duplicating code is evil. Adding layers of abstraction so
that the same code can be used through different interfaces is less evil,
but it's still bad.

It would also give us a chance to strip out SVG stuff that doesn't make any
> sense for Canvas or is too complicated for too little benefit.
>

You see that as a chance. I see it as an opportunity for endless arguments.
And experience suggests that over time both sets of functionality will grow
to meet all users' requirements.

BTW with an HTML5 parser you can write <svg> content directly in HTML, which
makes it really easy to write an SVG filter to use with <canvas>.

One thing I would change is SVG filters should not clip to the filter region
or the filter primitive subregions. That's actually a change that should be
made to SVG (and I think the SVG WG is planning to make it), but for canvas
that should be the default.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090707/27e289a4/attachment-0001.htm>