Appreciate your replies, I now have a much better sense of where GWT vector graphics is heading.
With my use of GWTCanvas, the fact that there was a per-pixel memory cost with the canvas tag (that does not exist with VML) forced me to do some extra work to "shrink-wrap" the canvas around each rendered curve. So, I can imagine how having everything sort of work like VML (element based rather than pixel based) could be a big consistency plus. I also found Ray's argument that many have tried to emulate canvas with VML and failed convincing. On the other hand: o The use of Flash would create a new proprietary dependency that does not exist with GWTCanvas at present. o Though my vector graphics needs were limited (I only required a canvas subset) I was able to do everything I wanted to using GWTCanvas (though working around the IE bugs was a pain). o Relative to other browsers, with the feature subset I used, IE's vector graphics rendering isn't nearly as slow as its HTML rendering. So, once I figured out I needed to minimize stroke count, I was happy with the IE rendering performance of GWTCanvas. >From the perspective of a black-box user of GWTCanvas, except for the IE bugs (which I was able to work around) it met my application's needs well. Without it GChart would still be stuck in the visual getto of HTML-only rendering. So I hope any improved system will preserve GWTCanvas' many good features, such as being packaged as a Widget, and having a reasonably low cost per widget (which made it possible for me to give each curve it's own GWTCanvas, and update them independently). My totally biased operational definition of if any new vector graphics library is 'good': when I implement GChartCanvasLite using the new library, my live demo and tests will 'just work', and run as fast or faster than with the GWTCanvas based implementation. On Jul 17, 7:33 am, Joel Webber <[email protected]> wrote: > 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... > > >> 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 -~----------~----~----~----~------~----~------~--~---
