xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Helder Magalhães <helder.magalh...@gmail.com>
Subject Re: FW: Browser-based scripting in Batik applets - conclusions
Date Tue, 10 Mar 2009 11:35:01 GMT
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

:: 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... :-)


[1] http://wiki.apache.org/xmlgraphics-batik/HowTo
[2] http://7-zip.org/
[3] http://javaactivex.com/

To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

View raw message