Differences between revisions 8 and 9
Revision 8 as of 2007-12-19 17:03:18
Size: 5972
Comment: wrote some docs
Revision 9 as of 2009-09-20 23:52:20
Size: 5972
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

This page is used to track the progress of the image package rewrite.

TO DO

done

Create the basic interfaces and classes: ImageManager, ImageImplRegistry, Image, ImageSource, ImagePreloader, ImageLoader, ImageConverter and ImageConverterPipeline.

done

Implement Dijkstra's shortest path algorithm to construct ImageConverterPipelines. This will automatically select the best way to acquire an image for a certain rendering situation.

done

Verify that the image conversion pipeline approach works.

done

Dynamic registration of all service provider interfaces (ImagePreloader, ImageLoader & ImageConverter)

done

Select a suitable way to represent the original image source (URI & data source). Decision: Use JAXP Source as base. ImageSource (extends Source) contains an ImageInputStream (from ImageIO). ImageInputStream provides the "push back" functionality I mentioned in the requirements, or rather it allows to seek back indefinitely caching the byte stream either in memory or in a temp file.

done

Distinguish between local file URLs and other URLs. File URLs are converted to File objects so ImageInputStreams can be created that operate directly on the file which makes caching unnecessary.

done

Reimplement Readers as ImagePreloaders for all supported formats. done: SVG, PNG, GIF, TIFF, WMF, EMF, EPS, BMP, JPEG

done

Fully implement intrinsic size determination (size plus resolution) in ImagePreloaders for PNG and TIFF. PNG using ImageIO which is now always available after switching to Java 1.4. TIFF using XML Graphics Commons' TIFF codec.

done

Reimplement the image loading code of the old Image implementations as ImageLoaders. done: ImageIO, Batik(SVG&WMF), raw formats (EPS, JPEG and CCITT), extension examples (Plan and MathML).

done

Implement all necessary ImageConverters. done: SVG->G2D, WMF->G2D, G2D->BufferedImage/RenderedImage, RenderedImage->G2D, RenderedImage->PNG.

done

Write unit test for as much of the functionality as possible/reasonable.

done

Write Javadocs

done

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, CCITT. PNG didn't work.

done

Implement transparent support for GZIP encoded streams.

done

Allow SAXSource and DOMSource for XML-based images. Not implemented but generally supported by the architecture (JAXP Source)

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

done

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. --> Painter moved, Adapter is renderer-specific and stays

done

Integrate the new image package into the layout engine (ImageInfo/ImageSize), the renderers (Image/ImageFlavor) and the FOP extensions.

done

Reimplement support for baseline adjustment (for MathML)

done

Enhance the existing penalty mechanism to allow manual fine-tuning of the conversion decisions.

done

Create a branch and upload what's there already for early feedback.

done

Write some usage docs. done: basic usage and SPI.

OPEN

Write some design docs on the new design.

Open Questions

  • How much focus should I put on backwards-compatibility in the renderer area? FOP extensions could be affected. ATM, I'm not as far as to integrate the whole thing in the renderers, yet.

Resolved Questions

  • What should the final package name be? Currently, I'm working in org.apache.fop.image2 in order to keep the old one next to the new one while I'm rewriting. done: moved to Commons under org.apache.xmlgraphics.image.loader.
  • 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. done: completely decoupled from FOP as a result of moving the package to XG Commons.

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

ImageSupport/Status (last edited 2009-09-20 23:52:20 by localhost)