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

[Robert O'Callahan]

On Tue, Jul 7, 2009 at 10:52 AM, Hans Schmucker <hansschmucker at gmail.com>wrote:

> It may just be me, but I think that the success of Canvas, which is
> way ahead of HTML5 in general, is largely due to the fact that it's
> pretty much standalone. You don't have to read through hundreds of
> pages of other documentation, you just read the Canvas spec and that's
> pretty much it. Same for parties who want to implement it, there's
> virtually no big dependency.


That's not going to change, unless you want this relatively narrow extra
functionality. For those who do, someone can write an SVG-filters-for-canvas
tutorial that can ignore most of the SVG spec.

If we duplicate the feature, then someone who's already familiar with SVG or
canvas filters and wants to use the other will need to read twice as much
documentation, and try to keep two separate syntaxes for the same feature
straight in their head. I think you know that in Firefox we support SVG
filters for HTML content, and it's very useful, so it's quite likely that
advanced Web authors will be learning about SVG filters independent of
canvas.

Of course, how you actually implement it (i.e. by sharing code with
> the SVG filters) is not even something a spec is supposed to dictate,
> you can share as much code as you want as long as the result is what
> the spec says.


Yes, but the specs can make code sharing painful or even infeasible if they
diverge, even accidentally.

On Tue, Jul 7, 2009 at 12:15 AM, Robert O'Callahan<robert at ocallahan.org>
> wrote:
> > On Tue, Jul 7, 2009 at 9:21 AM, <hansschmucker at gmail.com> wrote:
> >> 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.
> Is this really useful for Canvas? Partial results are fine when all
> you do is filter, but if the filter is part of a larger drawing
> routine, then the result could be pretty undesirable. And since
> there's no direct way to check for the status of the resource, all the
> Canvas user could do would be trying again and again until it works
> should we decide that methods should throw an error if a resource
> isn't loaded yet.


In Gecko at least, the feImage element fires 'load' and 'error' events like
other image elements, and also blocks the document load event while it's
loading, so waiting for it to fully load is easy.

Nope, I meant the filter loading an SVG, loading a HTML via
> foreignElement, loading another SVG via iframe, loading an image from
> another server. BackgroundImage is of no use for Canvas anyway.


We already have to solve that problem when we support SVG images with
drawImage, which is already in the spec (implicitly).

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?


I think we should change the SVG spec so that the default value of
color-interpolation-filters is sRGB.


> That the applied rectangle is actually 1.2x the given size
> in any dimension?


As I said in my previous email, the SVG working group is already receptive
to the idea of changing SVG filters so we don't clip to the filter region,
in which case the filter region (and its -10%,-10%,120%,120% default) can be
ignored in most cases.

There is simply a lot of stuff in SVG that's meant
> for graphics artists, not programmers. The usage would be different in
> Canvas from what it is in SVG.


There's a lot of stuff in SVG that's meant for programmers too. Some of it's
just not very well done, and will have to be fixed. I think it's pretty
clear programmers are a more suitable audience for SVG filters than graphic
artists...

> 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>.
> And suddenly we have another dependency :)


Not a dependency, just a convenience.


> But seriously: What good is
> a filter that is supplied somewhere in the document body to a dynamic
> graphic. Why would I want to meddle with the DOM, when really all I
> want to set is a local property?


In many cases it's easier to write markup and refer to it than to write
code. The goal here is to support declarative filters, after all.

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/560bd7e4/attachment.htm>