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 <[email protected]> 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 <[email protected] > > 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?id=293#c1 >> >> 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 <[email protected]> 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 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 -~----------~----~----~----~------~----~------~--~---
