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). 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. On Jul 29, 1:47 pm, Daniel Rice (דניאל רייס) <r...@google.com> wrote: > Hi Ray - > You can take a look at my work-in-progress > athttps://mondrian.corp.google.com/changelist/10864395. It's a retained-mode > API that translates into SVG or VML depending on browser > type. Retained-mode drawing uses a Graphics interface: > public interface Graphics { > ShapeElement circle(double cx, double cy, double r); > ShapeElement ellipse(double cx, double cy, double rx, double ry); > ShapeElement line(double x0, double y0, double x1, double y1); > ShapeElement rect(double x, double y, double width, double height); > ShapeElement roundRect(double x, double y, double width, double height, > double rx, double ry); > > GroupElement beginGroup(); > void endGroup(); > > ShapeElement beginPath(); > void endPath(boolean close); > > void moveTo(double x, double y); > void lineTo(double x, double y); > void quadTo(double x0, double y0, double x, double y); > void cubicTo(double x0, double y0, double x1, double y1, double x, double > y); > void arcTo(double rx, double ry, double phi, boolean largeArcFlag, > boolean sweepFlag, double x, double y); > > } > > A ShapeElement can have a Paint object applied to it that defines stroke > and fill parameters. A GroupElement can have a Transform object applied > (while SVG allows Transforms at every level, VML applies them at the group > level only). Either type of element can have normal event listeners applied > to it. > > I'd be very interested in your feedback on the API. > > Dan > > On Wed, Jul 29, 2009 at 12:22 PM, Ray Cromwell <cromwell...@gmail.com>wrote: > > > > > On Wed, Jul 29, 2009 at 8:57 AM, Joel Webber <j...@google.com> wrote: > > >> Is VML performance really that bad? I'm quite sure you've done a lot more > >> testing than I have :) My understanding has always been that it sucked > >> miserably for implementing a direct-mode API like Canvas, largely because > >> of > >> the obvious and inherent abstraction-inversion problems. But if you're > >> implementing a retained-mode SVG-like API, I thought it's performance was > >> fairly reasonable. But that's largely assumption on my part, and could well > >> be wrong. > > > I think it is reasonable for applications for which retained-mode SVG is > > ideally suited: apps where not much graphically changes on each update and > > for which hit-detection/clicking/picking is important. That is, if you're > > doing Visio in the browser, it'll probably work. Personally, and this is > > just my perspective, the immediate-mode API brings with it implications of > > performance and application type. After all, if I'm going to go through all > > the trouble of maintaining draw order, rendering loops, and hit-detection > > manually, I'm either a glutton for punishment, or there's an expectation > > it's going to be faster. > > > I've long through we should have the equivalent of O3D for 2D in GWT, an > > "O2D" API, whereby, one constructs a scenegraph, can tag bits for > > immutability, and then ask the API to render it, which could pick SVG or > > Canvas depending on object types. > > > That is, I think GWTCanvas is the wrong abstraction to encourage people to > > develop the kinds of apps that VML or SVG is good at. They should be writing > > code this like: > > > scene.beginUpdate(); > > Circle c=new Circle(radius); > > c.setStyle(styleObject); > > c.addClickHandler(...); > > scene.add(c); > > > Stroke s = new Stroke(); > > s.addPoint(x,y); > > s.curveTo(x2,y2); > > scene.add(s); > > > scene.doneUpdate(); > > >> Brad's stuff looks great, and I really like the idea of using Flash's > >> renderer, which does indeed not suck. My biggest concern, however, is that > >> any interaction with the SVG DOM could be abysmally slow, as it would > >> appear > >> that it has to go back and forth between js and flash, which is really, > >> really slow. Thoughts? > > > I've heard it's gotten faster in later HTML5 browsers, but it's probably > > very slow between Flash/IE6. The issue with IE6 isn't just VML, it's also > > the performance of JS for updating lots of stuff at a decent Hz. In > > Chronoscope, if I substitute a NullCanvas (no drawing actually done), > > performance is still sub-par. The interesting thing about SVG Web IMHO > > isn't its performance for real time updates of lots of draw changes, it's > > that it has far more capability than VML emulation layers. In other words, > > VML is a subset of Canvas, but SVGWeb is actually a super-set and can do > > stuff that canvas can't. > > > -Ray > > >> On Wed, Jul 29, 2009 at 11:43 AM, Ray Cromwell > >> <cromwell...@gmail.com>wrote: > > >>> Another crazy possibility is to use Brad Neuberg's SVGWeb ( > >>>http://code.google.com/p/svgweb/). He's implemented almost 100% of SVG > >>> and SMIL in Flash plus a JS wrapper, so as to enable HTML5 features in > >>> IE6. > >>> I have to say that the demos are very impressive. > >>> IMHO, IE6+VML is a lost cause for all but the most simple of graphical > >>> apps. The performance of the JS as well as VML is so gimped, that even if > >>> you get stuff working and looking the same, it'll likely be disappointing > >>> from a UI latency perspective. It's like writing a video game that has to > >>> simultaneously run on a 4-core 3Ghz x86 with latest GPU, and a Pentium3 > >>> system with VGA graphics. You either have to provide two rendering loops, > >>> one with the amount of stuff cut way way back, or make the lesser system > >>> unplayable. > > >>> On Wed, Jul 29, 2009 at 7:52 AM, Joel Webber <j...@google.com> wrote: > > >>>> I agree that it's probably best to go ahead and fix the bugs in > >>>> GWTCanvas that are likely to show up in any SVG/VML translation. And > >>>> while I > >>>> don't think anyone's actually worked out the performance of excanvas.js > >>>> vs > >>>> GWTCanvas, but I'm more concerned with getting a respectable SVG/VML > >>>> layer > >>>> implemented than with trying to chase the fool's errand of building the > >>>> Canvas API on top of VML, where there will always be cases that perform > >>>> horribly. > >>>> @Jaime, Dan: What do you guys think? I know the ball's still in my court > >>>> to help get Dan's work reviewed and ready for public consumption, but in > >>>> the > >>>> meantime taking fixes for GWTCanvas seems sensible. > > >>>> On Wed, Jul 29, 2009 at 2:05 AM, John Gunther < > >>>> johncurtisgunt...@yahoo.com> wrote: > > >>>>> I added a patch to fix the GWTCanvas bug that caused me the most > >>>>> grief: > > >>>>>http://code.google.com/p/google-web-toolkit-incubator/issues/detail?i... > > >>>>> Turned out, this problem was a basic one with IE's VML support: right > >>>>> after you apply DOM.removeChild to remove a child that contains VML, > >>>>> the fill and stroke colors, as well as the stroke widths that you so > >>>>> laboriously constructed during various strokes and fills, are all > >>>>> simply dropped by IE, as I confirmed by inspecting the inner HTML > >>>>> before and after the removeChild call within Widget.removeFromParent. > > >>>>> Do you think it is worthwhile to fix the remaining GWTCanvas bugs? My > >>>>> thinking is that it is on two levels: 1) because GWTCanvas is > >>>>> available now and 2) because any more advanced SVG + VML system will > >>>>> still have to fix such (mostly low-level VML-related stuff, is my > >>>>> guess) bugs, so these fixes should be useful in the new system, too. > > >>>>> Couple of questions/observations obliquely related to this patch: > > >>>>> o If it's just VML, features dropping out, fixing this within just GWT > >>>>> vector graphics Widgets makes sense. But what if IE drops non-VML > >>>>> stuff in removeChild? Just a thought: might be a good test case to > >>>>> check the innerHTML before and after removeChild with some omnibus > >>>>> HTML to assure IE doesn't drop any other important stuff off. The > >>>>> experience of seeing features respectably documented in the VML API > >>>>> (http://www.w3.org/TR/NOTE-VML) just dropping out more or less at > >>>>> random inspires paranoia. > > >>>>> o Has anyone compared GWTCanvas, performance-wise, to excanvas.js? > >>>>> Better: line-for-line translation of excanvas.js to Java, gwt-compile, > >>>>> does it yield any performance boost? How much? A lot of Javascript > >>>>> gurus known excanvas.js so could be an interesting kind of benchmark. > > >>>>> On Jul 19, 12:41 am, John Gunther <johncurtisgunt...@yahoo.com> wrote: > >>>>> > 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 > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
