On Mon, Aug 3, 2009 at 12:41 PM, John Gunther <[email protected]>wrote:
> > With the advantage of having read GWTCanvas, excanvas.js, and this > discussion, I got an interesting insight about how I actually ended up > using GWTCanvas in Client-side GChart. > > It turns out, much to my surprise, that each of the GWCanvas Widgets > used to render my charts could have been realized via a single VML > shape. > > "Could have" because, due to the fact that GWTCanvas puts out a > separate shape for each fill or stroke method invocation (instead of > just adding an extra fill or stroke sub-element) in fact more often > than not each GWTCanvas used by my application contains exactly two > shapes. > > I reached this particular rendering pattern randomly, through a series > of performance tweaks that began with a single GWTCanvas that was very > slow in IE because it was jam-packed VML shapes, all of which needed > to be completely regenerated whenever any part of the chart changed. > > Ironically, then, a GWTCanvas used and implemented with optimal > efficiency does not emulate a canvas element via a series of VML > shapes, but instead emulates each VML shape with a single canvas > element. > > That statement might not be true for every GWTCanvas application but > it certainly turned out to be true for mine (I was using ShapeElements > before I realized I was using ShapeElements. Minus times minus equals > plus). > > Thus, I'm now reasonably confident the new shape-focused approach will > be of material benefit to my application: it should allow me to cut > the VML shape element count in my chart renderings by a factor of two > (providing, I hope, a big performance boost just where it is most > needed, in IE) simply by executing an in principle simple (though in > fact probably very tedious) "replace each GWTCanvas with a single > ShapeElement" code transformation. > > One remaining concern: if emulating a shape via canvas performed > significantly better than using SVG, my application could take a > performance hit on non-IE. I know nothing about SVG, but I mention > this possibility only because GWTCanvas performance in non-IE has been > so fast it's hard for me to imagine it getting anything but worse. As > long as amortized over all clients the question 'are you faster with > ShapeElements than with GWTCanvases?' is answered in the affirmative > my application won't suffer (all performance complaints from users > I've received have been IE-related). > I'm now pretty much certain (though it is still worth measuring this assumption) that SVG performs just as well as Canvas for this kind of structure (and therefore using Canvas in the way that GWTCanvas does will likely always be slower). When Jaime and I first started talking about GWTCanvas, this was not the case at all (Firefox's SVG implementation, for example, was abysmally and inexplicably slow). So I agree 100% that moving to a retained-mode API will give us the best results. Your experience provides pretty strong evidence for this statement. In light of the above, I no longer believe fixing the bugs in > GWTCanvas is a reasonable thing to do. There's a better approach: > release a cross browser shape capability ASAP, and encourage existing > GWTCanvas users to convert to use ShapeElements. To avoid losing the > low-level VML knowledge represented by the GWTCanvas bug reports, > tests to reproduce the same symptoms could be added to the new system > when appropriate. > > In the above I'm assuming (with no knowlege of the new system's code) > that at least a limited but still useful feature subset of the shape- > based system (it would not even have to have all of GWTCanvas' current > capabilities to be immediately usable in Client-side GChart, for > example, which only uses a 'GChartCanvasLite' GWTCanvas feature > subset) could be released reasonably soon. > > Overall, I think I now finally get it and am very much looking forward > to trying out and maybe even submitting a patch or two to the new > shape-based GWT graphics API. Appreciate your efforts. > > @Daniel Rice: could not follow the link but your summary told me all I > need to know re: where GWT vector graphics API is headed; LGTM. > Sounds good to me as well. As soon as we get past some of our 2.0 crunch mode tasks, we should revisit getting this code out there for you (and everyone else) to start banging on. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
