xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Fop 0.95beta - svg tif images
Date Sat, 12 Apr 2008 09:37:01 GMT
On 11.04.2008 19:26:55 Andreas Delmelle wrote:
> On Apr 11, 2008, at 18:20, Peter Coppens wrote:
> >
> >>
> >>> Given my non existent knowledge on tiff (and image formats in  
> >>> general) and (I am sure recognizable) chronic lack of time to  
> >>> dive into image formats at this moment, I am afraid I would not  
> >>> even know with which tiff parameters to play
> >>>
> >>
> >> Which properties did you alter exactly? In the meantime, I read  
> >> somewhere that Apple's native TIFF codec for JAI does not provide  
> >> support for big-endian TIFFs.
> > None to be honest. Just took other tiff files. Would be nice if  
> > someone could try to reproduce my findings on another platform with  
> > other files. Perhaps this is a macos only issue...
> Well, did a very quick test here, and without Jeremias' change, any  
> TIFF that is produced by Preview indeed fails with the message you  
> provided earlier.
> Seems the issue is isolated to OS X. I guess one important thing to  
> check on the side of XMLGraphics is whether the native OS X TIFF  
> reader has peculiarities which make it undetectable somehow. Note  
> that the message indicates the framework is looking for a 'loader/ 
> converter combination'. All nice if there is a native codec, but if  
> there is no matching ... whichever of the two (*) then we'd get an  
> error like that.
> (*) not an expert on the image-handling code, here, so I really can't  
> say whether it should be 'loader' or 'converter' :/

The "loader/converter combination" message comes from my image loader
framework. Don't confuse that with any codec available inside ImageIO.
For the image loader framework ImageIO is just one single "codec". What
ImageIO does internally doesn't interest the image loader. If the
"loader/converter combination" message is produced, it means there's
simply no image loader around that can load TIFF files.

> > although the fact that 0.94 is faster than 0.95beta-jeremias-tiff  
> > would make that ....weird.
> Not really. It would be much weirder IMO if FOP (or any software for  
> that matter) were to offer increased flexibility/functionality/ 
> features without any performance penalty whatsoever. If that were the  
> case, Vista should run on a 386 without any noticeable slow-down when  
> compared to, say, Windows 3.11... errmmm.
> I'd think it pretty 'normal' that the new image-handling framework  
> adds /some/ overhead.

Uhm, yes, but so did the old image code. And that one had an even larger
overhead. The new image loader framework is supposed to provide minimal
overhead (like not parsing image files if not necessary). The old code
old stuff had some of this too, but doesn't do a very good job and
sometimes even had to additionally convert a RenderedImage into a byte
array, for example. Now this is not necessary anymore.

If Peter sends me his test TIFF I'll profile the problem. A factor 6
increase is certainly not to be expected.

> A factor of six would be on the high side,  
> though, but nothing points in the direction of the image-handling  
> framework alone. A lot has been changed and added between 0.94 and  
> 0.95, so even though this may seem 'weird', I somehow expect 0.95 to  
> be slightly slower than 0.94.
> Also, since (I presume) you are timing singular runs, there is no  
> accounting for things like static initialization. This only occurs  
> for the very first run in a given runtime session. If the newer code  
> moved some parts to those areas, then this would only slow down that  
> first run, but could speed up/save memory in all subsequent runs in  
> the same VM.
> Cheers
> Andreas

Jeremias Maerki

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

View raw message