xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Coppens <pc.subscripti...@gmail.com>
Subject Re: Fop 0.95beta - svg tif images
Date Sat, 12 Apr 2008 11:51:54 GMT

On 12 Apr 2008, at 13:09, Andreas Delmelle wrote:
> On Apr 11, 2008, at 23:30, Peter Coppens wrote:
>
> Hi Peter
>
>>
>> I don't like the jai dependancy (don't like native Java libraries)
>
> Very rightly so. As demonstrated by this particular case, if one  
> platform lacks native support, it seriously breaks the usability of  
> the library as a platform-independent way of handling images.
>
> Maybe this will be better in Apple Java 6, but I can't test since  
> the DP is only available for 64-bit Intel Macs and I'm still on  
> PowerPC... :(
I did...and these are decoders that are available
BMP
bmp
jpg
JPG
wbmp
jpeg
png
PNG
JPEG
WBMP
GIF
gif
>
>
>> but Jeremias' patch would solve that. The 6x performance hit  
>> is ....more troublesome :(
>
> Does this performance hit here also increase with the number of  
> TIFFs you include (as you verified with Sun's pure Java  
> implementation),
yes it does...that was the point I was trying to make
> or is the effect restricted to the first one?
No, it does not,.
> If you include, say 6 different images, is there still a 6x  
> performance hit, or does it shrink?
Have not tried to be honest
> The latter would ind1icate that the performance hit could actually  
> be a sign of good scalability (always think positive ;-)).
> A performance /hit/ for very low numbers, which decreases, then once  
> a threshold is reached, translates itself into an actual  
> performance /benefit/ for the larger numbers (?)
> An algorithm with linear behavior will perform better (sometimes / 
> much/ better) for only one execution, than one with logarithmic  
> behavior. The latter, OTOH, will very soon become your friend as the  
> number of executions starts to grow. Slower for a single execution  
> due to the added complexity, but this added complexity would  
> precisely have as its purpose to reduce the runtime for future  
> executions. Only if there are none, does this become pure overhead.
Yes thanks for the refreshment (I had my share of csc :) ).

> Another thing you could try out: Is there a similar difference in  
> timing if the TIFF is included as an fo:external-graphic? That would  
> already allow to factor Batik out of the equation.
Yes indeed...that would be a good parameter to play with.
>
>
>
> Cheers
>
> Andreas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>


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


Mime
View raw message