Hi Thomas,

 

Thanks for the response.

 

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

 

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