Rendering Independence: The Renderable and Rendered Imaging Layers
Another important advancement included in the Java 2D API, and one that forms the heart of the JAI, is the ability to do rendering independent imaging operations. The use of rendering independent operations can be quite powerful and is accomplished through classes that implement the Renderable interface. The basic advantage of rendering independence is that image operations can be accomplished without processing the pixel data. This enables a number of important optimizations, not the least of which is a greatly reduced need to render, but also goes a long way toward ensuring optimal quality over all devices. Most of the advanced capabilities that are such an integral part of the JAI are built on the capability of rendering independence.
Many incorrectly equate rendering independence with the related concept of resolution independence, but, strictly speaking, resolution independence is but one part of the more general rendering independence. Resolution independence refers to the fact that because a transformation exists between the resolution of the image source and the resolution of the target output device, operations can occur independently of either as long as the final transformation is applied at the end. Rendering independence extends this idea beyond resolution to basically all other aspects of the rendering.
It is important to note that it isn't always desirable to operate in a rendering independent fashion. Indeed, one generally has to enter the device dependent world eventually. An important component of the Java 2D and JAI rendering independent model is that a parallel world always exists for performing rendering dependent operations. These two parallel worlds are called the Renderable and Rendered layers. They are intended to work together.
The Renderable layer is the rendering independent layer. As such, a single renderable image can participate in a wide variety of contexts (that is, multiple printers, monitors, and output files). Any operation that produces a Renderable image as output can itself be considered a Renderable source for any other operation. Therefore, a series of Renderable image operations (known as RenderableImageOps) can be set up as an editable chain or graph (Figure 2.5). The design of graphs will be discussed in Chapter 6.
Figure 2.5. Rendering graph showing chain of operations in the Renderable Layer.
For now, remember the following: All Renderable images are required to adapt to a rendering context specified through an object instantiated from the RenderContext class. In other words, RenderContext contains the information needed to produce a specific rendering (that is, for a specific context) of an image. This information includes a rendering independent description of the area to be rendered and other information about the rendering context and resolution of the target device. To create a specific rendering, the user instantiates a RenderContext object and calls the createRendering() method of the RenderableImage.
The RenderableImageOps adapts to specific operations through classes implementing the ContextualRenderedImageFactory interface (also known by the acronym CRIF). The CRIF acts as the link between the Renderable and Rendered layers and is passed in during instantiation of the RenderableImageOp. The key idea here is that a single RenderableImageOp is used, but a series of CRIFs are specified to perform the different imaging operations.