On Tue, Jul 7, 2009 at 9:21 AM,  <span dir="ltr"><<a href="mailto:hansschmucker@gmail.com">hansschmucker@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tue, Jul 7, 2009 at 2:09 AM, <a href="mailto:hansschmucker@gmail.com" target="_blank">hansschmucker@gmail.com</a>>  wrote:<br></div><div class="im">> SVG Filters are a relatively easy spec, where the most important parts can be implemented in a matter of hours.<br>
</div><div class="im">On Jul 6, 2009 10:54pm, Robert O'Callahan <<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>> 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.</div>
</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Jul 6, 2009 10:54pm, Robert O'Callahan <<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>> wrote:<br>
<div><div class="h5">> 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.</div></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">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.</div>
</div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="h5">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.</div>
</div></blockquote><div><br>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.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div class="h5">Including a dedicated filter API for Canvas would keep it simple and self-contained, allowing for much easier implementation, wouldn't it?</div></div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">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.</div>
</div></blockquote></div><br>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.<br>
<br>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>.<br><br>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.<br>
<br clear="all">Rob<br>-- <br>"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]<br>