[gwt-contrib] Re: GWTCanvas status?
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
[gwt-contrib] Re: GWTCanvas status?
On Mon, Aug 3, 2009 at 12:41 PM, John Gunther johncurtisgunt...@yahoo.comwrote: 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWTCanvas status?
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?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 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 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
[gwt-contrib] Re: GWTCanvas status?
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. 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? On Wed, Jul 29, 2009 at 11:43 AM, Ray Cromwell cromwell...@gmail.comwrote: 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?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 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
[gwt-contrib] Re: GWTCanvas status?
On Wed, Jul 29, 2009 at 10: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. 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 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?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 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 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 j...@google.com 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
[gwt-contrib] Re: GWTCanvas status?
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.comwrote: 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?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
[gwt-contrib] Re: GWTCanvas status?
Oh, I think we're in complete agreement that GWTCanvas is the wrong abstraction for SVG/VML -- which is why I cc'd Dan, who's been working on a replacement that presents a sensible retained-mode API (to be fair, when Jaime first wrote GWTCanvas, SVG performance was *abysmal* on most browsers, and we were trying to find a middle-ground between VML and Canvas; upon reflection, I'm not sure that this was even a reasonable goal). 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. I would also kill to have an implementation of an immediate mode API that actually worked worth a damn on IE. I couldn't agree more that there are cases (like Chronoscope and most games) where you're *much* better off with something like Canvas. I just don't know how to get there sensibly on IE without some really nasty tradeoffs (like the Flash bridge overhead). Ideas on this front are also very much welcome! On Wed, Jul 29, 2009 at 12:22 PM, Ray Cromwell cromwell...@gmail.comwrote: 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.comwrote: 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
[gwt-contrib] Re: GWTCanvas status?
On Wed, Jul 29, 2009 at 9:34 AM, Joel Webber j...@google.com 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 cromwell...@gmail.comwrote: 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.comwrote: 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
[gwt-contrib] Re: GWTCanvas status?
Hi Ray -
You can take a look at my work-in-progress at
https://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.comwrote:
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.comwrote:
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
[gwt-contrib] Re: GWTCanvas status?
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 j...@google.com 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 cromwell...@gmail.comwrote: 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 johncurtisgunt...@yahoo.com 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 jaime...@google.com. Presume they are the same person, right)? I was thinking of trying to better understand and maybe even fix
[gwt-contrib] Re: GWTCanvas status?
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 cromwell...@gmail.comwrote: 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 johncurtisgunt...@yahoo.com 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=2q=GWTCanvascolspec=ID+Type+Status+Priority+Milestone+Owner+Summarycells=tiles 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 jaime...@google.com. 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWTCanvas status?
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 johncurtisgunt...@yahoo.comwrote: 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=2q=GWTCanvascolspec=ID+Type+Status+Priority+Milestone+Owner+Summarycells=tiles 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/) Are the two projects related in any way (they list a gwt.team.jaimeyap as a contributor, though not jaime...@google.com. 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 -~--~~~~--~~--~--~---
