xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject Re: batik viewer speed
Date Wed, 02 Jan 2002 13:46:58 GMT
>>>>> "TK" == Thierry Kormann <tkormann@ilog.fr> writes:

TK> On Tuesday 25 December 2001 21:16, Yusuf Saib wrote:
>> Hi all. Why does it take so long for Batik to draw stuff?
>> 
>> For example, MathMetal.svg in the sample directory. It's only 30k
>> in size and it takes my 750MHz PC 12 seconds before it draws it,
>> while the status bar says "Rendering internal tree".

TK> MathMetal is a complex svg file with filter effects. The intensive
TK> use of filter effects (like in this example or bookOfKells) gives
TK> some awesome results on the screen but may slow down the
TK> performance.

    The file size is a terrible indicator of rendering time
requirements for SVG. Unlike most traditional file formats (JPEG, PNG,
GIF) SVG is much more like a programming language.  This means that a
very small SVG file can take a very long time to render.

>> What can be done to speed it up?

TK> Nothing for this document :) For yours, you can reduce the number
TK> of filters or at least, use them carefully.

    Actually Thierry, several of the filters in mathMetal could be
made significantly more efficent (so for example in the 'recessed'
filter all the inputs to the feMerge have seperate 'feComposite
operator="in"' with sourceAlpha, it would be much more efficent to do
that once after the merge.  There are a number of other improvements
that could be made to the filters that are used in the document).  

    I only point this out to make it clearer that SVG is closer to a
programming language than a 'traditional' graphics file format, since
it is often possible to 'optimize' the SVG content (especially when
filters are involved), the same is not true of JPEG and GIF (there are
tools that improve the compression for these formats - often reducing
quality in the processes, but they don't modify the _decoding_ time
significantly).

-- 
							Thomas DeWeese
Thomas.DeWeese@Kodak.com
			  "The only difference between theory and practice is
			   that in theory there isn't any." -- unknown

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