xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John C. Turnbull" <ozem...@ozemail.com.au>
Subject RE: FW: Browser-based scripting in Batik applets - conclusions
Date Tue, 10 Mar 2009 09:47:12 GMT
Hi Helder,

> Cool, even if left incomplete, it would be great if you made this
> available. I'd suggest a patch attached to a RFE (request for
> extension) so that someone else may be able to improve and/or reuse in
> other contexts. Also, even if currently not awesome, give the steady
> speed improvement of browser scripting engines, it may well become
> suitable in a near future! ;-)

[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.

I completely agree that this usage may come into its own as browser
scripting performance increases although this may be tempered by the need to
invoke applet methods to access the SVG DOM which may be an unavoidable
overhead.

> Agreed. If you use JDK1.5+ clients and use the pack200 [1] method to
> repackage the Batik Jars, then this may become even smoother. :-)

[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.
 
> Weird, as far as I know, this would not be required. If I recall
> properly, if you implemented the scripting COM interfaces from ActiveX
> to Java, scripts should be able to run unmodified. But probably Batik
> needed to be repackaged as an ActiveX. My knowledge in this area is
> pretty limited, though... ;-)

[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.

Cheers,

John


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


Mime
View raw message