Hi John,

"John C. Turnbull" <[email protected]> wrote on 02/09/2009 02:50:16 
PM:

> How would I go about implementing SVG DOM interaction in a browser-
> based script?  I am guessing I would need to change the script to 
> call the Batik Java methods that access the DOM ? is that how you 
> see it?

   I don't know how they bind Java classes/objects into the browser
script implementation. 

> Are you aware of any overheads from repeatedly invoking 
> Java methods from a JavaScript script?  If that?s going to be slow 
> then there?s no point in me proceeding because, as you say, most of 
> my scripts rely on the SVG DOM.

   I really don't know much of anything about calling Java from
browser script engines.  All of my comments have been based on my
general understanding of things (which is why I was curious about
other projects that might have done something similar).

> 
> Cheers,
> 
> John
> 
> From: [email protected] [mailto:[email protected]] 
> Sent: Monday, 9 February 2009 22:05
> To: [email protected]
> Cc: [email protected]
> Subject: RE: Scripting in Batik applets
> 
> 
> Hi John,
> 
> "John C. Turnbull" <[email protected]> wrote on 02/02/2009 07:06:07 
AM:
> 
> > Do you think that the scripts would run using the browser scripting 
> > engine as they are or would they need modification? 
> 
>    It depends entirely on what the script does.  If it's not talking 
> to the SVG DOM then the script should just run in the browser engine. 
> If the script is calling/querying the SVG DOM then I think it will 
> need to be modified. 
> 
> > I am no ECMAScript guru unfortunately.  Anyway, browser delivery of my 

> > applet(s) is very important and I would be interested in evaluating 
> > the performance gains or otherwise achievable by using the browser?s
> > scripting engine but only if it?s actually achievable and doable.  I
> > agree that the Java-to-JavaScript interface may be the bottleneck 
> > but I?d like to prove it one way or the other.  I am hoping it?s 
> > just a matter of passing the script over to the browser and then 
> > passing the result(s) back to the applet but clearly, depending on 
> > the nature of the script, this may involve a lot more interaction. 
> 
>    See above, I don't know what your scripts are doing but my guess 
> is that most of your scripts will be interacting with the DOM. 
> 
> > So if it doesn?t involve wholesale changes to the scripts themselves
> > then I would like to have a go at a benchmark. 
> 
> 
> 
> > From: [email protected] [mailto:[email protected]] 
> > Sent: Monday, 2 February 2009 22:18
> > To: [email protected]
> > Cc: [email protected]
> > Subject: Re: Scripting in Batik applets 
> > 
> > 
> > Hi John, 
> > 
> > "John C. Turnbull" <[email protected]> wrote on 02/01/2009 
06:46:41 PM:
> > 
> > > In an applet environment, I believe Rhino cannot use compiled 
> > > scripts and hence the performance of those scripts is worse than in 
> > > an application environment.  Now, given that most browser vendors 
> > > have introduced JIT compilers for JavaScript, how difficult would it
> > > be to replace the use of Rhino in Batik applets with the browser?s 
> > > JavaScript engine?  I imagine there would have to be some changes to
> > > the scripts themselves but Java/JavaScript interaction has greatly 
> > > improved since Java 6 Update 10 and using Batik in an applet 
> > > environment is very important to me. 
> > 
> >    I don't know what you are doing in the script but I suspect that 
> > Batik's performance is generally limited by the underlying Java code 
> > not the JavaScript.  If you are doing heavy duty operations in script 
> > it might make sense to do those in the browsers script engine and 
> > then send the results across to the Applet.  If your script is 
> > interacting heavily with the SVG DOM then it wouldn't surprise me if 
> > the extra overhead of the Browser<->Java communication would defeat 
> > the gain from using the Browser script engine. 
> > 
> >    In short while it might be a win in a few cases I suspect that 
> > the general case is likely to be a wash or close to it, but if anyone 
> > has benchmarks or something from projects that have done something 
> > similar I'd be interested in hearing about them. 

Reply via email to