1 | /* Copyright (C) 2000 Free Software Foundation
|
---|
2 |
|
---|
3 | This file is part of libgcj.
|
---|
4 |
|
---|
5 | This software is copyrighted work licensed under the terms of the
|
---|
6 | Libgcj License. Please consult the file "LIBGCJ_LICENSE" for
|
---|
7 | details. */
|
---|
8 |
|
---|
9 | package gnu.awt.j2d;
|
---|
10 |
|
---|
11 | import java.awt.image.WritableRaster;
|
---|
12 | import java.awt.image.ColorModel;
|
---|
13 |
|
---|
14 | /* The raster and associated properties of a mapped screen region.
|
---|
15 | * The compositing capabilities of backends are often insufficient.
|
---|
16 | * The backend may not support alpha blending, or may not support some
|
---|
17 | * other special compositing rule. This means that compositing must
|
---|
18 | * sometimes be done within the rendering pipeline. The general
|
---|
19 | * compositing operation consists of combining new color and alpha
|
---|
20 | * values with existing color values on the drawing surface, to find
|
---|
21 | * the new color values for the drawing surface. The way the values
|
---|
22 | * are combined, determines what kind of compositing operation that is
|
---|
23 | * performed. The default compositing operation is alpha compositing.
|
---|
24 | *
|
---|
25 | * <p>In order to perform alpha compositing and other compositing
|
---|
26 | * operations, we need access to the color values of the imagery that
|
---|
27 | * has already been drawn on the drawing surface. The
|
---|
28 | * DirectRasterGraphics interface must therefore contain methods that
|
---|
29 | * makes it possible to gain access to the pixel values of the drawing
|
---|
30 | * surface. The methods are modeled after the POSIX mmap() and
|
---|
31 | * munmap() functions. But, instead of mapping and unmapping portions
|
---|
32 | * of data from a file descriptor to memory, the methods in
|
---|
33 | * DirectRasterGraphics maps and unmaps portions of the drawing
|
---|
34 | * surface to data arrays within writable raster objects. A call to
|
---|
35 | * mapRaster() will return a writable raster object, encapsulating the
|
---|
36 | * image data of the drawing surface in the requested domain. The data
|
---|
37 | * encapsulated by this raster object can be modified using the
|
---|
38 | * WritableRaster API, or the data buffers can be retrieved from the
|
---|
39 | * raster, so that the data arrays can be manipulated directly. When
|
---|
40 | * the raster image has been modified as desired, the data can be
|
---|
41 | * resynchronized with the drawing surface by calling mapRaster().
|
---|
42 | *
|
---|
43 | * <p>As with mmap() and munmap() the methods may work by direct
|
---|
44 | * manipulation of shared memory, (i.e. the raster object directly
|
---|
45 | * wraps the actual image data of the drawing surface), or may make a
|
---|
46 | * private copy that is resynched when the raster is unmapped. The
|
---|
47 | * backend may choose to implement either mechanism, and the pipeline
|
---|
48 | * code should not care what mechanism is actually used. This design
|
---|
49 | * allows us to make full use of speedups such as X shared memory
|
---|
50 | * extentions when available.
|
---|
51 | */
|
---|
52 | public class MappedRaster
|
---|
53 | {
|
---|
54 | WritableRaster raster;
|
---|
55 | ColorModel cm;
|
---|
56 |
|
---|
57 | public MappedRaster(WritableRaster raster, ColorModel cm)
|
---|
58 | {
|
---|
59 | this.raster = raster;
|
---|
60 | this.cm = cm;
|
---|
61 | }
|
---|
62 |
|
---|
63 | public final WritableRaster getRaster()
|
---|
64 | {
|
---|
65 | return raster;
|
---|
66 | }
|
---|
67 |
|
---|
68 | public final ColorModel getColorModel()
|
---|
69 | {
|
---|
70 | return cm;
|
---|
71 | }
|
---|
72 | }
|
---|