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 Vectors within their respective ParameterBlocks 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 RenderedImages is created. Each node in the chain of RenderableOps corresponds to a node in the chain of RenderedImages. 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 PropertyChangeListeners. Certain PropertyChangeEvents may be emitted by the RenderableOp. These include the PropertyChangeEventJAIs and PropertySourceChangeEvents required by virtue of implementing the OperationNode interface.
RenderableOp nodes are WritablePropertySources 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:
PropertyGenerators, 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 SerializableRenderedImages 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
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 Vectors within their respective ParameterBlocks 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 RenderedImages is created. Each node in the chain of RenderableOps corresponds to a node in the chain of RenderedImages. 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 PropertyChangeListeners. Certain PropertyChangeEvents may be emitted by the RenderableOp. These include the PropertyChangeEventJAIs and PropertySourceChangeEvents required by virtue of implementing the OperationNode interface.
RenderableOp nodes are WritablePropertySources 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:
PropertyGenerators, 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 SerializableRenderedImages 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
| |
| |