On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker@gmail.com&gt;  wrote:<br />&gt; 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&#39;Callahan &lt;robert@ocallahan.org&gt; wrote:<br />&gt; Speaking as an implementor of SVG filters, I don&#39;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&#39;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&#39;t terribly complicated.<br /><br />On Tue, Jul 7, 2009 at 2:09 AM, hansschmucker@gmail.com&gt; wrote:<br />&gt; 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&#39;Callahan &lt;robert@ocallahan.org&gt; wrote:<br />&gt; 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 />&gt; 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&#39;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&#39;t work asyc, so either the whole call would fail or we&#39;d lock up the browser for ages. Security issues would also increase tenfold as Canvas has a pretty simple security model. If we&#39;d allow normal SVG filters, we&#39;d probably need to flag the Canvas as &quot;dirty&quot;, since SVG flters allow for loading of data from many sources, including what&#39;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&#39;t it?<br /><br />It would also give us a chance to strip out SVG stuff that doesn&#39;t make any sense for Canvas or is too complicated for too little benefit.