RenderableImageOp
. Instead of an explicit ContextualRenderedImageFactory
, the indirection of the OperationRegistry
is used. A RenderableOp
stores an operation name and a ParameterBlock
containing sources and parameters. A set of nodes may be joined together via the source Vector
s within their respective ParameterBlock
s to form a directed acyclic graph (DAG). The topology, i.e., connectivity, of the graph may be altered by changing the node's sources. The operation name and parameters may also be changed.
Such chains provide a framework for resolution- and rendering- independent imaging. They are useful in that a chain may be manipulated dynamically and rendered multiple times. Thus for example the same chain of operations may be applied to different images or the parameters of certain operations in a chain may be modified interactively.
A RenderableOp
may be constructed directly as, for example,
RenderableImage addend1; RenderableImage addend2; ParameterBlock pb = (new ParameterBlock()).addSource(addend1).addSource(addend2); RenderableOp node = new RenderableOp("add", pb);
or via the createRenderable()
or createRenderableNS()
methods defined in the JAI
class. The difference between direct construction of a node and creation via a convenience method is that in the latter case: validateArguments()
method of the associated OperationDescriptor
, the arguments (sources and parameters) are validated as being compatible with the specified operation.RenderingHints
maintained by the JAI
instance are set on the RenderableOp
using setRenderingHints()
. When a chain of nodes is rendered by any any of the createRendering()
methods, a "parallel" chain of RenderedImage
s is created. Each node in the chain of RenderableOp
s corresponds to a node in the chain of RenderedImage
s. A RenderedImage
associated with a given node is referred to as a rendering of the node.
The translation between RenderableOp
chains and RenderedImage
(usually OpImage
) chains makes use of three levels of indirection provided by the OperationRegistry
, ContextualRenderedImageFactory
, (CRIF), and RenderedImageFactory
(RIF) facilities. First, the OperationRegistry
is used to map the operation name into a CRIF. This CRIF then constructs a RenderedImage
via its create(RenderContext, ParameterBlock)
method. The third level of indirection results from the operation name being mapped within create()
into the optimum RIF which actually creates the RenderedImage
. (Note that this third level of indirection is a function of the CRIF implementation of the renderable create()
method: that provided by the convenience class CRIFImpl
provides this indirection.) If the RenderedImage
returned by the CRIF create()
invocation is a RenderedOp
, it is replaced with the rendering of the RenderedOp
(usually an OpImage
).
RenderingHints
may be set on a RenderableOp
to provide a set of common hints to be used in all invocations of the various createRendering()
methods on the node. These hints are merged with any hints supplied to createRendering()
either explicitly or via a RenderContext
. Directly supplied hints take precedence over the common hints.
RenderableOp
nodes may participate in Java Bean-style events. The PropertyChangeEmitter
methods may be used to register and unregister PropertyChangeListener
s. Certain PropertyChangeEvent
s may be emitted by the RenderableOp
. These include the PropertyChangeEventJAI
s and PropertySourceChangeEvent
s required by virtue of implementing the OperationNode
interface.
RenderableOp
nodes are WritablePropertySource
s and so manage a name-value database of image meta-data also known as image properties. Properties may be set on and requested from a node. The value of a property not explicitly set on the node (via setProperty()
) is obtained from the property environment of the node. When a property is derived from the property environment it is cached locally to ensure synchronization, i.e., that properties do not change spontaneously if for example the same property is modified upstream.
The property environment of the RenderableOp
is initially derived from that of the corresponding OperationDescriptor
as maintained by the OperationRegistry
. It may be modified locally by adding a PropertyGenerator
or by suppressing a specific property. These modifications cannot be undone.
When a property value is requested an attempt will be made to derive it from the several entities in the following order of precedence:
PropertyGenerator
s, or setProperty()
or due to caching of a property derived from the property environment. The properties of a RenderableOp
node are copied to each rendering generated by any of the createRendering()
methods. Properties already set on the rendering are not copied, i.e., those of the rendering take precedence.
A RenderableOp
chain created on a client may be passed to a server via a RemoteImage
. Any RenderedImage
sources which are not Serializable
will be wrapped in SerializableRenderedImage
s for serialization. The tile transmission parameters will be determined from the common RenderingHints
of the node. All other non-serializable objects will attempt to be serialized using SerializerFactory
. If no Serializer
is available for a particular object, a java.io.NotSerializableException
may result. Image properties (meta-data) are serialized insofar as they are serializable: non-serializable components are simply eliminated from the local cache of properties and from the property environment.
@see CRIFImpl
@see CollectionOp
@see OperationRegistry
@see RenderedOp
@see java.awt.RenderingHints
@see java.awt.image.renderable.ContextualRenderedImageFactory
@see java.awt.image.renderable.RenderableImageOp
@see java.awt.image.renderable.RenderContext
|
|
|
|
|
|