OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-dev/] [or1k-gcc/] [libjava/] [gnu/] [awt/] [j2d/] [MappedRaster.java] - Blame information for rev 791

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 756 jeremybenn
/* 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
}

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.