1 |
14 |
jlechner |
/* 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 |
|
|
}
|