In order to perform alpha compositing and other compositing - * operations, we need access to the color values of the imagery that - * has already been drawn on the drawing surface. The - * DirectRasterGraphics interface must therefore contain methods that - * makes it possible to gain access to the pixel values of the drawing - * surface. The methods are modeled after the POSIX mmap() and - * munmap() functions. But, instead of mapping and unmapping portions - * of data from a file descriptor to memory, the methods in - * DirectRasterGraphics maps and unmaps portions of the drawing - * surface to data arrays within writable raster objects. A call to - * mapRaster() will return a writable raster object, encapsulating the - * image data of the drawing surface in the requested domain. The data - * encapsulated by this raster object can be modified using the - * WritableRaster API, or the data buffers can be retrieved from the - * raster, so that the data arrays can be manipulated directly. When - * the raster image has been modified as desired, the data can be - * resynchronized with the drawing surface by calling mapRaster(). - * - *
As with mmap() and munmap() the methods may work by direct - * manipulation of shared memory, (i.e. the raster object directly - * wraps the actual image data of the drawing surface), or may make a - * private copy that is resynched when the raster is unmapped. The - * backend may choose to implement either mechanism, and the pipeline - * code should not care what mechanism is actually used. This design - * allows us to make full use of speedups such as X shared memory - * extentions when available. - */ -public class MappedRaster -{ - WritableRaster raster; - ColorModel cm; - - public MappedRaster(WritableRaster raster, ColorModel cm) - { - this.raster = raster; - this.cm = cm; - } - - public final WritableRaster getRaster() - { - return raster; - } - - public final ColorModel getColorModel() - { - return cm; - } -}