On Wed, Jul 29, 2009 at 9:34 AM, Joel Webber <[email protected]> wrote: > > > As for "O2D", isn't that more or less what you get with the SVG/VML DOM > structures? Ugliness of XML aside, the Javascript *does* mostly get out of > the way of the renderer once your scene graph's constructed -- you just run > code to bump values on those nodes you need to animate or update. >
Somewhat, but I was thinking about more than a straightforward serialization and mapping approach, since once you have a retained mode structure, there are optimizations you can perform on it. There's also the HTML5 functionality where people mix <video>, <svg>, and <canvas> together. So it might not be unreasonable to take these future capabilities into consideration when designing a retained mode system, instead of just mapping the LCD of SVG and VML elements. People who work with graphics are used to having multiple render paths and fallbacks, so it's not unreasonable to provide a rich API with capability detection, and allow people to exercise HTML5 features when available, but provide basic VML functionality when not. Think of it as progressive enhancement for rendering. -Ray > > > On Wed, Jul 29, 2009 at 12:22 PM, Ray Cromwell <[email protected]>wrote: > >> >> >> On Wed, Jul 29, 2009 at 8:57 AM, Joel Webber <[email protected]> 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 <[email protected]>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 <[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 -~----------~----~----~----~------~----~------~--~---
