You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Thomas DeWeese <Th...@Kodak.com> on 2005/06/25 12:48:12 UTC
Re: javascript dynamic update very slow
Javid Alimohideen wrote:
> I just started using Batik and i am in the process of creating an applet to
> view an existing SVG document with javascript features. I got it to work
> successfully but the dynamic updates handled by the javascript are very
> slow. I have more than 100 path elements to update and it takes around 2-3
> minutes to update all the elements. Is this because my SVG uses javascript?
Several minutes? That is _much_ slower than I would expect (easily
two orders of magnitude for the types of changes most people make).
What sort of changes are you making to the path elements? Are you
just changing attributes or are you doing complex math? How large is
the base document? Can you describe the basic structure of your
changes?
> Will converting javascript to java classes help in performance?
It depends on exactly what you are doing. If it is really
compute bound (i.e. it is your calculations that are the major
bottleneck) then switching to Java could help. If it is mostly
redrawing performance then switching to java won't help much.
> I found out that javascript compiler converts .js files to java
> classes and SVG can load external resurces like jar archives.
> Can someone point me to some examples as how i could do this?
Well Rhino (the javascript interpreter used in Batik) when
not used in an Applet context will compile javascript on the
fly to Java Bytecode. It's probably not as good as an offline
compiler or better moving the code to real Java, but I would
guess that for straight calculations it would be pretty good.
I don't know anything about such a java script compiler
so I can't really tell you how you would tie it in. I suspect
that it wouldn't be trivial (in my experience such things are
good for 'stand alone' code but problematic across interfaces).
But since I don't know anything about this compiler it might
be easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: javascript dynamic update very slow
Posted by JAVID M ALIMOHIDEEN MEERASA <ja...@evl.uic.edu>.
Hi Thomas,
Sorry for not being very clear. I am using Batik-1.6 and the js.jar and
xerces jar that came with the distribution. Here is an example as how the
path elements are defined in the SVG document.
<g id="segments">^M
<path id = "I-90-E-2043-2042" d = "M457.280007229 266.595606184
L457.144470673 265.244372118" style=""/> ^M
<path id = "I-90-E-2042-2041" d = "M457.144470673 265.244372118
L457.144470673 263.80688907" style=""/>^M
<path id = "I-90-E-2041-2040" d = "M457.144470673 263.80688907
L457.144470673 262.465238224" style=""/>
and the list continues. There are 700 path elements in total.
And in the javascript the style is defined as follows:
var congestionStyle=new Array(
"fill:none;stroke-width:1;stroke-linecap:round;stroke-linejoin:miter;stroke:gray;",
//unknowncongestion
"fill:none;stroke:red;stroke-width:5;stroke-linecap:round;stroke-linejoin:miter;",
//highcongestion
"fill:none;stroke-width:5;stroke:orange;stroke-linecap:round;stroke-linejoin:miter;",
//mediacongestion
"fill:none;stroke:yellow;stroke-width:5;stroke-linecap:round;stroke-linejoin:miter;",
//lowcongestion
"fill:none;stroke:green;stroke-width:5;stroke-linecap:round;stroke-linejoin:miter;"
//noncongestion
);
The raw data is obtained from an URL and then parsed and are stored in the
highwayData variable. Then, i traverse through the array highway for all
the elements and apply their respective styles.
Thanks,
Javid
On Sun, 26 Jun 2005, Thomas DeWeese wrote:
> Hi Javid,
>
> Javid Alimohideen wrote:
> > Sorry, i forgot to mention the number of elements i am trying to update.
> > It's around 700.
>
> To be clear you are updating the style element on 700 elements? or
> are you updating 100 elements in a document of 700 elements?
>
> > Thanks for the reply. Here is the piece of code that updates the SVG
> > document.
> > highwayData is an array of size more than 100. All the path elements have an
> > unique ID and i change the attributes to a particular style based on the ID.
>
> The first thing is that switching to compiled JavaScript or plain
> Java won't win you much for this code (there are a few things I
> might change but given the loop only executes 100-700 times I doubt
> they are the main problem).
>
> I suspect one of two problems, first if you aren't using
> Batik 1.6 it includes a significantly improved implementation of
> 'getElementById', the implementation in 1.5.1 and earlier would
> walk the entire tree.
>
> The second I would suspect the CSS property subsystem. When
> anything changes on an element it needs to examine all
> the children and following siblings as there could be a CSS pattern
> that would cause the other elements to change as well. A quick and
> dirty way to find out if this is the problem is that assuming all
> your path elements are siblings would be to insert groups every 10
> or so path elements. Since you are using getElementById this shouldn't
> effect the script but will allow the CSS engine to stop after just 5-10
> elements.
>
> Can you give an example of the value of style you are using?
> I'm mostly curious if you are using filters or any other really
> expensive features of SVG...
>
> > Javascript Code:
> > for(i=0;i<parseInt((highwayData.length)/5);i++)
>
> BTW this is a bit silly if highwayData.length wasn't
> an int dividing by 5 wouldn't work. Given your usage I would
> use:
> for (i=0; i<highwayData.length; i+=5) ...
>
> > {
> > System.out.println(highwayData[5*i]);
> > segnode=svgDocument.getElementById(highwayData[5*i]);
> >
> > if(segnode==null)
> > {
> > continue;
> > }
> > fillstyle=congestionStyle[highwayData[5*i+1]];
> > segnode.setAttributeNS(null, "style",fillstyle);
> > }
> >
> > Thanks,
> > Javid
> >
> > A clever person solves a problem.
> > A wise person avoids it.
> >
> > -- Einstein
> >
> >
> > -----Original Message-----
> > From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com]
> > Sent: Saturday, June 25, 2005 5:48 AM
> > To: batik-users@xmlgraphics.apache.org
> > Subject: Re: javascript dynamic update very slow
> >
> >
> > Javid Alimohideen wrote:
> >
> >
> >>I just started using Batik and i am in the process of creating an applet
> >
> > to
> >
> >>view an existing SVG document with javascript features. I got it to work
> >>successfully but the dynamic updates handled by the javascript are very
> >>slow. I have more than 100 path elements to update and it takes around 2-3
> >>minutes to update all the elements. Is this because my SVG uses
> >
> > javascript?
> >
> > Several minutes? That is _much_ slower than I would expect (easily
> > two orders of magnitude for the types of changes most people make).
> >
> > What sort of changes are you making to the path elements? Are you
> > just changing attributes or are you doing complex math? How large is
> > the base document? Can you describe the basic structure of your
> > changes?
> >
> >
> >>Will converting javascript to java classes help in performance?
> >
> >
> > It depends on exactly what you are doing. If it is really
> > compute bound (i.e. it is your calculations that are the major
> > bottleneck) then switching to Java could help. If it is mostly
> > redrawing performance then switching to java won't help much.
> >
> >
> >>I found out that javascript compiler converts .js files to java
> >>classes and SVG can load external resurces like jar archives.
> >>Can someone point me to some examples as how i could do this?
> >
> >
> > Well Rhino (the javascript interpreter used in Batik) when
> > not used in an Applet context will compile javascript on the
> > fly to Java Bytecode. It's probably not as good as an offline
> > compiler or better moving the code to real Java, but I would
> > guess that for straight calculations it would be pretty good.
> >
> > I don't know anything about such a java script compiler
> > so I can't really tell you how you would tie it in. I suspect
> > that it wouldn't be trivial (in my experience such things are
> > good for 'stand alone' code but problematic across interfaces).
> > But since I don't know anything about this compiler it might
> > be easy.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: javascript dynamic update very slow
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Javid,
Javid Alimohideen wrote:
> Sorry, i forgot to mention the number of elements i am trying to update.
> It's around 700.
To be clear you are updating the style element on 700 elements? or
are you updating 100 elements in a document of 700 elements?
> Thanks for the reply. Here is the piece of code that updates the SVG
> document.
> highwayData is an array of size more than 100. All the path elements have an
> unique ID and i change the attributes to a particular style based on the ID.
The first thing is that switching to compiled JavaScript or plain
Java won't win you much for this code (there are a few things I
might change but given the loop only executes 100-700 times I doubt
they are the main problem).
I suspect one of two problems, first if you aren't using
Batik 1.6 it includes a significantly improved implementation of
'getElementById', the implementation in 1.5.1 and earlier would
walk the entire tree.
The second I would suspect the CSS property subsystem. When
anything changes on an element it needs to examine all
the children and following siblings as there could be a CSS pattern
that would cause the other elements to change as well. A quick and
dirty way to find out if this is the problem is that assuming all
your path elements are siblings would be to insert groups every 10
or so path elements. Since you are using getElementById this shouldn't
effect the script but will allow the CSS engine to stop after just 5-10
elements.
Can you give an example of the value of style you are using?
I'm mostly curious if you are using filters or any other really
expensive features of SVG...
> Javascript Code:
> for(i=0;i<parseInt((highwayData.length)/5);i++)
BTW this is a bit silly if highwayData.length wasn't
an int dividing by 5 wouldn't work. Given your usage I would
use:
for (i=0; i<highwayData.length; i+=5) ...
> {
> System.out.println(highwayData[5*i]);
> segnode=svgDocument.getElementById(highwayData[5*i]);
>
> if(segnode==null)
> {
> continue;
> }
> fillstyle=congestionStyle[highwayData[5*i+1]];
> segnode.setAttributeNS(null, "style",fillstyle);
> }
>
> Thanks,
> Javid
>
> A clever person solves a problem.
> A wise person avoids it.
>
> -- Einstein
>
>
> -----Original Message-----
> From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com]
> Sent: Saturday, June 25, 2005 5:48 AM
> To: batik-users@xmlgraphics.apache.org
> Subject: Re: javascript dynamic update very slow
>
>
> Javid Alimohideen wrote:
>
>
>>I just started using Batik and i am in the process of creating an applet
>
> to
>
>>view an existing SVG document with javascript features. I got it to work
>>successfully but the dynamic updates handled by the javascript are very
>>slow. I have more than 100 path elements to update and it takes around 2-3
>>minutes to update all the elements. Is this because my SVG uses
>
> javascript?
>
> Several minutes? That is _much_ slower than I would expect (easily
> two orders of magnitude for the types of changes most people make).
>
> What sort of changes are you making to the path elements? Are you
> just changing attributes or are you doing complex math? How large is
> the base document? Can you describe the basic structure of your
> changes?
>
>
>>Will converting javascript to java classes help in performance?
>
>
> It depends on exactly what you are doing. If it is really
> compute bound (i.e. it is your calculations that are the major
> bottleneck) then switching to Java could help. If it is mostly
> redrawing performance then switching to java won't help much.
>
>
>>I found out that javascript compiler converts .js files to java
>>classes and SVG can load external resurces like jar archives.
>>Can someone point me to some examples as how i could do this?
>
>
> Well Rhino (the javascript interpreter used in Batik) when
> not used in an Applet context will compile javascript on the
> fly to Java Bytecode. It's probably not as good as an offline
> compiler or better moving the code to real Java, but I would
> guess that for straight calculations it would be pretty good.
>
> I don't know anything about such a java script compiler
> so I can't really tell you how you would tie it in. I suspect
> that it wouldn't be trivial (in my experience such things are
> good for 'stand alone' code but problematic across interfaces).
> But since I don't know anything about this compiler it might
> be easy.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: javascript dynamic update very slow
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
Sorry, i forgot to mention the number of elements i am trying to update.
It's around 700.
Javid
A clever person solves a problem.
A wise person avoids it.
-- Einstein
-----Original Message-----
From: Javid Alimohideen [mailto:javid@evl.uic.edu]
Sent: Saturday, June 25, 2005 9:30 PM
To: batik-users@xmlgraphics.apache.org
Subject: RE: javascript dynamic update very slow
Thanks for the reply. Here is the piece of code that updates the SVG
document.
highwayData is an array of size more than 100. All the path elements have an
unique ID and i change the attributes to a particular style based on the ID.
Javascript Code:
for(i=0;i<parseInt((highwayData.length)/5);i++)
{
System.out.println(highwayData[5*i]);
segnode=svgDocument.getElementById(highwayData[5*i]);
if(segnode==null)
{
continue;
}
fillstyle=congestionStyle[highwayData[5*i+1]];
segnode.setAttributeNS(null, "style",fillstyle);
}
Thanks,
Javid
A clever person solves a problem.
A wise person avoids it.
-- Einstein
-----Original Message-----
From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com]
Sent: Saturday, June 25, 2005 5:48 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: javascript dynamic update very slow
Javid Alimohideen wrote:
> I just started using Batik and i am in the process of creating an applet
to
> view an existing SVG document with javascript features. I got it to work
> successfully but the dynamic updates handled by the javascript are very
> slow. I have more than 100 path elements to update and it takes around 2-3
> minutes to update all the elements. Is this because my SVG uses
javascript?
Several minutes? That is _much_ slower than I would expect (easily
two orders of magnitude for the types of changes most people make).
What sort of changes are you making to the path elements? Are you
just changing attributes or are you doing complex math? How large is
the base document? Can you describe the basic structure of your
changes?
> Will converting javascript to java classes help in performance?
It depends on exactly what you are doing. If it is really
compute bound (i.e. it is your calculations that are the major
bottleneck) then switching to Java could help. If it is mostly
redrawing performance then switching to java won't help much.
> I found out that javascript compiler converts .js files to java
> classes and SVG can load external resurces like jar archives.
> Can someone point me to some examples as how i could do this?
Well Rhino (the javascript interpreter used in Batik) when
not used in an Applet context will compile javascript on the
fly to Java Bytecode. It's probably not as good as an offline
compiler or better moving the code to real Java, but I would
guess that for straight calculations it would be pretty good.
I don't know anything about such a java script compiler
so I can't really tell you how you would tie it in. I suspect
that it wouldn't be trivial (in my experience such things are
good for 'stand alone' code but problematic across interfaces).
But since I don't know anything about this compiler it might
be easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: javascript dynamic update very slow
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
Thanks for the reply. Here is the piece of code that updates the SVG
document.
highwayData is an array of size more than 100. All the path elements have an
unique ID and i change the attributes to a particular style based on the ID.
Javascript Code:
for(i=0;i<parseInt((highwayData.length)/5);i++)
{
System.out.println(highwayData[5*i]);
segnode=svgDocument.getElementById(highwayData[5*i]);
if(segnode==null)
{
continue;
}
fillstyle=congestionStyle[highwayData[5*i+1]];
segnode.setAttributeNS(null, "style",fillstyle);
}
Thanks,
Javid
A clever person solves a problem.
A wise person avoids it.
-- Einstein
-----Original Message-----
From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com]
Sent: Saturday, June 25, 2005 5:48 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: javascript dynamic update very slow
Javid Alimohideen wrote:
> I just started using Batik and i am in the process of creating an applet
to
> view an existing SVG document with javascript features. I got it to work
> successfully but the dynamic updates handled by the javascript are very
> slow. I have more than 100 path elements to update and it takes around 2-3
> minutes to update all the elements. Is this because my SVG uses
javascript?
Several minutes? That is _much_ slower than I would expect (easily
two orders of magnitude for the types of changes most people make).
What sort of changes are you making to the path elements? Are you
just changing attributes or are you doing complex math? How large is
the base document? Can you describe the basic structure of your
changes?
> Will converting javascript to java classes help in performance?
It depends on exactly what you are doing. If it is really
compute bound (i.e. it is your calculations that are the major
bottleneck) then switching to Java could help. If it is mostly
redrawing performance then switching to java won't help much.
> I found out that javascript compiler converts .js files to java
> classes and SVG can load external resurces like jar archives.
> Can someone point me to some examples as how i could do this?
Well Rhino (the javascript interpreter used in Batik) when
not used in an Applet context will compile javascript on the
fly to Java Bytecode. It's probably not as good as an offline
compiler or better moving the code to real Java, but I would
guess that for straight calculations it would be pretty good.
I don't know anything about such a java script compiler
so I can't really tell you how you would tie it in. I suspect
that it wouldn't be trivial (in my experience such things are
good for 'stand alone' code but problematic across interfaces).
But since I don't know anything about this compiler it might
be easy.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org