[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: Support animated images in ImageResource
LGTM.
http://gwt-code-reviews.appspot.com/54808/diff/1/4
File user/src/com/google/gwt/resources/rg/ImageBundleBuilder.java
(right):
http://gwt-code-reviews.appspot.com/54808/diff/1/4#newcode636
Line 636: for (IteratorImageReader it =
ImageIO.getImageReadersBySuffix(suffix); it.hasNext();) {
Minor 80-col overflow.
http://gwt-code-reviews.appspot.com/54808
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[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] Just posted initial layout design doc
All, I just posted an initial design doc for the new Layout system here: http://code.google.com/p/google-web-toolkit/wiki/LayoutDesign Note that it doesn't address much in the way of details on the individual widget APIs yet -- it's mostly about the sorts of constraints that the system can express and how they're implemented. Ideas and feedback are, as always, welcome. I hope to have the first patch of a series ready for review later today. joel. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[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: Just posted initial layout design doc
Joel, Does this mean you can no longer say I don't care how wide my widget is, just take up whatever space is left? The document says you can use % as a unit, but if I say 100% as I don't care, just as big as possible, is something bad going to happen? -Ray On Wed, Jul 29, 2009 at 9:36 AM, Joel Webber j...@google.com wrote: All, I just posted an initial design doc for the new Layout system here: http://code.google.com/p/google-web-toolkit/wiki/LayoutDesign Note that it doesn't address much in the way of details on the individual widget APIs yet -- it's mostly about the sorts of constraints that the system can express and how they're implemented. Ideas and feedback are, as always, welcome. I hope to have the first patch of a series ready for review later today. joel. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Just posted initial layout design doc
That's correct, but only in the context of layout panels. So for example, you would have to explicitly specify the height of header widgets in a stack panel (say, 2em), but *inside* them, you can do whatever you want, using traditional CSS techniques. I imagine that most apps will have a relatively small number of layout panels for coarse-grained application structure (e.g., a dock, a couple of splitters, maybe a stack or two), with more standard structures within these panels. Does that make sense? On Wed, Jul 29, 2009 at 12:58 PM, Ray Cromwell cromwell...@gmail.comwrote: Joel, Does this mean you can no longer say I don't care how wide my widget is, just take up whatever space is left? The document says you can use % as a unit, but if I say 100% as I don't care, just as big as possible, is something bad going to happen? -Ray On Wed, Jul 29, 2009 at 9:36 AM, Joel Webber j...@google.com wrote: All, I just posted an initial design doc for the new Layout system here: http://code.google.com/p/google-web-toolkit/wiki/LayoutDesign Note that it doesn't address much in the way of details on the individual widget APIs yet -- it's mostly about the sorts of constraints that the system can express and how they're implemented. Ideas and feedback are, as always, welcome. I hope to have the first patch of a series ready for review later today. joel. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[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] [google-web-toolkit] r5834 commited - Update ant-launcher to ant version 1.7.1...
Revision: 5834 Author: zun...@google.com Date: Wed Jul 29 11:34:50 2009 Log: Update ant-launcher to ant version 1.7.1 Review by: jlabanca(TBR) http://code.google.com/p/google-web-toolkit/source/detail?r=5834 Added: /tools/lib/tomcat/ant-launcher-1.7.1.jar === --- /dev/null +++ /tools/lib/tomcat/ant-launcher-1.7.1.jarWed Jul 29 11:34:50 2009 Binary file, no diff available. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5833 commited - Added Apache Ant 1.7.1 to the list of tools....
Revision: 5833 Author: zun...@google.com Date: Wed Jul 29 11:22:15 2009 Log: Added Apache Ant 1.7.1 to the list of tools. Review by: jlabanca http://code.google.com/p/google-web-toolkit/source/detail?r=5833 Added: /tools/antlib/ant-junit-1.7.1.jar /tools/lib/apache/ant-1.7.1-src.zip /tools/lib/apache/ant-1.7.1.jar === --- /dev/null +++ /tools/antlib/ant-junit-1.7.1.jar Wed Jul 29 11:22:15 2009 Binary file, no diff available. === --- /dev/null +++ /tools/lib/apache/ant-1.7.1-src.zip Wed Jul 29 11:22:15 2009 File is too large to display a diff. === --- /dev/null +++ /tools/lib/apache/ant-1.7.1.jar Wed Jul 29 11:22:15 2009 File is too large to display a diff. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Generalized RPC for server-enhanced objects
Reviewers: robertvawter_google.com, scottb, Description: This patch removes the previous special-case handling of JDO objects in favor of a more general approach. First we determine which classes may be enhanced, based on annotations in the classes themselves or a new rpc.enhancedClasses configuration property. For those classes that are (possibly) enhanced and which may be transmitted in both directions between client and server, we place a list of client-visible methods into the .gwt.rpc file containing the RPC-able classes. At runtime, we use this list to identify any server-only fields and apply server-side serialization to them. When deserializing an enhanced object on the server, we user setter methods where possible rather than direct field writes. Please review this at http://gwt-code-reviews.appspot.com/51823 Affected files: user/src/com/google/gwt/user/RemoteService.gwt.xml user/src/com/google/gwt/user/rebind/rpc/ClientDataSerializer.java user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java user/src/com/google/gwt/user/rebind/rpc/JdoDetachedStateClientDataSerializer.java user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracle.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleImpl.java user/src/com/google/gwt/user/rebind/rpc/Shared.java user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java user/src/com/google/gwt/user/server/rpc/SerializationPolicy.java user/src/com/google/gwt/user/server/rpc/SerializationPolicyLoader.java user/src/com/google/gwt/user/server/rpc/impl/JdoDetachedStateServerDataSerializer.java user/src/com/google/gwt/user/server/rpc/impl/LegacySerializationPolicy.java user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java user/src/com/google/gwt/user/server/rpc/impl/ServerDataSerializer.java user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamWriter.java user/src/com/google/gwt/user/server/rpc/impl/StandardSerializationPolicy.java user/super/com/google/gwt/user/translatable/com/google/gwt/core/client/impl/WeakMapping.java user/test/com/google/gwt/user/server/rpc/RPCTest.java user/test/com/google/gwt/user/server/rpc/impl/StandardSerializationPolicyTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Generalized RPC for server-enhanced objects
This sounds very promising! Will there be (is there already?) a wiki page explaining how this works? Regards, -- Arthur Kalmenson On Wed, Jul 29, 2009 at 3:04 PM, r...@google.com wrote: Reviewers: robertvawter_google.com, scottb, Description: This patch removes the previous special-case handling of JDO objects in favor of a more general approach. First we determine which classes may be enhanced, based on annotations in the classes themselves or a new rpc.enhancedClasses configuration property. For those classes that are (possibly) enhanced and which may be transmitted in both directions between client and server, we place a list of client-visible methods into the .gwt.rpc file containing the RPC-able classes. At runtime, we use this list to identify any server-only fields and apply server-side serialization to them. When deserializing an enhanced object on the server, we user setter methods where possible rather than direct field writes. Please review this at http://gwt-code-reviews.appspot.com/51823 Affected files: user/src/com/google/gwt/user/RemoteService.gwt.xml user/src/com/google/gwt/user/rebind/rpc/ClientDataSerializer.java user/src/com/google/gwt/user/rebind/rpc/FieldSerializerCreator.java user/src/com/google/gwt/user/rebind/rpc/JdoDetachedStateClientDataSerializer.java user/src/com/google/gwt/user/rebind/rpc/ProxyCreator.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracle.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleImpl.java user/src/com/google/gwt/user/rebind/rpc/Shared.java user/src/com/google/gwt/user/server/rpc/RemoteServiceServlet.java user/src/com/google/gwt/user/server/rpc/SerializationPolicy.java user/src/com/google/gwt/user/server/rpc/SerializationPolicyLoader.java user/src/com/google/gwt/user/server/rpc/impl/JdoDetachedStateServerDataSerializer.java user/src/com/google/gwt/user/server/rpc/impl/LegacySerializationPolicy.java user/src/com/google/gwt/user/server/rpc/impl/SerializabilityUtil.java user/src/com/google/gwt/user/server/rpc/impl/ServerDataSerializer.java user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamWriter.java user/src/com/google/gwt/user/server/rpc/impl/StandardSerializationPolicy.java user/super/com/google/gwt/user/translatable/com/google/gwt/core/client/impl/WeakMapping.java user/test/com/google/gwt/user/server/rpc/RPCTest.java user/test/com/google/gwt/user/server/rpc/impl/StandardSerializationPolicyTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Testing new GWT RPC implementation (aka deRPC)
Hi Bob et. al, Obviously development is hard to predict, but do you have a rough estimate of when this will be ready for prime time? 2 months? 6 months? Nick On Fri, Jul 24, 2009 at 8:22 PM, BobV b...@google.com wrote: The deRPC code went into trunk a week or so ago, and no initial fires have been reported. I'd like to get folks on GWTC to give it a shakedown. Quickstart (for vanilla configurations): - Inherit com.google.gwt.rpc.Rpc in your gwt.xml file - Change your remote service interfaces to extend com.google.gwt.rpc.client.RpcService - Change your servlet to extend com.google.gwt.rpc.server.RpcServlet Right now, the new code base should be functionally equivalent to the legacy RPC system. The plan is to get the new code base stabilized with the existing feature set, before adding new features. Slowstart (for people doing their own thing) - The gwt.rpc file is now mandatory for operation of the RPC system. It's no longer just a policy file, but contains metadata about any given permutation. You can override RpcServlet.findClientOracleData() to alter how this data is retrieved. - If you have been using the static gwt.user.rpc.server.RPC utility class, there is a new formulation of the same in gwt.rpc.server.RPC. Instances of the ClientOracle type can be obtained from WebModeClientOracle.load() or simply instantiating a HostedModeClientOracle. - If you want your servlet to be able to talk to both legacy and new RPC clients, extend HybridServiceServlet. I'm mainly looking for the following kinds of feedback: - Knowing that it did work is helpful. - If it doesn't work, please tell me how it breaks: - Run your JVM with -Dgwt.rpc.dumpPayload=true to have RpcServlet emit the incoming and outgoing payloads to System.out. - There are a lot of low-hanging optimizations that remain to be done. If you have any particular metrics or features that you particularly care about, let me know so I can prioritize accordingly. Why switch? - Faster IE6 performance - Hosted Mode clients don't need a serialization policy file pushed to the server, so you can more easily test changes to client code in a -noserver configuration. - A much more hackable code base to add oft-requested features to the GWT RPC system. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5836 commited - Update branch info to reflect r5835.
Revision: 5836 Author: r...@google.com Date: Wed Jul 29 13:59:08 2009 Log: Update branch info to reflect r5835. http://code.google.com/p/google-web-toolkit/source/detail?r=5836 Modified: /branches/snapshot-2009.07.21-r5768/branch-info.txt === --- /branches/snapshot-2009.07.21-r5768/branch-info.txt Wed Jul 22 07:57:45 2009 +++ /branches/snapshot-2009.07.21-r5768/branch-info.txt Wed Jul 29 13:59:08 2009 @@ -1,4 +1,4 @@ -branch-info.txt for the 2009.07.21 -r5768 snapshot branch. +branch-info.txt for the 2009.07.21-r5768 snapshot branch. Tracks interactions between this branch and other branches. See: http://code.google.com/p/google-web-toolkit/wiki/ManagingMerges @@ -6,3 +6,5 @@ /branches/snapshot-2009.07.21-r5768 was created (r5770) as a straight copy from /trunk/@5768 Merges: +/trunk c5819 was merged (r5835) into snapshot + $ svn merge -c5819 http://google-web-toolkit.googlecode.com/svn/trunk . --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5837 commited - Change file reference test to use new API dealing with types rather th...
Revision: 5837
Author: j...@google.com
Date: Wed Jul 29 14:58:34 2009
Log: Change file reference test to use new API dealing with types rather
than
file names.
http://code.google.com/p/google-web-toolkit/source/detail?r=5837
Modified:
/changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/CompilationUnitFileReferenceTest.java
===
---
/changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/CompilationUnitFileReferenceTest.java
Fri May 8 17:38:40 2009
+++
/changes/jat/ihm/dev/core/test/com/google/gwt/dev/javac/CompilationUnitFileReferenceTest.java
Wed Jul 29 14:58:34 2009
@@ -21,11 +21,13 @@
import com.google.gwt.dev.javac.impl.MockResourceOracle;
import com.google.gwt.dev.javac.impl.SourceFileCompilationUnit;
import com.google.gwt.dev.resource.Resource;
+import com.google.gwt.dev.util.Name.BinaryName;
import com.google.gwt.dev.util.log.AbstractTreeLogger;
import com.google.gwt.dev.util.log.PrintWriterTreeLogger;
import junit.framework.TestCase;
+import java.util.Collections;
import java.util.HashMap;
import java.util.HashSet;
import java.util.Map;
@@ -120,21 +122,26 @@
static {
// Setup EXPECTED_DEPENDENCIES with hand-computed data.
-initializeExpectedDependency(JavaResourceBase.FOO,
JavaResourceBase.STRING);
-initializeExpectedDependency(JavaResourceBase.BAR,
JavaResourceBase.STRING,
-JavaResourceBase.FOO);
+initializeExpectedDependency(test/Foo, java/lang/String,
+java/lang/Object);
+initializeExpectedDependency(test/Bar, java/lang/String,
+test/Foo);
// TOP has a self-reference
-initializeExpectedDependency(TOP, JavaResourceBase.STRING, TOP);
-initializeExpectedDependency(TOP3, JavaResourceBase.STRING, TOP);
-
-initializeExpectedDependency(OUTER, JavaResourceBase.STRING);
-initializeExpectedDependency(MEMBER_INNER_SUBCLASS,
-JavaResourceBase.STRING, OUTER);
-
-initializeExpectedDependency(OUTER, JavaResourceBase.STRING);
-initializeExpectedDependency(STATIC_INNER_SUBCLASS,
-JavaResourceBase.STRING, OUTER);
+initializeExpectedDependency(test/Top, java/lang/String,
+java/lang/Object, test/Top);
+initializeExpectedDependency(test/Top3, java/lang/String,
+test/Top2);
+
+
initializeExpectedDependency(test/Outer, test/Outer, java/lang/String,
+test/Outer$StaticInner, java/lang/Object,
test/Outer$MemberInner);
+
+initializeExpectedDependency(test/OuterSubclass,
+test/OuterSubclass$MemberInnerSubclass, test/Outer,
+java/lang/String, test/OuterSubclass, test/Outer$MemberInner);
+
+initializeExpectedDependency(test/StaticInnerSubclass,
+test/Outer, java/lang/String, test/Outer$StaticInner);
}
/**
@@ -150,13 +157,11 @@
return TreeLogger.NULL;
}
- private static void initializeExpectedDependency(Resource source,
- Resource... targets) {
+ private static void initializeExpectedDependency(String type,
+ String... referencedTypes) {
SetString targetSet = new HashSetString();
-for (Resource target : targets) {
- targetSet.add(target.getLocation());
-}
-EXPECTED_DEPENDENCIES.put(source.getLocation(), targetSet);
+Collections.addAll(targetSet, referencedTypes);
+EXPECTED_DEPENDENCIES.put(type, targetSet);
}
private MockResourceOracle oracle = new MockResourceOracle(
@@ -212,13 +217,14 @@
}
private void assertRefsMatchExpectedRefs(Resource... files) {
-// TODO(jat): reimplement with new API
-//for (Resource sourceFile : files) {
-// SetString sourceFileRefs = state.getCompilationUnitMap().get(
-//
SourceFileCompilationUnit.getTypeName(sourceFile)).getFileNameRefs();
-// SetString expectedSourceFileRefs =
EXPECTED_DEPENDENCIES.get(sourceFile.getLocation());
-// assertEquals(expectedSourceFileRefs, sourceFileRefs);
-//}
+for (Resource sourceFile : files) {
+ String typeName = SourceFileCompilationUnit.getTypeName(sourceFile);
+ SetString sourceFileRefs = state.getCompilationUnitMap().get(
+ typeName).getReferencedTypes();
+ SetString expectedSourceFileRefs = EXPECTED_DEPENDENCIES.get(
+ BinaryName.toInternalName(typeName));
+ assertEquals(expectedSourceFileRefs, sourceFileRefs);
+}
}
/**
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit] r5835 commited - Merging /trunk c5819 into this branch.
Revision: 5835
Author: r...@google.com
Date: Wed Jul 29 13:57:34 2009
Log: Merging /trunk c5819 into this branch.
http://code.google.com/p/google-web-toolkit/source/detail?r=5835
Modified:
/branches/snapshot-2009.07.21-r5768/dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java
/branches/snapshot-2009.07.21-r5768/dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java
===
---
/branches/snapshot-2009.07.21-r5768/dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java
Thu Jul 16 16:35:08 2009
+++
/branches/snapshot-2009.07.21-r5768/dev/core/src/com/google/gwt/dev/jjs/impl/CodeSplitter.java
Wed Jul 29 13:57:34 2009
@@ -555,14 +555,6 @@
for (JMethod entryMethod : jprogram.entryMethods.get(splitPoint)) {
cfa.traverseFrom(entryMethod);
}
-if (splitPoint == 0) {
- /*
- * Include class literal factories for simplicity. It is possible to
move
- * them out, if they are only needed by one fragment, but they are
tiny,
- * so it does not seem worth the complexity in the compiler.
- */
- cfa.traverseFromClassLiteralFactories();
-}
}
private static T SetT union(Set? extends T set1, Set? extends T
set2) {
===
---
/branches/snapshot-2009.07.21-r5768/dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java
Tue Jul 21 18:30:12 2009
+++
/branches/snapshot-2009.07.21-r5768/dev/core/src/com/google/gwt/dev/jjs/impl/ControlFlowAnalyzer.java
Wed Jul 29 13:57:34 2009
@@ -771,34 +771,6 @@
public void traverseFrom(JMethod method) {
rescuer.rescue(method);
}
-
- /**
- * Trace all code needed by class literal constructor expressions except
for
- * the string literals they include. At the time of writing, these would
- * include the factory methods for class literals.
- */
- public void traverseFromClassLiteralFactories() {
-class ReplaceStringLiterals extends JModVisitor {
- @Override
- public void endVisit(JStringLiteral stringLiteral, Context ctx) {
-ctx.replaceMe(program.getLiteralNull());
- }
-}
-
-final JModVisitor stringLiteralReplacer = new ReplaceStringLiterals();
-final CloneExpressionVisitor cloner = new
CloneExpressionVisitor(program);
-
-class ClassLitTraverser extends JVisitor {
- @Override
- public void endVisit(JClassLiteral classLiteral, Context ctx) {
-JExpression initializer = classLiteral.getField().getInitializer();
-JExpression initializerWithoutStrings =
stringLiteralReplacer.accept(cloner.cloneExpression(initializer));
-rescuer.accept(initializerWithoutStrings);
- }
-}
-
-(new ClassLitTraverser()).accept(program);
- }
public void traverseFromLeftoversFragmentHasLoaded() {
if (program.entryMethods.size() 1) {
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Obfuscator/GZip optimization patch
Reviewers: scottb, Lex, Description: Obfuscation Optimization Patch, incorporates two features: 1) The first character of an obfuscated identifier can be base-54 instead of base-32. This reduces output size by 0.5-1%. This patch originally came from an external contributor (Issue #2448) 2) Change JsScope to use LinkedHashMap instead of HashMap. This allows identifiers to be allocated obfuscated identifiers in the original order of their declaration, which produces a lot more common substrings in the obfuscated output which significantly improves gzip/deflate compression. Experimental Data using gzip -9 on cache.html files: Mail sample: 191614/197548 (3%) (with patch/without/% improved) Chronoscope: 1373800/1482204 (7.3%) Showcase: 1641005/1832098 (10.5%) Please review this at http://gwt-code-reviews.appspot.com/54810 Affected files: dev/core/src/com/google/gwt/dev/js/JsObfuscateNamer.java dev/core/src/com/google/gwt/dev/js/ast/JsScope.java dev/core/src/com/google/gwt/dev/util/collect/Maps.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
