On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker@gmail.com>  wrote:<br />> SVG Filters are a relatively easy spec, where the most important parts can be implemented in a matter of hours.<br />On Jul 6, 2009 10:54pm, Robert O'Callahan <robert@ocallahan.org> wrote:<br />> Speaking as an implementor of SVG filters, I don't believe you :-).<br /><br />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.<br /><br />On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker@gmail.com> wrote:<br />> Am I the only one seeing any benefit for this or does anybody else think that would be hope for such a proposal?<br />On Jul 6, 2009 10:54pm, Robert O'Callahan <robert@ocallahan.org> wrote:<br />> I agree that we need a convenient way to use filters with canvas. But I would rather not create an entirely new object model.<br />> 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.<br /><br />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.<br /><br />Including a dedicated filter API for Canvas would keep it simple and self-contained, allowing for much easier implementation, wouldn't it?<br /><br />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.