Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/ImageSupport/Status The comment on the change is: Update status and record some observations ------------------------------------------------------------------------------ ||IN PROGRESS||Write Javadocs|| ||IN PROGRESS||Verify that undecoded images (TIFF with CCITT G4, JPEG, PNG, EPS) are properly supported by the architecture in order to have minimal memory usage and maximum performance (no more passing around byte arrays). done: JPEG, EPS.|| ||done||Implement transparent support for GZIP encoded streams.|| - ||OPEN||Allow SAXSource and DOMSource for XML-based images. Not implemented but generally supported by the architecture (JAXP Source)|| + ||done||Allow SAXSource and DOMSource for XML-based images. Not implemented but generally supported by the architecture (JAXP Source)|| - ||OPEN||Reimplement caching. Cache the various image flavors separately of each other. Identify uncacheable image flavors.|| + ||done||Reimplement caching. Cache the various image flavors separately of each other. Identify uncacheable image flavors.|| ||OPEN||Make sure all streams are properly closed.|| ||OPEN||Support injection of manually built Image subclasses through the Source mechanism (meaning: act during URI resolution and build the final image (ex. as BufferedImage or Graphics2DImagePainter) instead of providing a stream to an encoded image).|| ||OPEN||Decide if the Graphics2DAdapter/Graphics2DImagePainter pair is still in the right place (in the render package) as it is heavily used now in the image package.|| @@ -37, +37 @@ * Should the reference to FOUserAgent be taken out of the image package? That would make it more easily usable outside of FOP. Tonny Kohar of Kiyut is already interested in the package for their image viewer application. An adapter could provide access to a !URIResolver and the source resolution. + = Observations with the new code while testing = + + * For locally accessible bitmap images, the image cache has almost no speed advantage anymore, since the image loading is more efficient. But the caching is not detrimental, either. The additional memory used is reclaimed by the JVM when necessary. + * For images that need to be converted (SVG to bitmap, for example), the image cache will help even for local images. + * Memory consumption has been cut to half in certain cases as no additional in-memory buffers are necessary to serialize the image. + * The expected reduction of output file size has been realized through the use of BufferedImage instead of a normalized RGB byte array. For example, monochrome (1bit) or grayscale images are no longer converted to RGB images (which caused up to a 24 times bigger uncompressed in-memory representations). Of course, this also has speed advantages. + * Hotspots are now in the renderer code which has to serialize the images. For example, the ASCII85OutputStream has shown up in profiling sessions. + * The image package is now a little more complex but I think easier to understand and to extend. The difficulties lie with reusing and closing Sources as optimizations are required in order to avoid multiple requests to HTTP servers for the same image. From a user perspective, the image package is very easy to use (through ImageManager). + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
