Hi Steven,
Steven Huey wrote:
I checked out the Batik sources from CVS and changed line 90 that reads:
ColorModel cm = GraphicsUtil.sRGB_Unpre;
so that it would use the Linear_sRGB ColorModel, recompiled, and re-ran my tests.I repeated this process for the Linear_sRGB_Pre, Linear_sRGB_Unpre, sRGB, sRGB_Pre, and sRGB_Unpre.
Great! Thanks for taking the time to provide the data.
= PowerBook = sRGB_Pre: 2.828 sRGB_Unpre: 133.748
That's pretty impressive :)
= Dell Workstation = sRGB_Pre: 1.328 sRGB_Unpre: 1.359
With that in mind, I've got two more questions:
1. Are there any advantages / disadvantages to the various models?
Yes, although the details would take a long time to explain. The difference between Pre/Unpre is that for Pre the color channels are premultiplied with the alpha channel, this tends to be good for drawing graphics but can have some issues with accuracy in filters. Unpre is the same except the alpha channel is not premultiplied into the color channels. The linear one's use a linear color space instead of gamma corrected, this means the calculations are more accurate but 8bits really isn't quite enough precision for linear data.
2. Why is sRGB_Unpre selected as the default?
This is complex, there used to be lots of 'gotchas' in Java2D (but this was mostly back with JDK 1.2), so it is entirely possible that it was chosen as the least bug prone choice (which makes me nervous to change it), and on Unix and windows the performance difference was negligible. Obviously, the above means that this should probably change I'll look at changing it and see what breaks.
On Feb 7, 2005, at 9:13 PM, Thomas DeWeese wrote:
Hi Steven,
Yes, I've been aware that drawing on Mac OS X is much slower although I must admit that I am very surprised at the difference you are seeing (although the example seems to be a fairly extreme one).
The first thing I would try is adjusting the format of the Buffered Image created by batik.gvt.filter.GraphicsNodeRed8Bit It is entirely possible that the format of the image used by it currently is poorly supported by Mac OS X.
Steven Huey wrote:
I ran some tests using a modified version of the SVGApplication found online at http://xml.apache.org/batik/svgcanvas.html . I've basically added a few calls to System.currentTimeMillis() in the three listeners at the end of the class to determine how long various operations are taking.
The two machines I'm working with and comparing performance on are:
Apple PowerBook - G4 1GHZ, 1GB RAM, ATI Mobility 9000 64MB
Dell Workstation - P4 2.8GHz, 1GB RAM, NVidia Quadro FX 500 128MB
I'm loading a compressed SVG document that is 677k compressed and 2MB uncompressed.
Here are the results (all times in seconds):
= PowerBook =
Load Document: 10.762
Build GVT Tree: 7.371
Prepare to Render: 8.912
Render: 112.147
= Dell Workstation =
Load Document: 7.234
Build GVT Tree: 2.016
Prepare to Render: 4.266
Render: 2.672
I was using the latest versions J2SE 1.4 for OS X and Windows when running these tests.
I can understand the difference in load times being down to the slower 4200RPM hard drive in the PowerBook, and the build and perhaps the rendering preparation times being attributed to the performance advantage of the P4 over the G4, however I'm curious to know if the drastic difference in rendering time is due to the better video hardware of the Dell Workstation, the P4, Java 2D performance on Windows vs. OS X, or is it perhaps a combination of all three? I'm somewhat new to Batik so I was hoping that someone with more experience could lend some insight? If you need any more information please let me know.
Thanks.
Steven Huey
--
Steven Huey
Sparta, Inc. - Senior Design Analyst
570.233.0005
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
