Ray's basically right about this -- you can't simulate canvas on vml (extant attempts to do so with limited success notwithstanding). When GWTCanvas was originally designed, SVG performance on some browsers was absolutely atrocious, while Canvas and VML were basically acceptable. So Jaime and I attempted to design an API that would use Canvas and VML for a rendering layer, while trying to nudge the developer towards a use pattern that would work well in practice.
Since then, the situation has changed quite a lot. SVG performance on Gecko, WebKit, and Opera has finally gotten up to speed, making it possible (or at least a *lot* easier) to build a sensible scene-graph API that uses just VML and SVG. I strongly believe this will end up being a better API, because the rendering back-ends will be (more or less) equally capable and similarly constructed. Dan Rice (cc'd) has started working on this approach, but it may be a little while before it sees the light of day. In the meantime, if you have patches for any of the issues you listed in GWTCanvas, don't hesitate to let us know. Cheers, joel. On Fri, Jul 17, 2009 at 12:04 AM, Ray Cromwell <[email protected]>wrote: > > The only realistic way to truly emulate canvas on IE is to use Flash. VML > just doesn't cut it. Even after lots of community effort on excanvas.js, it > still falls short of even the old Canvas that Safari first exported, and > that doesn't even take into account that performance is pretty bad too. > Silverlight could be a deferred binding option as well, but Flash has >95% > penetration and would work in a majority of cases. You could still fallback > to VML in some of those intranet settings that don't allow plugins, but as > you say, you'd have to bifurifcate the Canvas API into what's supportable by > VML and what's supportable by everything else, and code your draw paths to > deal with them separately. > Even with Flash, there's some stuff like fetching or setting pixel data > that would be quite slow, in that regard, I think image processing ops > should be encoded declaratively in a scenegraph, much like Java2D/JAI > Renderable, and shipped over to Flash for execution rather than trying to > bring them into the browser's JS engine. > > -Ray > > > On Thu, Jul 16, 2009 at 8:36 PM, John Gunther <[email protected] > > wrote: > >> >> There are a number of GWTCanvas bug reports that are still categorized >> as New, some several months old, some submitted by me. >> >> >> http://code.google.com/p/google-web-toolkit-incubator/issues/list?can=2&q=GWTCanvas&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary&cells=tiles >> >> Has anyone looked at these yet? Anyone have plans to fix any of them >> (or are there any fixes that have not yet been committed yet?) >> >> I've also noticed a project called gwt-canvas (http://code.google.com/ >> p/gwt-canvas/ <http://code.google.com/%0Ap/gwt-canvas/>) Are the two >> projects related in any way (they list a >> "gwt.team.jaimeyap" as a contributor, though not [email protected]. >> Presume they are the same person, right)? >> >> I was thinking of trying to better understand and maybe even fix some >> of the bugs I reported but wanted to make sure I was not missing >> anything first. Thanks for any info you can provide. >> >> >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
