Hi John, > [JCT] Well it's like this... there is no patch as I didn't actually make any > changes to Batik itself. I wanted to determine how fast scripting with the > browser engine would work and all I did was to run a modified script using > the load event dispatcher and added a couple of public methods to the applet > that invoked DOM methods using Batik. It was purely an experiment. If I > were to do it properly I would create a new implementation of the > Interpreter interface and have it run the scripts as required but I simply > didn't have enough time to devote to this exercise.
OK, but it was worth asking. ;-) I'm also not sure if it would also help if Rhino was updated -- I recall a couple of previous threads on this, and I'm not sure if there were performance improvements, but this may worth further study in a near future. :-) > [JCT] In fact I am using pack200 and ProGuard together which as a > combination produce a final applet JAR of less than a megabyte which > downloads on an average machine in about 4-5 seconds. It's very viable. 1 megabyte? Wow, I never got to the point of using Bytecode optimizers, but I didn't thought size could drop as much -- thanks for sharing. ;-) My idea was to write an "Applet packaging" how-to or similar, probably in that section of the Batik Wiki [1]. I believe integrating this information would also be pretty valuable. Would you like to start the page? ;-) Currently I only have a couple of scripts and tips and tricks such as using 7-zip [2] for the "gzip" step, which seems to increase compression (Windows command-line script snippet follows): :: NOTE: this assumes Java binaries directory and 7-zip directory in the system path (%PATH% variable) :: pack200 the Jar file without gzip compression pack200 --no-gzip --strip-debug --segment-limit=-1 --modification-time=latest -J-Xms64m -J-Xmx128m %JAR_FILE% :: use 7-zip for the compression step 7z a -tgzip %JAR_FILE%.pack.gz -mx=9 -mfb=258 -mpass=15 -si <%JAR_FILE% My tests show about 10% improvement over the gzip compression offered by the pack200 utility. But an optimized Jar file may yield different results: if you decide to make a few tests, it would be great to share the comparison result. ;-) > [JCT] I am not sure what you are saying here but, the way I see it, the > problem is that scripts which run in the browser interact with the DOM that > represents the structure and content of the web page whereas I require > interaction with the SVG DOM which represents the structure and content of > the SVG document that lives inside the applet. As far as I can tell, the > only way to achieve this is to have the script access the applet which in > turn accesses the SVG DOM. Correct me if I am wrong on this. I'm not sure about this being the only way. ASV (by default) and Renesis use the browser's scripting engine and DOM manipulations work so this is possible. :-) The base idea would be wrapping Batik in an ActiveX object, (there seem to exist tools to automate this [3]), so Batik wouldn't be seen as an applet but as an ActiveX object. What I'm saying is that probably this would require a lot of ActiveX/COM magic in order for to redirect DOM stuff for Batik to handle and the remaining scripting to the browser's engine. Also, given that there are different technologies involved, the COM<-->Java overhead would likely make it unfeasible (I anticipate an overall Batik performance degradation). But a real proof-of-concept would be required to throw this idea away -- unfortunately, I currently also have no time or the required expertize to carry this on, but if anyone else wants to step in and conduct some sort of prototype... :-) Regards, Helder [1] http://wiki.apache.org/xmlgraphics-batik/HowTo [2] http://7-zip.org/ [3] http://javaactivex.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
