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 Javid Alimohideen <ja...@evl.uic.edu> on 2005/07/13 18:00:50 UTC
Applet way too slow on MAC
Hi,
I successfully finished writing my applet to view and interact with SVG. I
have two problems now.
1. Applet hangs when trying to hit refresh button on the browser (all
browsers and OS).
2. SVG takes way too much time to build and render on Mac. (Safari browser
on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
Can someone tell what i could be doing wrong?
Thanks for your help,
Javid
A clever person solves a problem.
A wise person avoids it.
-- Einstein
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Scott Ruffner <sr...@phy.ucsf.edu>.
hi, thomas --
javid's results are encouraging!
i tried the patch on my Windows laptop and observed a 30%
decrease in rendering speed -- confirming what you have experienced.
also: my app uses the UpdateManager scheme to update selected
pieces of a graph when the user alters the definition of an existing SVG
node. with the patch I was seeing artifacts because the previous
rendering of a node was not erased. i modified the code in
DynamicRenderer::repaint(RectListManager rlm) to clear the dirty
region before drawing it, and that fixed the problem.
scott ruffner
----- Original Message -----
From: "Thomas DeWeese" <Th...@Kodak.com>
To: <ba...@xmlgraphics.apache.org>
Sent: Thursday, September 22, 2005 4:46 AM
Subject: Re: Applet way too slow on MAC
> Hi Andreas, Scott,
>
> I have created a new bug in Bugzilla to track this issue.
> I have also created a patch that replaced the current
> DynamicRenderer with one that doesn't touch the underlying
> raster data. This should in theory solve the problem for
> you on tiger. Since I don't have a Tiger system to check
> you will have to try it for me:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>
> There are some edge cases that I know the new renderer
> doesn't handle but I'm curious if it solves the problem
> at all or in any kind of useful percentage of the cases.
>
> Andreas Neumann wrote:
> > This issue is really annoying. I remember that the performance was much
> > better on Panther using the different color model as described in
> >
> >
http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200508.mbox/%3c42FA4DA8.3050104@phy.ucsf.edu%3e
> >
> >
> > Too bad, to discover that it's slow again on Tiger ...
> >
> > It would really help if the apple engineers could work on that issue.
> >
> > Andreas
> >
> > Thomas DeWeese wrote:
> >
> >> Hi Scott,
> >>
> >>> Thomas DeWeese wrote:
> >>
> >>
> >>
> >>>> I just noticed Apple released a Java 1.3/1.4 update for
> >>>> Tiger. Can you check if this fixes the problem?
> >>>
> >>>
> >>
> >> Scott A. Ruffner wrote:
> >>
> >>> i just installed the Java update on my Powerbook, and it
> >>> made no difference in performance -- it's still 20x slower
> >>> than under Panther 10.3.9. :(
> >>
> >>
> >>
> >> Too bad.
> >>
> >>> thomas, is there any chance you'll be able to revise how batik
> >>> uses BufferedImage/WritableRaster to avoid this performance hit?
> >>
> >>
> >>
> >> There is essentially no way to fix this in all of Batik.
> >> Much of Batik is built around the java.awt.image.RenderedImage
> >> interface. In this interface an image is composed of tiles which
> >> are rasters, so you basically can't avoid touching the rasters that
> >> are used to build BufferedImages for rendering.
> >>
> >> There is some chance that the use of Rasters/RenderedImages
> >> might be avoided in the 'DynamicRenderer' which would help for
> >> simple things but I think that you would find that most content
> >> would 'trip' over the raster access.
> >>
> >> ---------------------------------------------------------------------
> >> 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: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
> I'll be putting up a new version that uses the Mac OS X
>'preferred' BufferedImage type that _might_ make it a bit faster
>even.
>
>
>
good
>>With the new renderer, however, you seem to have created a (hopefully
>>easy to fix?) new problem. When there is no background rectangle with a
>>defined color, the normally white background now appears black.
>>
>>
>
> Both your problems are fairly simple to fix, now that we have a
>basic solution to the problem I'll work on these issues. The one
>possibly tricky problem I've seen with the new renderer is that
>occasionally objects leave 'bits' behind - do you see this on Mac OS X?
>I've looked at the code for this and I suspect it's a rounding issue
>with the JVM renderer but it need to investigate a bit more.
>
>
>
no, I don't see these effects of objects not being rendered. The quality
and behaviour seems fine, except the background and zoom problems
previously described.
The only effects I have are the ones with the black backgrounds as
described with the screenshots and when resizing windows. When resizing
the Squiggle window one shortly sees both the old and the new rendering
at once until the new one is fully renderered. To be more specific: if
the windows wasn't maximized and one maximizes the window (or manually
increases the window size) one briefly sees the old rendering at the
previous window size and in the background already the new rendering.
Finally, the new rendering fully replaces the old rendering correctly.
This is only a very minor flaw.
>>Do you think that background problem is easy to fix? Do you think you
>>can provide the improvements for rendering dynamic documents also for
>>static documents, eliminating the need to add useless script nodes?
>>
>>
>
> Since the new renderer doesn't seem to offer any advantage (and may
>be a bit slower) for Windows, I'll likely make the DynamicRenderer
>a 'MacOSXRenderer' and have it used all the time on Mac OS X. This does
>mean that you will loose the tiled rendering that is currently used
>for the Static renderer but since that uses Rasters it's going to
>be horribly slow on Mac OS X anyways.
>
>
I see.
Let's hope the Apple people don't mess everything up again in the future
MacOSX versions!
Thanks and all the best,
Andreas
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andreas,
Andreas Neumann wrote:
> Yeah!!!!
>
> that fixed it Thomas.
Good news!
> The rendering time is now much faster. The whole rendering (including
> the 4 getURL remote calls) is now a few seconds. It is now quite similar
> to the speed I experience on Window/Linux, maybe a little bit slower -
> but then my Mac machine is slower than my PC ...
I'll be putting up a new version that uses the Mac OS X
'preferred' BufferedImage type that _might_ make it a bit faster
even.
> With the new renderer, however, you seem to have created a (hopefully
> easy to fix?) new problem. When there is no background rectangle with a
> defined color, the normally white background now appears black.
Both your problems are fairly simple to fix, now that we have a
basic solution to the problem I'll work on these issues. The one
possibly tricky problem I've seen with the new renderer is that
occasionally objects leave 'bits' behind - do you see this on Mac OS X?
I've looked at the code for this and I suspect it's a rounding issue
with the JVM renderer but it need to investigate a bit more.
> Do you think that background problem is easy to fix? Do you think you
> can provide the improvements for rendering dynamic documents also for
> static documents, eliminating the need to add useless script nodes?
Since the new renderer doesn't seem to offer any advantage (and may
be a bit slower) for Windows, I'll likely make the DynamicRenderer
a 'MacOSXRenderer' and have it used all the time on Mac OS X. This does
mean that you will loose the tiled rendering that is currently used
for the Static renderer but since that uses Rasters it's going to
be horribly slow on Mac OS X anyways.
> I also added this information to bugzilla with one screenshot.
>
> Thanks a lot for your efforts, Thomas!
>
> Andreas
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Yeah!!!!
that fixed it Thomas.
The rendering time is now much faster. The whole rendering (including
the 4 getURL remote calls) is now a few seconds. It is now quite similar
to the speed I experience on Window/Linux, maybe a little bit slower -
but then my Mac machine is slower than my PC ...
Very cool!
> I think this was fine. It looks like the draw is just going
>_very_ slowly (every single stack trace was stuck in
>'apple.awt.CRenderer.doShape'.
>
> One thing is that I created yet another DynamicRenderer that might
>help Mac OS X keep the buffered image on the graphics card.
>
> The other slightly odd thing is that in the stack traces it seemed
>to spend a lot of time drawing text. It looks like the content
>is using an SVG font? I'd be a little curious (if the new
>DynamicRenderer doesn't fix the problem) if switching the font to a
>'system' font helped at all or a lot (might be a pain to test).
>
>
>
no, it works now fast again.
With the new renderer, however, you seem to have created a (hopefully
easy to fix?) new problem. When there is no background rectangle with a
defined color, the normally white background now appears black. (only in
the dynamic SVG files (with script links)). The static files appear
correctly (with white background) but still render awfully slow. Adding
an empty script node would make the files render very fast, but would
introduce this ugly black background.
see
http://www.carto.net/neumann/temp/screenshot_black_background_1.png
and
http://www.carto.net/neumann/temp/screenshot_black_background_2.png
Do you think that background problem is easy to fix? Do you think you
can provide the improvements for rendering dynamic documents also for
static documents, eliminating the need to add useless script nodes?
I also added this information to bugzilla with one screenshot.
Thanks a lot for your efforts, Thomas!
Andreas
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andreas,
Andreas Neumann wrote:
> I hope I did the correct thread dump now. I also found now the link to
> create attachments. The link looked a bit like the other attachments ...
Yes, it is a little hard to find.
> Let me know if you need the kill -3 command at a regular interval. I
> could write a small perl script to call it at , lets say every 15
> seconds. Currently I issued the command manually.
I think this was fine. It looks like the draw is just going
_very_ slowly (every single stack trace was stuck in
'apple.awt.CRenderer.doShape'.
One thing is that I created yet another DynamicRenderer that might
help Mac OS X keep the buffered image on the graphics card.
The other slightly odd thing is that in the stack traces it seemed
to spend a lot of time drawing text. It looks like the content
is using an SVG font? I'd be a little curious (if the new
DynamicRenderer doesn't fix the problem) if switching the font to a
'system' font helped at all or a lot (might be a pain to test).
>
> Andreas
>
> Thomas DeWeese wrote:
>
>> Hi Andreas,
>>
>> It looks like you were 'pinging' the Ant Java
>> processes not the Batik one, also I was hoping you
>> would make it an 'attachment' (further up the page)
>> not just paste it into the comment area (it mucks
>> with it less, and it doesn't get sent to everyone on
>> 'dev'):
>>
>
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
oops, too stupid from me.
I hope I did the correct thread dump now. I also found now the link to
create attachments. The link looked a bit like the other attachments ...
Let me know if you need the kill -3 command at a regular interval. I
could write a small perl script to call it at , lets say every 15
seconds. Currently I issued the command manually.
Andreas
Thomas DeWeese wrote:
> Hi Andreas,
>
> It looks like you were 'pinging' the Ant Java
> processes not the Batik one, also I was hoping you
> would make it an 'attachment' (further up the page)
> not just paste it into the comment area (it mucks
> with it less, and it doesn't get sent to everyone on
> 'dev'):
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by George Armhold <ar...@cs.rutgers.edu>.
Hi, has this patch made it into svn trunk yet? I just tested our app
with the latest svn, and based on its (unmeasured, but observed)
performance against Tiger, I'm guessing it hasn't. Also, will this
patch make things "worse" again on for folks still using Panther?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by th...@kodak.com.
Hi George,
George Armhold <ar...@cs.rutgers.edu> wrote on 10/13/2005 01:22:44 PM:
> Thomas DeWeese wrote:
>
> > It is in SVN now (the loose ends were longer than
> > I thought ;) It is now in the svg11 branch and trunk.
>
> Thanks Thomas. I think you might have some outstanding changes left to
> commit though, as the current trunk doesn't seem to build for me:
This is a problem with Java 5, and the way the applied
generics to the RenderingHints class. You must compile the code
in JDK 1.4 compatibility mode. I think someone posted a solution
on this to the list but I can't dig it up right now.
>
> localhost:2]/home/armhold/work/batik%ant jars
> Buildfile: build.xml
>
> init-args:
>
> init:
>
> compile:
> [echo] debug on, optimize on, deprecation on
> [javac] Compiling 293 source files to
/home/armhold/work/batik/classes
> [javac]
>
/home/armhold/work/batik/sources/org/apache/batik/gvt/renderer/MacRenderer.java:78:
> cannot find symbol
> [javac] symbol : constructor
RenderingHints(java.awt.RenderingHints)
> [javac] location: class java.awt.RenderingHints
> [javac] renderingHints = new
> RenderingHints(defaultRenderingHints);
> [javac] ^
> [javac]
>
/home/armhold/work/batik/sources/org/apache/batik/gvt/renderer/MacRenderer.java:84:
> cannot find symbol
> [javac] symbol : constructor
RenderingHints(java.awt.RenderingHints)
> [javac] location: class java.awt.RenderingHints
> [javac] renderingHints = new RenderingHints(rh);
> [javac] ^
> [javac]
>
/home/armhold/work/batik/sources/org/apache/batik/gvt/renderer/MacRenderer.java:145:
> cannot find symbol
> [javac] symbol : constructor
RenderingHints(java.awt.RenderingHints)
> [javac] location: class java.awt.RenderingHints
> [javac] this.renderingHints = new RenderingHints(rh);
> [javac] ^
> [javac] Note: Some input files use unchecked or unsafe operations.
> [javac] Note: Recompile with -Xlint:unchecked for details.
> [javac] 3 errors
>
> BUILD FAILED
> /home/armhold/work/batik/build.xml:432: Compile failed; see the compiler
> error output for details.
>
> Total time: 15 seconds
> localhost:2]/home/armhold/work/batik%svn info
> Path: .
> URL: http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk
> Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> Revision: 320811
> Node Kind: directory
> Schedule: normal
> Last Changed Author: deweese
> Last Changed Rev: 320740
> Last Changed Date: 2005-10-13 07:39:26 -0400 (Thu, 13 Oct 2005)
> Properties Last Updated: 2005-10-10 10:34:06 -0400 (Mon, 10 Oct 2005)
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> It is in SVN now (the loose ends were longer than
> I thought ;) It is now in the svg11 branch and trunk.
Thanks Thomas. I think you might have some outstanding changes left to
commit though, as the current trunk doesn't seem to build for me:
localhost:2]/home/armhold/work/batik%ant jars
Buildfile: build.xml
init-args:
init:
compile:
[echo] debug on, optimize on, deprecation on
[javac] Compiling 293 source files to /home/armhold/work/batik/classes
[javac]
/home/armhold/work/batik/sources/org/apache/batik/gvt/renderer/MacRenderer.java:78:
cannot find symbol
[javac] symbol : constructor RenderingHints(java.awt.RenderingHints)
[javac] location: class java.awt.RenderingHints
[javac] renderingHints = new
RenderingHints(defaultRenderingHints);
[javac] ^
[javac]
/home/armhold/work/batik/sources/org/apache/batik/gvt/renderer/MacRenderer.java:84:
cannot find symbol
[javac] symbol : constructor RenderingHints(java.awt.RenderingHints)
[javac] location: class java.awt.RenderingHints
[javac] renderingHints = new RenderingHints(rh);
[javac] ^
[javac]
/home/armhold/work/batik/sources/org/apache/batik/gvt/renderer/MacRenderer.java:145:
cannot find symbol
[javac] symbol : constructor RenderingHints(java.awt.RenderingHints)
[javac] location: class java.awt.RenderingHints
[javac] this.renderingHints = new RenderingHints(rh);
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 3 errors
BUILD FAILED
/home/armhold/work/batik/build.xml:432: Compile failed; see the compiler
error output for details.
Total time: 15 seconds
localhost:2]/home/armhold/work/batik%svn info
Path: .
URL: http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 320811
Node Kind: directory
Schedule: normal
Last Changed Author: deweese
Last Changed Rev: 320740
Last Changed Date: 2005-10-13 07:39:26 -0400 (Thu, 13 Oct 2005)
Properties Last Updated: 2005-10-10 10:34:06 -0400 (Mon, 10 Oct 2005)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi George,
George Armhold wrote:
> has this patch made it into svn trunk yet?
It is in SVN now (the loose ends were longer than
I thought ;) It is now in the svg11 branch and trunk.
> [...] Also, will this patch make things "worse"
> again on for folks still using Panther?
It shouldn't (and hasn't in my testing).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
Hi, Thomas, Andreas, et al --
I tested your latest patch (dtd 10/4/05) of DynamicRenderer in our app
and it's working great! I'm no longer having any problems with
dynamic updates of small portions of a document via UpdateManager,
and overall rendering speed is a little better than under 10.3.9.
Here's a summary (Powerbook G4, 800MHz, 1GB):
MacOSX Java Batik "doc" "build" "render"
10.3.x 1.4.1(?) 1.5 354 251 8308
10.3.x 1.4.2_?? 1.6 369 245 675
10.4.2 1.4.2_07 1.6 333 214 13637
10.4.2 1.4.2_09 1.6 (*) 277 133 677
10.4.2 1.4.2_09 1.6 (**) 266 90 432
* = with initial DynamicRenderer patch
** = with patch dtd 10/4/05
Andreas -- I did not get a chance to test the svg file as you
suggested, but I'm assuming it's moot at this point.
Thomas -- Thanks so much for your help!!! I second andreas in
praying that Apple doesn't muck things up again!
Scott
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: mouse zoom interactor
Posted by Maik Schürer <Ma...@proveo.de>.
Hi Thomas,
> Care to share your changes?
Sorry for my bad english - I'm not sure about the meaning of 'Care to'.
Do you mean if I want to publish my changes ?
I changed the instanciation of AbstractZoomInteractor() in JSVGCanvas.
Where the startInteraction() method was overwritten, I add
mouseReleased() to overwrite this method too. In the method
implementation I only changed the line
if ((xCurrent - xStart) != 0 && (yCurrent - yStart) != 0) ...
to
if (Math.abs(xCurrent - xStart) > 10 && Math.abs(yCurrent - yStart) > 10)
to discard 'small mouse events' less than 10 pixels mouse movement
If you think, this is useful for all Batik users, we can change
AbstractZoomInteractor.mouseReleased(), add a member for the pixel value
and add a set() method to allow changing this member. Default could be
0, so we have no different standard behaviour...
Maik
Thomas DeWeese schrieb:
> Hi Maik,
>
> Maik Schürer wrote:
>
>
>>I want to check the size of the rectangle when I zoom in via mouse (Ctrl
>> + left mouse button).
>>When the size of the rectangle is to small, I want discard this event.
>>What is the best way to do this ? Which class has the mouseReleased()
>>inside I'm looking for ?
>
>
> The class is 'org.apache.batik.swing.gvt.AbstractZoomInteractor'.
>
> Care to share your changes?
>
>
> ---------------------------------------------------------------------
> 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: mouse zoom interactor
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Maik,
Maik Schürer wrote:
> I want to check the size of the rectangle when I zoom in via mouse (Ctrl
> + left mouse button).
> When the size of the rectangle is to small, I want discard this event.
> What is the best way to do this ? Which class has the mouseReleased()
> inside I'm looking for ?
The class is 'org.apache.batik.swing.gvt.AbstractZoomInteractor'.
Care to share your changes?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
mouse zoom interactor
Posted by Maik Schürer <Ma...@proveo.de>.
Hi there,
I want to check the size of the rectangle when I zoom in via mouse (Ctrl
+ left mouse button).
When the size of the rectangle is to small, I want discard this event.
What is the best way to do this ? Which class has the mouseReleased()
inside I'm looking for ?
Maik
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andreas,
Andreas Neumann wrote:
> I tried the recent DynamicRenderer for MacOSX and can confirm that it
> runs fine now on Tiger. No more black backgrounds, good speed and no
> strange effects when zooming/resizing.
I believe there is still a 'dirty bits' problem. It is subtle
(usually looks like dirt on your screen ;) and may not occur at all with
many of your examples, but it is there at least with the towers solitaire
example. It manifests it's self as a single column or part of a column
(I think it's always a column) of pixels being left behind when one of
the cards is dragged/moved across the screen.
> Are you planning to make the DynamicRender now the default renderer for
> Mac? Static documents still run very slow.
I want to fix the dirty bits problem first.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Thomas,
I tried the recent DynamicRenderer for MacOSX and can confirm that it
runs fine now on Tiger. No more black backgrounds, good speed and no
strange effects when zooming/resizing.
Are you planning to make the DynamicRender now the default renderer for
Mac? Static documents still run very slow.
Thanks a lot for your efforts,
Andreas
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andreas,
It looks like you were 'pinging' the Ant Java
processes not the Batik one, also I was hoping you
would make it an 'attachment' (further up the page)
not just paste it into the comment area (it mucks
with it less, and it doesn't get sent to everyone on
'dev'):
"main" prio=5 tid=0x00500cd0 nid=0x1804600 in Object.wait()
[f07ff000..f08002c8]
at java.lang.Object.wait(Native Method)
- waiting on <0x65049498> (a java.lang.UNIXProcess)
at java.lang.Object.wait(Object.java:429)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:111)
- locked <0x65049498> (a java.lang.UNIXProcess)
at org.apache.tools.ant.taskdefs.Execute.waitFor(Execute.java:404)
at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:395)
at org.apache.tools.ant.taskdefs.Java.run(Java.java:338)
at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:115)
at org.apache.tools.ant.taskdefs.Java.execute(Java.java:88)
at org.apache.tools.ant.Task.perform(Task.java:217)
at org.apache.tools.ant.Target.execute(Target.java:184)
at org.apache.tools.ant.Target.performTasks(Target.java:202)
at org.apache.tools.ant.Project.executeTarget(Project.java:601)
at org.apache.tools.ant.Project.executeTargets(Project.java:560)
at org.apache.tools.ant.Main.runBuild(Main.java:454)
at org.apache.tools.ant.Main.start(Main.java:153)
at org.apache.tools.ant.Main.main(Main.java:176)
Andreas Neumann wrote:
`
> I did the thread dump as you proposed and uploaded it to
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>
> I had to remove the last thread dump because the text was too long for
> bugzilla and I could not find a way to upload a file.
>
> Let me know if I can help anything else.
>
> Thanks,
> Andreas
>
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Thomas,
I did the thread dump as you proposed and uploaded it to
http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
I had to remove the last thread dump because the text was too long for
bugzilla and I could not find a way to upload a file.
Let me know if I can help anything else.
Thanks,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andreas,
Can you generate a few thread dumps during the
several minutes it's updating with the 'dynamic'
content?
You can do this by running squiggle in one terminal
window, and then in a second terminal window getting
the process id of the squiggle java process:
ps | grep java
The process number is the first number in the line
with /usr/bin/java.
Then start the 'update' and in the second
terminal window run:
kill -3 <java process number>
This should trigger a bunch of output in the
first terminal window (where you ran squiggle).
Doing this a few times during the update would
be helpful to see if it is just moving slowly through
the graphics tree or if it is hung up on a particular
call.
You might attach the output to the bugzilla
bug on this issue.
Andreas Neumann wrote:
>
> Hi Thomas,
>
> I replaced the DynamicRender.java file (in
> trunk/sources/org/apache/batik/gvt/renderer/)
> <ci...@karto.baug.ethz.ch>
> , downloaded from
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769, but it did not
> help inmy case (Yosemite map). There is no noticable difference compared
> to the old renderer.
>
> Scott, if you try http://www.carto.net/williams/yosemite/index.svg in
> your Mac/Tiger - is it as slow as it is on my machine?
>
> Andreas
>
> Thomas DeWeese wrote:
>
>> Hi Scott, Andreas,
>>
>> I am at a bit of a loss what would cause such problems.
>> One possibility is that my use of a 'complex' clip path
>> to avoid multiple renders of the document is at fault. I've created
>> a new attachment to the bug that has a newer version of the Renderer
>> that uses something closer to the old code (multiple draws with
>> simple rect clips).
>>
>> Scott Ruffner wrote:
>>
>>> Hi, Andreas and Thomas --
>>>
>>>
>>>> I wonder what I did different from scott? Is it because I have a G4 and
>>>> scott has a G5? Or because I applied the patch to the trunk (latest
>>>> developer version) instead of the older stable version?
>>>
>>>
>>>
>>>
>>> I'm using a 800MHz G4 Powerbook, so our "testbeds" are
>>> similar in that regard. I think Thomas answered your question
>>> about the static document. My documents are always dynamic, so I
>>> "cheated" by overriding JGVTComponent.createImageRenderer()
>>> and instantiating the version of DynamicRenderer() that Thomas
>>> provided in the patch. Complete refreshes of the canvas were back to
>>> MacOSX 10.3/Batik 1.6 performance levels, but partial updates via
>>> the canvas's UpdateManager were often terribly long (>15sec vs
>>> ~150millisecs
>>> on WinXP).
>>>
>>> I don't know much about how scripting and the getURL() stuff works,
>>> but I'm guessing that if it is "remote" data, the UpdateManager is
>>> responsible
>>> for updating the canvas once the data has been retrieved. If so,
>>> perhaps
>>> the
>>> really slow rendering times you're seeing with the remote data are
>>> akin to
>>> the problems my app is having with partial updates of the loaded SVG
>>> document??
>>>
>>> Any thoughts, Thomas?
>>>
>>> thanks,
>>>
>>> Scott Ruffner
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Thomas,
I replaced the DynamicRender.java file (in
trunk/sources/org/apache/batik/gvt/renderer/)
<ci...@karto.baug.ethz.ch>
, downloaded from
http://issues.apache.org/bugzilla/show_bug.cgi?id=36769, but it did not
help inmy case (Yosemite map). There is no noticable difference compared
to the old renderer.
Scott, if you try http://www.carto.net/williams/yosemite/index.svg in
your Mac/Tiger - is it as slow as it is on my machine?
Andreas
Thomas DeWeese wrote:
> Hi Scott, Andreas,
>
> I am at a bit of a loss what would cause such problems.
> One possibility is that my use of a 'complex' clip path
> to avoid multiple renders of the document is at fault. I've created
> a new attachment to the bug that has a newer version of the Renderer
> that uses something closer to the old code (multiple draws with
> simple rect clips).
>
> Scott Ruffner wrote:
>
>> Hi, Andreas and Thomas --
>>
>>
>>> I wonder what I did different from scott? Is it because I have a G4 and
>>> scott has a G5? Or because I applied the patch to the trunk (latest
>>> developer version) instead of the older stable version?
>>
>>
>>
>> I'm using a 800MHz G4 Powerbook, so our "testbeds" are
>> similar in that regard. I think Thomas answered your question
>> about the static document. My documents are always dynamic, so I
>> "cheated" by overriding JGVTComponent.createImageRenderer()
>> and instantiating the version of DynamicRenderer() that Thomas
>> provided in the patch. Complete refreshes of the canvas were back to
>> MacOSX 10.3/Batik 1.6 performance levels, but partial updates via
>> the canvas's UpdateManager were often terribly long (>15sec vs
>> ~150millisecs
>> on WinXP).
>>
>> I don't know much about how scripting and the getURL() stuff works,
>> but I'm guessing that if it is "remote" data, the UpdateManager is
>> responsible
>> for updating the canvas once the data has been retrieved. If so,
>> perhaps
>> the
>> really slow rendering times you're seeing with the remote data are
>> akin to
>> the problems my app is having with partial updates of the loaded SVG
>> document??
>>
>> Any thoughts, Thomas?
>>
>> thanks,
>>
>> Scott Ruffner
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Scott, Andreas,
I am at a bit of a loss what would cause such problems.
One possibility is that my use of a 'complex' clip path
to avoid multiple renders of the document is at fault. I've created
a new attachment to the bug that has a newer version of the Renderer
that uses something closer to the old code (multiple draws with
simple rect clips).
Scott Ruffner wrote:
> Hi, Andreas and Thomas --
>
>
>>I wonder what I did different from scott? Is it because I have a G4 and
>>scott has a G5? Or because I applied the patch to the trunk (latest
>>developer version) instead of the older stable version?
>
>
> I'm using a 800MHz G4 Powerbook, so our "testbeds" are
> similar in that regard. I think Thomas answered your question
> about the static document. My documents are always dynamic, so I
> "cheated" by overriding JGVTComponent.createImageRenderer()
> and instantiating the version of DynamicRenderer() that Thomas
> provided in the patch. Complete refreshes of the canvas were back to
> MacOSX 10.3/Batik 1.6 performance levels, but partial updates via
> the canvas's UpdateManager were often terribly long (>15sec vs ~150millisecs
> on WinXP).
>
> I don't know much about how scripting and the getURL() stuff works,
> but I'm guessing that if it is "remote" data, the UpdateManager is
> responsible
> for updating the canvas once the data has been retrieved. If so, perhaps
> the
> really slow rendering times you're seeing with the remote data are akin to
> the problems my app is having with partial updates of the loaded SVG
> document??
>
> Any thoughts, Thomas?
>
> thanks,
>
> Scott Ruffner
>
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC
Posted by Scott Ruffner <sr...@phy.ucsf.edu>.
Hi, Andreas and Thomas --
> I wonder what I did different from scott? Is it because I have a G4 and
> scott has a G5? Or because I applied the patch to the trunk (latest
> developer version) instead of the older stable version?
I'm using a 800MHz G4 Powerbook, so our "testbeds" are
similar in that regard. I think Thomas answered your question
about the static document. My documents are always dynamic, so I
"cheated" by overriding JGVTComponent.createImageRenderer()
and instantiating the version of DynamicRenderer() that Thomas
provided in the patch. Complete refreshes of the canvas were back to
MacOSX 10.3/Batik 1.6 performance levels, but partial updates via
the canvas's UpdateManager were often terribly long (>15sec vs ~150millisecs
on WinXP).
I don't know much about how scripting and the getURL() stuff works,
but I'm guessing that if it is "remote" data, the UpdateManager is
responsible
for updating the canvas once the data has been retrieved. If so, perhaps
the
really slow rendering times you're seeing with the remote data are akin to
the problems my app is having with partial updates of the loaded SVG
document??
Any thoughts, Thomas?
thanks,
Scott Ruffner
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
>
> These are 'static' files so I'm not surprised the time didn't
> change. You can trick Batik into thinking they are dynamic by adding
> a script element (even if it does nothing). I'd be curious if this
> 'fixed' the problem for you.
>
oh, yes - I overread that that patch is for dynamic files only.
but, as you told me - I added a script tag to the static file that does
nothing and rendering went to less than three seconds compared to the
previous 15 seconds. So, thats much, much better now.
>> The two files take about three seconds to render on my Linux system
>> (2.2 Ghz, 1.5 GB Ram).
>>
>> Furthermore I tested with
>> http://www.carto.net/williams/yosemite/index.svg
>>
>> On MacOSX it takes more than 4 minutes to render (the dynamically
>> loaded map-data), on Linux it takes less than 10 seconds, including
>> loading, script execution and getURL stuff. In this application 4
>> additional map layers are loaded using getURL.
>
>
> Gahh! That is horrible. This map should be using the Dynamic renderer
> so it is unfortunate that it stays so slow. Does this map use Filters?
> Masks? Patterns? I'm just trying to figure out what is causing the
> "regression" in performance.
In the Yosemite map I use symbols, markers. I don't use patterns,
filters and masks. There is a filter definition in the <defs> section,
but it is never applied in Batik. I only use it in ASV, due to a bug
with line-widths on text elements. In ASV I use a filter to produce
"halo" effects around the text elements, but they aren't used in Batik.
The interesting thing with the Yosemite mapping application is, that the
initial map loads and renders quickly (5-10 seconds), but takes awfully
long (several minutes) to render the data received by getURL(). So I
suspect, something weird is going on when rendering the geometry
received by getURL() on MacOSX. Maybe this fact helps you with the
investigations.
> I suspect that mapWaad/Spain is because they are using the old
> 'static' renderer (if this pans out we may have a MacOSX renderer that
> is used for static and dynamic docs). I suspect that something in
> the more complex Yosemite document is causing the raster to be
> fetched... are you using the 'static' patch? that will cause the
> 'static' content to be rendered to a 'raster' which will have the
> 'slow' behavior. I think if you remove any 'batik:static="true"' it
> should avoid this.
no, I don't use the static attribute, and I did not test with a
'static-patched' Squiggle on MacOSX. The only patch I applied is the
"macosx-render.patch".
Andreas
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Andreas Neumann wrote:
> I updated to the latest svn version (trunk) and applied the
> macosx-render.patch file, using 'patch'.
>
> Unfortunately I don't see any improvements, regarding rendering speed.
>
> The rendering speeds are still very, very slow. I tested with the two
> sample maps provided with the Batik distribution:
>
> mapWaadt.svg (contains no raster images and opacity)
> mapSpain.svg (contains raster image and opacity)
>
> both take about 15 seconds to render on my machine (see details below).
These are 'static' files so I'm not surprised the time didn't
change. You can trick Batik into thinking they are dynamic by adding
a script element (even if it does nothing). I'd be curious if this
'fixed' the problem for you.
> The two files take about three seconds to render on my Linux system (2.2
> Ghz, 1.5 GB Ram).
>
> Furthermore I tested with http://www.carto.net/williams/yosemite/index.svg
>
> On MacOSX it takes more than 4 minutes to render (the dynamically loaded
> map-data), on Linux it takes less than 10 seconds, including loading,
> script execution and getURL stuff. In this application 4 additional map
> layers are loaded using getURL.
Gahh! That is horrible. This map should be using the Dynamic renderer
so it is unfortunate that it stays so slow. Does this map use Filters?
Masks? Patterns? I'm just trying to figure out what is causing the
"regression" in performance.
>
> information about my Mac system:
>
> my java-version:
> java version "1.4.2_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232)
> Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)
>
> my system:
> powerbook G4, 1Ghz, 1GB Ram, MacOSX 10.4.2
>
> I wonder what I did different from scott? Is it because I have a G4 and
> scott has a G5? Or because I applied the patch to the trunk (latest
> developer version) instead of the older stable version?
I suspect that mapWaad/Spain is because they are using the old
'static' renderer (if this pans out we may have a MacOSX renderer that
is used for static and dynamic docs). I suspect that something in
the more complex Yosemite document is causing the raster to be
fetched... are you using the 'static' patch? that will cause the
'static' content to be rendered to a 'raster' which will have the
'slow' behavior. I think if you remove any 'batik:static="true"' it
should avoid this.
> Scott A. Ruffner wrote:
>
>> Thomas DeWeese wrote:
>>
>>> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>>>
>>> There are some edge cases that I know the new renderer
>>> doesn't handle but I'm curious if it solves the problem
>>> at all or in any kind of useful percentage of the cases.
>>
>>
>>
>> hi, thomas --
>>
>> i managed to run a few tests before vacation, and your patch
>> fixed the rendering performance slowdown that our app
>> experienced in Mac OSX 10.4.x. here's a summary:
>>
>> MacOSX Batik "doc" "build" "render"
>> 10.3.x 1.5 354 251 8308
>> 10.3.x 1.6 369 245 675 YEA!
>> 10.4.2 1.6 333 214 13637 DARN!
>> 10.4.2 1.6(patch) 277 133 677 WHEW!
>>
>> these results are for complete "refreshes" of the entire
>> document rendered on the JSVGCanvas. unfortunately, when i use the
>> canvas's
>> UpdateManager framework to update the rendering in response
>> to a small change in the SVG document, i will occasionally
>> get awful rendering times (15 seconds or more) on Mac OSX
>> that i don't see in Windows. this is probably a different
>> issue, perhaps thread-related. i'll let you know if i figure
>> it out...
>>
>> thanks again for the patch!
>>
>> scott
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Thomas, Scott and others,
I updated to the latest svn version (trunk) and applied the
macosx-render.patch file, using 'patch'.
Unfortunately I don't see any improvements, regarding rendering speed.
The rendering speeds are still very, very slow. I tested with the two
sample maps provided with the Batik distribution:
mapWaadt.svg (contains no raster images and opacity)
mapSpain.svg (contains raster image and opacity)
both take about 15 seconds to render on my machine (see details below).
The two files take about three seconds to render on my Linux system (2.2
Ghz, 1.5 GB Ram).
Furthermore I tested with http://www.carto.net/williams/yosemite/index.svg
On MacOSX it takes more than 4 minutes to render (the dynamically loaded
map-data), on Linux it takes less than 10 seconds, including loading,
script execution and getURL stuff. In this application 4 additional map
layers are loaded using getURL.
information about my Mac system:
my java-version:
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232)
Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)
my system:
powerbook G4, 1Ghz, 1GB Ram, MacOSX 10.4.2
I wonder what I did different from scott? Is it because I have a G4 and
scott has a G5? Or because I applied the patch to the trunk (latest
developer version) instead of the older stable version?
Andreas
Scott A. Ruffner wrote:
> Thomas DeWeese wrote:
>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>>
>> There are some edge cases that I know the new renderer
>> doesn't handle but I'm curious if it solves the problem
>> at all or in any kind of useful percentage of the cases.
>
>
> hi, thomas --
>
> i managed to run a few tests before vacation, and your patch
> fixed the rendering performance slowdown that our app
> experienced in Mac OSX 10.4.x. here's a summary:
>
> MacOSX Batik "doc" "build" "render"
> 10.3.x 1.5 354 251 8308
> 10.3.x 1.6 369 245 675 YEA!
> 10.4.2 1.6 333 214 13637 DARN!
> 10.4.2 1.6(patch) 277 133 677 WHEW!
>
> these results are for complete "refreshes" of the entire
> document rendered on the JSVGCanvas. unfortunately, when i use the
> canvas's
> UpdateManager framework to update the rendering in response
> to a small change in the SVG document, i will occasionally
> get awful rendering times (15 seconds or more) on Mac OSX
> that i don't see in Windows. this is probably a different
> issue, perhaps thread-related. i'll let you know if i figure
> it out...
>
> thanks again for the patch!
>
> scott
>
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
Thomas DeWeese wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>
> There are some edge cases that I know the new renderer
> doesn't handle but I'm curious if it solves the problem
> at all or in any kind of useful percentage of the cases.
hi, thomas --
i managed to run a few tests before vacation, and your patch
fixed the rendering performance slowdown that our app
experienced in Mac OSX 10.4.x. here's a summary:
MacOSX Batik "doc" "build" "render"
10.3.x 1.5 354 251 8308
10.3.x 1.6 369 245 675 YEA!
10.4.2 1.6 333 214 13637 DARN!
10.4.2 1.6(patch) 277 133 677 WHEW!
these results are for complete "refreshes" of the entire
document rendered on the JSVGCanvas. unfortunately, when i use the canvas's
UpdateManager framework to update the rendering in response
to a small change in the SVG document, i will occasionally
get awful rendering times (15 seconds or more) on Mac OSX
that i don't see in Windows. this is probably a different
issue, perhaps thread-related. i'll let you know if i figure
it out...
thanks again for the patch!
scott
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: Applet way too slow on MAC
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
Thanks Thomas,
I just tried the patch file and my app rendering works much faster than
before.
OS: Tiger
G5 processor.
Thanks a lot,
Javid
-----Original Message-----
From: Scott Ruffner [mailto:sruffner@phy.ucsf.edu]
Sent: Thursday, September 22, 2005 10:52 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Applet way too slow on MAC
Many thanks, Thomas. I only wish Apple was as responsive
as you!... I will be out of the office for a week or so, but I'll
give it a try as soon as I return.
thanks again!
Scott Ruffner
----- Original Message -----
From: "Thomas DeWeese" <Th...@Kodak.com>
To: <ba...@xmlgraphics.apache.org>
Sent: Thursday, September 22, 2005 4:46 AM
Subject: Re: Applet way too slow on MAC
> Hi Andreas, Scott,
>
> I have created a new bug in Bugzilla to track this issue.
> I have also created a patch that replaced the current
> DynamicRenderer with one that doesn't touch the underlying
> raster data. This should in theory solve the problem for
> you on tiger. Since I don't have a Tiger system to check
> you will have to try it for me:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>
> There are some edge cases that I know the new renderer
> doesn't handle but I'm curious if it solves the problem
> at all or in any kind of useful percentage of the cases.
>
> Andreas Neumann wrote:
> > This issue is really annoying. I remember that the performance was much
> > better on Panther using the different color model as described in
> >
> >
http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200508.mbox
/%3c42FA4DA8.3050104@phy.ucsf.edu%3e
> >
> >
> > Too bad, to discover that it's slow again on Tiger ...
> >
> > It would really help if the apple engineers could work on that issue.
> >
> > Andreas
> >
> > Thomas DeWeese wrote:
> >
> >> Hi Scott,
> >>
> >>> Thomas DeWeese wrote:
> >>
> >>
> >>
> >>>> I just noticed Apple released a Java 1.3/1.4 update for
> >>>> Tiger. Can you check if this fixes the problem?
> >>>
> >>>
> >>
> >> Scott A. Ruffner wrote:
> >>
> >>> i just installed the Java update on my Powerbook, and it
> >>> made no difference in performance -- it's still 20x slower
> >>> than under Panther 10.3.9. :(
> >>
> >>
> >>
> >> Too bad.
> >>
> >>> thomas, is there any chance you'll be able to revise how batik
> >>> uses BufferedImage/WritableRaster to avoid this performance hit?
> >>
> >>
> >>
> >> There is essentially no way to fix this in all of Batik.
> >> Much of Batik is built around the java.awt.image.RenderedImage
> >> interface. In this interface an image is composed of tiles which
> >> are rasters, so you basically can't avoid touching the rasters that
> >> are used to build BufferedImages for rendering.
> >>
> >> There is some chance that the use of Rasters/RenderedImages
> >> might be avoided in the 'DynamicRenderer' which would help for
> >> simple things but I think that you would find that most content
> >> would 'trip' over the raster access.
> >>
> >> ---------------------------------------------------------------------
> >> 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: Applet way too slow on MAC
Posted by Scott Ruffner <sr...@phy.ucsf.edu>.
Many thanks, Thomas. I only wish Apple was as responsive
as you!... I will be out of the office for a week or so, but I'll
give it a try as soon as I return.
thanks again!
Scott Ruffner
----- Original Message -----
From: "Thomas DeWeese" <Th...@Kodak.com>
To: <ba...@xmlgraphics.apache.org>
Sent: Thursday, September 22, 2005 4:46 AM
Subject: Re: Applet way too slow on MAC
> Hi Andreas, Scott,
>
> I have created a new bug in Bugzilla to track this issue.
> I have also created a patch that replaced the current
> DynamicRenderer with one that doesn't touch the underlying
> raster data. This should in theory solve the problem for
> you on tiger. Since I don't have a Tiger system to check
> you will have to try it for me:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
>
> There are some edge cases that I know the new renderer
> doesn't handle but I'm curious if it solves the problem
> at all or in any kind of useful percentage of the cases.
>
> Andreas Neumann wrote:
> > This issue is really annoying. I remember that the performance was much
> > better on Panther using the different color model as described in
> >
> >
http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200508.mbox/%3c42FA4DA8.3050104@phy.ucsf.edu%3e
> >
> >
> > Too bad, to discover that it's slow again on Tiger ...
> >
> > It would really help if the apple engineers could work on that issue.
> >
> > Andreas
> >
> > Thomas DeWeese wrote:
> >
> >> Hi Scott,
> >>
> >>> Thomas DeWeese wrote:
> >>
> >>
> >>
> >>>> I just noticed Apple released a Java 1.3/1.4 update for
> >>>> Tiger. Can you check if this fixes the problem?
> >>>
> >>>
> >>
> >> Scott A. Ruffner wrote:
> >>
> >>> i just installed the Java update on my Powerbook, and it
> >>> made no difference in performance -- it's still 20x slower
> >>> than under Panther 10.3.9. :(
> >>
> >>
> >>
> >> Too bad.
> >>
> >>> thomas, is there any chance you'll be able to revise how batik
> >>> uses BufferedImage/WritableRaster to avoid this performance hit?
> >>
> >>
> >>
> >> There is essentially no way to fix this in all of Batik.
> >> Much of Batik is built around the java.awt.image.RenderedImage
> >> interface. In this interface an image is composed of tiles which
> >> are rasters, so you basically can't avoid touching the rasters that
> >> are used to build BufferedImages for rendering.
> >>
> >> There is some chance that the use of Rasters/RenderedImages
> >> might be avoided in the 'DynamicRenderer' which would help for
> >> simple things but I think that you would find that most content
> >> would 'trip' over the raster access.
> >>
> >> ---------------------------------------------------------------------
> >> 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: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Andreas, Scott,
I have created a new bug in Bugzilla to track this issue.
I have also created a patch that replaced the current
DynamicRenderer with one that doesn't touch the underlying
raster data. This should in theory solve the problem for
you on tiger. Since I don't have a Tiger system to check
you will have to try it for me:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36769
There are some edge cases that I know the new renderer
doesn't handle but I'm curious if it solves the problem
at all or in any kind of useful percentage of the cases.
Andreas Neumann wrote:
> This issue is really annoying. I remember that the performance was much
> better on Panther using the different color model as described in
>
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200508.mbox/%3c42FA4DA8.3050104@phy.ucsf.edu%3e
>
>
> Too bad, to discover that it's slow again on Tiger ...
>
> It would really help if the apple engineers could work on that issue.
>
> Andreas
>
> Thomas DeWeese wrote:
>
>> Hi Scott,
>>
>>> Thomas DeWeese wrote:
>>
>>
>>
>>>> I just noticed Apple released a Java 1.3/1.4 update for
>>>> Tiger. Can you check if this fixes the problem?
>>>
>>>
>>
>> Scott A. Ruffner wrote:
>>
>>> i just installed the Java update on my Powerbook, and it
>>> made no difference in performance -- it's still 20x slower
>>> than under Panther 10.3.9. :(
>>
>>
>>
>> Too bad.
>>
>>> thomas, is there any chance you'll be able to revise how batik
>>> uses BufferedImage/WritableRaster to avoid this performance hit?
>>
>>
>>
>> There is essentially no way to fix this in all of Batik.
>> Much of Batik is built around the java.awt.image.RenderedImage
>> interface. In this interface an image is composed of tiles which
>> are rasters, so you basically can't avoid touching the rasters that
>> are used to build BufferedImages for rendering.
>>
>> There is some chance that the use of Rasters/RenderedImages
>> might be avoided in the 'DynamicRenderer' which would help for
>> simple things but I think that you would find that most content
>> would 'trip' over the raster access.
>>
>> ---------------------------------------------------------------------
>> 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: Applet way too slow on MAC
Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
This issue is really annoying. I remember that the performance was much
better on Panther using the different color model as described in
http://mail-archives.apache.org/mod_mbox/xmlgraphics-batik-users/200508.mbox/%3c42FA4DA8.3050104@phy.ucsf.edu%3e
Too bad, to discover that it's slow again on Tiger ...
It would really help if the apple engineers could work on that issue.
Andreas
Thomas DeWeese wrote:
> Hi Scott,
>
>> Thomas DeWeese wrote:
>
>
>>> I just noticed Apple released a Java 1.3/1.4 update for
>>> Tiger. Can you check if this fixes the problem?
>>
>
> Scott A. Ruffner wrote:
>
>> i just installed the Java update on my Powerbook, and it
>> made no difference in performance -- it's still 20x slower
>> than under Panther 10.3.9. :(
>
>
> Too bad.
>
>> thomas, is there any chance you'll be able to revise how batik
>> uses BufferedImage/WritableRaster to avoid this performance hit?
>
>
> There is essentially no way to fix this in all of Batik.
> Much of Batik is built around the java.awt.image.RenderedImage
> interface. In this interface an image is composed of tiles which
> are rasters, so you basically can't avoid touching the rasters that
> are used to build BufferedImages for rendering.
>
> There is some chance that the use of Rasters/RenderedImages
> might be avoided in the 'DynamicRenderer' which would help for
> simple things but I think that you would find that most content
> would 'trip' over the raster access.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
--
----------------------------------------------
Andreas Neumann - Institute of Cartography
Swiss Federal Institute of Technology (ETH)
ETH Hoenggerberg
CH-8093 Zurich, Switzerland
Phone: ++41-1-633 3031, Fax: ++41-1-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Scott,
> Thomas DeWeese wrote:
>> I just noticed Apple released a Java 1.3/1.4 update for
>> Tiger. Can you check if this fixes the problem?
Scott A. Ruffner wrote:
> i just installed the Java update on my Powerbook, and it
> made no difference in performance -- it's still 20x slower
> than under Panther 10.3.9. :(
Too bad.
> thomas, is there any chance you'll be able to revise how batik
> uses BufferedImage/WritableRaster to avoid this performance hit?
There is essentially no way to fix this in all of Batik.
Much of Batik is built around the java.awt.image.RenderedImage
interface. In this interface an image is composed of tiles which
are rasters, so you basically can't avoid touching the rasters that
are used to build BufferedImages for rendering.
There is some chance that the use of Rasters/RenderedImages
might be avoided in the 'DynamicRenderer' which would help for
simple things but I think that you would find that most content
would 'trip' over the raster access.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
Thomas DeWeese wrote:
> Hi Scott,
>
> I just noticed Apple released a Java 1.3/1.4 update for
> Tiger. Can you check if this fixes the problem?
>
hi, thomas --
i just installed the Java update on my Powerbook, and it
made no difference in performance -- it's still 20x slower
than under Panther 10.3.9. :(
here's yet another thread from apple's java-dev mailing list that
rehashes the same topic:
http://lists.apple.com/archives/java-dev/2005/Aug/msg00381.html.
an apple java-dev thread posted in may 05 indicated that an apple
engineer admitted that their implementation of BufferedImage
in Tiger is wanting. but i cannot find any information about
whether and when they might provide a fix. if there's an apple
engineer on this mailing list (or a friend of an apple engineer!),
any chance of providing this information?!
thomas, is there any chance you'll be able to revise how batik
uses BufferedImage/WritableRaster to avoid this performance hit?
thanks,
scott
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Scott,
I just noticed Apple released a Java 1.3/1.4 update for
Tiger. Can you check if this fixes the problem?
Scott A. Ruffner wrote:
> Thomas DeWeese wrote:
>
>> Hi Scott,
>>
>> Good find. I suspect this is the issue.
>> I haven't finished reading the whole thread,
>> I'll look to see if it would be easy for Batik
>> to avoid requesting the raster data (but I
>> am not hopeful).
>>
>
> again, i hope Apple is doing something about it.
> here's another thread in the Apple java-dev mailing
> list.
>
> http://lists.apple.com/archives/Java-dev/2005/Jul/msg00009.html
>
> one response succinctly describes the problem
> and some of the other emails address possible
> workarounds (which i don't entirely follow!)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
Thomas DeWeese wrote:
> Hi Scott,
>
> Good find. I suspect this is the issue.
> I haven't finished reading the whole thread,
> I'll look to see if it would be easy for Batik
> to avoid requesting the raster data (but I
> am not hopeful).
>
again, i hope Apple is doing something about it.
here's another thread in the Apple java-dev mailing
list.
http://lists.apple.com/archives/Java-dev/2005/Jul/msg00009.html
one response succinctly describes the problem
and some of the other emails address possible
workarounds (which i don't entirely follow!)
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Scott,
Good find. I suspect this is the issue.
I haven't finished reading the whole thread,
I'll look to see if it would be easy for Batik
to avoid requesting the raster data (but I
am not hopeful).
Scott A. Ruffner wrote:
> after a lot more surfing Mac OSX/Java mailing lists,
> i came across this tidbit on apple's java-dev list.
> i think it might address the drastic rendering
> slowdown on OSX 10.4.2. it's worth a read:
>
> http://lists.apple.com/archives/java-dev/2005/May/msg00498.html
>
> there are plenty of calls to Raster.getDataBuffer() in
> Batik, so perhaps this is the problem??
>
> i did some further profiling of my app, and indeed:
> 59.6% of CPU time is in __memcpy(), all of which can
> be traced back to calls to either "syncFromJavaPixels"
> or "syncToJavaPixels" in the Apple library libawt.jnilib.
>
> hopefully, Apple is going to address this problem soon
> (the author of the above list entry kind of intimated
> this might be the case...)... any thoughts?
>
> scott
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
hi, thomas, et al. --
after a lot more surfing Mac OSX/Java mailing lists,
i came across this tidbit on apple's java-dev list.
i think it might address the drastic rendering
slowdown on OSX 10.4.2. it's worth a read:
http://lists.apple.com/archives/java-dev/2005/May/msg00498.html
there are plenty of calls to Raster.getDataBuffer() in
Batik, so perhaps this is the problem??
i did some further profiling of my app, and indeed:
59.6% of CPU time is in __memcpy(), all of which can
be traced back to calls to either "syncFromJavaPixels"
or "syncToJavaPixels" in the Apple library libawt.jnilib.
hopefully, Apple is going to address this problem soon
(the author of the above list entry kind of intimated
this might be the case...)... any thoughts?
scott
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
Hi, Thomas --
I haven't tried your suggestions yet, but
thanks....
here are a few numbers for rendering a
figure (with lots of lines, simple shapes,
and text) to a JSVGCanvas in my application
running on a Powerbook G4, 800MHz, 1G SDRAM
(times in ms):
MacOSX Batik "doc" "build" "render"
10.3.x 1.5 354 251 8308
10.3.x 1.6 369 245 675 YEA!
10.4.2 1.6 333 214 13637 DARN!
I did try to profile my application running
on MacOSX 10.4.2 (Powerbook G4, 800MHz, 1G SDRAM)
using Shark. Unfortunately, I haven't been able
to get Shark to lookup symbols in my app yet, but
I found that during rendering, much of the CPU
time is spent in calls to __memcpy() in the
commpage library, and most of the calls were made
from CGBlt_copyBytes() in Apple's CoreGraphics
library... doubt if that helps at all, but maybe
it will light some bulb out there somewhere...
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi Scott,
Scott A. Ruffner wrote:
> has anyone made any progress on this issue -- Batik
> rendering very slowly on Mac OSX 10.4.2? any
> suggestions are welcome.
It occurred to me that they might want an either a BGR
style image, or a component image (instead of a packed image).
If you know a bit about Java2D you should be able to construct
such a ColorModel (the first is a DirectColorModel with a
different set of masks), the second is a ComponentColorModel.
There is also some small chance that they will only drop
into the really fast case if the ColorModel is '==' to the
ColorModel that a BufferedImage of the appropriate type
uses.
You might also poke at and dump the contents of the
GraphicsEnvironment (get all the screenDevices, get
either 'defaultConfiguration' or all configurations
(or best with alpha) and get the ColorModel from that.
I was thinking that Batik should really defer some of this
stuff to a UserAgent type class so it's more easily configured.
In the past we had to be very careful about what we used due to
fairly pervasive Alpha handling bugs in the JDK. A little
bit of testing has shown that some of these still exist but
it still might be nice to allow for configuration here.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
Javid Alimohideen wrote:
> Thomas,
> I ran the tests you had mentioned on a Mac OSX 10.4.2 G5 2.5 GHz Dual
> Processor, 4 GB SDRAM DDR.
> Here are the results (for my SVG document in seconds):
>
> Mac:
> Linear_sRGB_Pre :12
> Linear_sRGB_Unpre : 37
> sRGB_Pre :12
> sRGB_Unpre: 37
> sRGB : Throws some exception.
> Linear_sRGB: Throws exception
>
> Java : 1.4.2_07
> Batik: SVN Nightly build dated 05-07-13
>
>
has anyone made any progress on this issue -- Batik
rendering very slowly on Mac OSX 10.4.2? any
suggestions are welcome.
thanks!
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
RE: Applet way too slow on MAC
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
Thomas,
I ran the tests you had mentioned on a Mac OSX 10.4.2 G5 2.5 GHz Dual
Processor, 4 GB SDRAM DDR.
Here are the results (for my SVG document in seconds):
Mac:
Linear_sRGB_Pre :12
Linear_sRGB_Unpre : 37
sRGB_Pre :12
sRGB_Unpre: 37
sRGB : Throws some exception.
Linear_sRGB: Throws exception
Java : 1.4.2_07
Batik: SVN Nightly build dated 05-07-13
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: Friday, July 15, 2005 5:18 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Applet way too slow on MAC
Hi all,
Could someone who has 10.4 rerun Steven's tests?
http://koala.ilog.fr/batik/mlists/batik-users/archives/msg06976.html
The class in question is org.apache.batik.gvt.filter.GraphicsNodeRed8Bit
and report back results? I still only have access to
Mac OS 10.3. Also I noticed the following on a message board that
people might try (although I'm unsure how one would use them in
an applet):
From: http://lists.apple.com/archives/Java-dev/2005/Apr/msg00578.html
Note Quartz 2D Extreme is turned off by default in 10.4 (not just for
Java) however one can use Quartz Debug to enable it.
---
apple.awt.graphics.EnableQ2DX
Quartz 2D acceleration is a feature included in Mac OS X v.10.4 for
development purposes. It uses hardware acceleration to speed up
rendering of simple primitives like images, lines, rects, and simple
characters.
---
apple.awt.graphics.EnableDeferredUpdates
Mac OS X v.10.4 uses deferred drawing updates, which eliminates visual
tearing, but blocks those applications that flush too often.
Scott A. Ruffner wrote:
> i was writing to suggest that you try 10.3.9,
> and i just saw your last post!
>
> we've observed a substantial slowdown in rendering
> performance with our Batik-based Java application
> when running under 10.4.0 vs 10.3.9. (sorry, no
> stats to offer, but the slowdown was so bad that
> we decided to stick with 10.3.9 for now). i'm no
> mac guru, but i understand that 10.4 includes some
> major changes to how OSX does graphics...
>
> is anyone else out there running 10.4.x and NOT
> seeing a performance degradation?
>
> sincerely,
>
---------------------------------------------------------------------
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: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi all,
Could someone who has 10.4 rerun Steven's tests?
http://koala.ilog.fr/batik/mlists/batik-users/archives/msg06976.html
The class in question is org.apache.batik.gvt.filter.GraphicsNodeRed8Bit
and report back results? I still only have access to
Mac OS 10.3. Also I noticed the following on a message board that
people might try (although I'm unsure how one would use them in
an applet):
From: http://lists.apple.com/archives/Java-dev/2005/Apr/msg00578.html
Note Quartz 2D Extreme is turned off by default in 10.4 (not just for
Java) however one can use Quartz Debug to enable it.
---
apple.awt.graphics.EnableQ2DX
Quartz 2D acceleration is a feature included in Mac OS X v.10.4 for
development purposes. It uses hardware acceleration to speed up
rendering of simple primitives like images, lines, rects, and simple
characters.
---
apple.awt.graphics.EnableDeferredUpdates
Mac OS X v.10.4 uses deferred drawing updates, which eliminates visual
tearing, but blocks those applications that flush too often.
Scott A. Ruffner wrote:
> i was writing to suggest that you try 10.3.9,
> and i just saw your last post!
>
> we've observed a substantial slowdown in rendering
> performance with our Batik-based Java application
> when running under 10.4.0 vs 10.3.9. (sorry, no
> stats to offer, but the slowdown was so bad that
> we decided to stick with 10.3.9 for now). i'm no
> mac guru, but i understand that 10.4 includes some
> major changes to how OSX does graphics...
>
> is anyone else out there running 10.4.x and NOT
> seeing a performance degradation?
>
> sincerely,
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Applet way too slow on MAC
Posted by "Scott A. Ruffner" <sr...@phy.ucsf.edu>.
hi, javid --
i was writing to suggest that you try 10.3.9,
and i just saw your last post!
we've observed a substantial slowdown in rendering
performance with our Batik-based Java application
when running under 10.4.0 vs 10.3.9. (sorry, no
stats to offer, but the slowdown was so bad that
we decided to stick with 10.3.9 for now). i'm no
mac guru, but i understand that 10.4 includes some
major changes to how OSX does graphics...
is anyone else out there running 10.4.x and NOT
seeing a performance degradation?
sincerely,
--
Scott A. Ruffner, Scientific Programmer/Analyst
Lisberger Lab
W.M. Keck Foundation Center for Integrative Neuroscience
University of California -- San Francisco
513 Parnassus Avenue, Box 0444, S871
San Francisco, CA 94143-0444
415-502-7897
Javid Alimohideen wrote:
>
> Hi Thomas,
> Thanks for your suggestions.
> I opened the SVG document with squiggle and rendering time is between 10-15
> secs (still slow for users) on a Mac OS 10.4.2 G5 Dual processor (with both
> filters on and off). With Adobe plug-in approx. 2 seconds.
>
> you can take a look at the document here
> http://users.lac.uic.edu/~javid/newMap/data/demo-map.svg
>
> 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: Thursday, July 14, 2005 8:19 AM
> To: batik-users@xmlgraphics.apache.org
> Subject: Re: Applet way too slow on MAC
>
> Javid Alimohideen wrote:
> > No luck. i tried the latest nightly build of Batik and the performance is
> > still the same. It takes on average like 25 seconds to render the svg
> image.
> > Any suggestions are welcome.
>
> One thing would be to try removing all use of filters in your
> document.
>
> > I really need to improve the performace as the
> > whole aim of my project was to make it browser and OS independent.
> > A working demo is available.
>
> Can you 'extract' the SVG document so it can be tested in just
> the Squiggle browser more easily?
>
> > http://users.lac.uic.edu/~javid/testMap/traffic.html
> >
> > Note: Applet hangs when user tries to hit refresh button.
>
> I know very little about applets so I don't know what would
> cause this. Can you get a stack trace/thread dump? Can you
> look at the Java console?
>
> > -----Original Message-----
> > From: Tonny Kohar [mailto:tonny@kiyut.com]
> > Sent: Wednesday, July 13, 2005 1:11 PM
> > To: batik-users@xmlgraphics.apache.org
> > Subject: Re: Applet way too slow on MAC
> >
> >
> > Hi,
> >
> > On Wed, 2005-07-13 at 11:00 -0500, Javid Alimohideen wrote:
> >
> >>Hi,
> >>I successfully finished writing my applet to view and interact with SVG. I
> >>have two problems now.
> >>1. Applet hangs when trying to hit refresh button on the browser (all
> >>browsers and OS).
> >>2. SVG takes way too much time to build and render on Mac. (Safari browser
> >>on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
> >>
> >>Can someone tell what i could be doing wrong?
> >
> >
> > This may not help you at all. But since Batik 1.6 or 1.5.? (I forgot)
> > have special Mac Speedup fix in the way Batik handle its image buffer.
> > It change the image buffer type, if it detect Mac.
> >
> > If you are not using recent version of Batik, just try the latest build
> > to see if it is improve the rendering performance.
> >
> > Regards
> > Tonny Kohar
> > --
> > Sketsa
> > SVG Graphics Editor
> > http://www.kiyut.com
> >
> >
> > ---------------------------------------------------------------------
> > 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: Applet way too slow on MAC
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
Hi Thomas,
Thanks for your suggestions.
I opened the SVG document with squiggle and rendering time is between 10-15
secs (still slow for users) on a Mac OS 10.4.2 G5 Dual processor (with both
filters on and off). With Adobe plug-in approx. 2 seconds.
you can take a look at the document here
http://users.lac.uic.edu/~javid/newMap/data/demo-map.svg
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: Thursday, July 14, 2005 8:19 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Applet way too slow on MAC
Javid Alimohideen wrote:
> No luck. i tried the latest nightly build of Batik and the performance is
> still the same. It takes on average like 25 seconds to render the svg
image.
> Any suggestions are welcome.
One thing would be to try removing all use of filters in your
document.
> I really need to improve the performace as the
> whole aim of my project was to make it browser and OS independent.
> A working demo is available.
Can you 'extract' the SVG document so it can be tested in just
the Squiggle browser more easily?
> http://users.lac.uic.edu/~javid/testMap/traffic.html
>
> Note: Applet hangs when user tries to hit refresh button.
I know very little about applets so I don't know what would
cause this. Can you get a stack trace/thread dump? Can you
look at the Java console?
> -----Original Message-----
> From: Tonny Kohar [mailto:tonny@kiyut.com]
> Sent: Wednesday, July 13, 2005 1:11 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: Re: Applet way too slow on MAC
>
>
> Hi,
>
> On Wed, 2005-07-13 at 11:00 -0500, Javid Alimohideen wrote:
>
>>Hi,
>>I successfully finished writing my applet to view and interact with SVG. I
>>have two problems now.
>>1. Applet hangs when trying to hit refresh button on the browser (all
>>browsers and OS).
>>2. SVG takes way too much time to build and render on Mac. (Safari browser
>>on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
>>
>>Can someone tell what i could be doing wrong?
>
>
> This may not help you at all. But since Batik 1.6 or 1.5.? (I forgot)
> have special Mac Speedup fix in the way Batik handle its image buffer.
> It change the image buffer type, if it detect Mac.
>
> If you are not using recent version of Batik, just try the latest build
> to see if it is improve the rendering performance.
>
> Regards
> Tonny Kohar
> --
> Sketsa
> SVG Graphics Editor
> http://www.kiyut.com
>
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC (but not on 10.3.9)
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
Hi,
I just found out that viewing my applet on Mac OS X 10.3.9 is much faster (3
seconds) than on a Mac with OS X 10.4.2 (14 seconds). I am using Batik-1.6
and trying to view with Safari browser on both the Mac.
It seems very strange to me..
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: Thursday, July 14, 2005 8:19 AM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Applet way too slow on MAC
Javid Alimohideen wrote:
> No luck. i tried the latest nightly build of Batik and the performance is
> still the same. It takes on average like 25 seconds to render the svg
image.
> Any suggestions are welcome.
One thing would be to try removing all use of filters in your
document.
> I really need to improve the performace as the
> whole aim of my project was to make it browser and OS independent.
> A working demo is available.
Can you 'extract' the SVG document so it can be tested in just
the Squiggle browser more easily?
> http://users.lac.uic.edu/~javid/testMap/traffic.html
>
> Note: Applet hangs when user tries to hit refresh button.
I know very little about applets so I don't know what would
cause this. Can you get a stack trace/thread dump? Can you
look at the Java console?
> -----Original Message-----
> From: Tonny Kohar [mailto:tonny@kiyut.com]
> Sent: Wednesday, July 13, 2005 1:11 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: Re: Applet way too slow on MAC
>
>
> Hi,
>
> On Wed, 2005-07-13 at 11:00 -0500, Javid Alimohideen wrote:
>
>>Hi,
>>I successfully finished writing my applet to view and interact with SVG. I
>>have two problems now.
>>1. Applet hangs when trying to hit refresh button on the browser (all
>>browsers and OS).
>>2. SVG takes way too much time to build and render on Mac. (Safari browser
>>on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
>>
>>Can someone tell what i could be doing wrong?
>
>
> This may not help you at all. But since Batik 1.6 or 1.5.? (I forgot)
> have special Mac Speedup fix in the way Batik handle its image buffer.
> It change the image buffer type, if it detect Mac.
>
> If you are not using recent version of Batik, just try the latest build
> to see if it is improve the rendering performance.
>
> Regards
> Tonny Kohar
> --
> Sketsa
> SVG Graphics Editor
> http://www.kiyut.com
>
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC
Posted by Thomas DeWeese <Th...@Kodak.com>.
Javid Alimohideen wrote:
> No luck. i tried the latest nightly build of Batik and the performance is
> still the same. It takes on average like 25 seconds to render the svg image.
> Any suggestions are welcome.
One thing would be to try removing all use of filters in your
document.
> I really need to improve the performace as the
> whole aim of my project was to make it browser and OS independent.
> A working demo is available.
Can you 'extract' the SVG document so it can be tested in just
the Squiggle browser more easily?
> http://users.lac.uic.edu/~javid/testMap/traffic.html
>
> Note: Applet hangs when user tries to hit refresh button.
I know very little about applets so I don't know what would
cause this. Can you get a stack trace/thread dump? Can you
look at the Java console?
> -----Original Message-----
> From: Tonny Kohar [mailto:tonny@kiyut.com]
> Sent: Wednesday, July 13, 2005 1:11 PM
> To: batik-users@xmlgraphics.apache.org
> Subject: Re: Applet way too slow on MAC
>
>
> Hi,
>
> On Wed, 2005-07-13 at 11:00 -0500, Javid Alimohideen wrote:
>
>>Hi,
>>I successfully finished writing my applet to view and interact with SVG. I
>>have two problems now.
>>1. Applet hangs when trying to hit refresh button on the browser (all
>>browsers and OS).
>>2. SVG takes way too much time to build and render on Mac. (Safari browser
>>on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
>>
>>Can someone tell what i could be doing wrong?
>
>
> This may not help you at all. But since Batik 1.6 or 1.5.? (I forgot)
> have special Mac Speedup fix in the way Batik handle its image buffer.
> It change the image buffer type, if it detect Mac.
>
> If you are not using recent version of Batik, just try the latest build
> to see if it is improve the rendering performance.
>
> Regards
> Tonny Kohar
> --
> Sketsa
> SVG Graphics Editor
> http://www.kiyut.com
>
>
> ---------------------------------------------------------------------
> 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: Applet way too slow on MAC
Posted by Javid Alimohideen <ja...@evl.uic.edu>.
No luck. i tried the latest nightly build of Batik and the performance is
still the same. It takes on average like 25 seconds to render the svg image.
Any suggestions are welcome. I really need to improve the performace as the
whole aim of my project was to make it browser and OS independent.
A working demo is available.
http://users.lac.uic.edu/~javid/testMap/traffic.html
Note: Applet hangs when user tries to hit refresh button.
Thanks,
Javid
A clever person solves a problem.
A wise person avoids it.
-- Einstein
-----Original Message-----
From: Tonny Kohar [mailto:tonny@kiyut.com]
Sent: Wednesday, July 13, 2005 1:11 PM
To: batik-users@xmlgraphics.apache.org
Subject: Re: Applet way too slow on MAC
Hi,
On Wed, 2005-07-13 at 11:00 -0500, Javid Alimohideen wrote:
> Hi,
> I successfully finished writing my applet to view and interact with SVG. I
> have two problems now.
> 1. Applet hangs when trying to hit refresh button on the browser (all
> browsers and OS).
> 2. SVG takes way too much time to build and render on Mac. (Safari browser
> on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
>
> Can someone tell what i could be doing wrong?
This may not help you at all. But since Batik 1.6 or 1.5.? (I forgot)
have special Mac Speedup fix in the way Batik handle its image buffer.
It change the image buffer type, if it detect Mac.
If you are not using recent version of Batik, just try the latest build
to see if it is improve the rendering performance.
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
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: Applet way too slow on MAC
Posted by Tonny Kohar <to...@kiyut.com>.
Hi,
On Wed, 2005-07-13 at 11:00 -0500, Javid Alimohideen wrote:
> Hi,
> I successfully finished writing my applet to view and interact with SVG. I
> have two problems now.
> 1. Applet hangs when trying to hit refresh button on the browser (all
> browsers and OS).
> 2. SVG takes way too much time to build and render on Mac. (Safari browser
> on Mac OS). It takes ~2 sec on Windows and Linux and ~45 sec on Mac.
>
> Can someone tell what i could be doing wrong?
This may not help you at all. But since Batik 1.6 or 1.5.? (I forgot)
have special Mac Speedup fix in the way Batik handle its image buffer.
It change the image buffer type, if it detect Mac.
If you are not using recent version of Batik, just try the latest build
to see if it is improve the rendering performance.
Regards
Tonny Kohar
--
Sketsa
SVG Graphics Editor
http://www.kiyut.com
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org