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

[hansschmucker at gmail.com]

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.

On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker at gmail.com> wrote:
> Am I the only one seeing any benefit for this or does anybody else think  
> that would be hope for such a proposal?
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.  
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. 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. Or we forbid only dangerous elements, but that would mean that  
Canvas filters would look like SVG filters, but really function differently.

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/f7789cd6/attachment-0002.htm>