On Wed, Jul 29, 2009 at 10: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. > Ill dedicate this Friday to look over all the open GWTCanvas issues on the issue tracker and try to get them resolved in the incubator. -Jaime > > > 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 -~----------~----~----~----~------~----~------~--~---
