xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DeWeese <Thomas.DeWe...@Kodak.com>
Subject Re: Batik Performance Questions
Date Tue, 08 Feb 2005 19:50:44 GMT
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: batik-users-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
>> For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org


Mime
View raw message