obtained gcc-4.6.4.tar.bz2 from upstream website;upstream

verified gcc-4.6.4.tar.bz2.sig;
imported gcc-4.6.4 source tree from verified upstream tarball.

downloading a git-generated archive based on the 'upstream' tag
should provide you with a source tree that is binary identical
to the one extracted from the above tarball.

if you have obtained the source via the command 'git clone',
however, do note that line-endings of files in your working
directory might differ from line-endings of the respective
files in the upstream repository.

1 files changed, 72 insertions, 0 deletions

diff --git a/libjava/gnu/awt/j2d/MappedRaster.java b/libjava/gnu/awt/j2d/MappedRaster.java
new file mode 100644
index 000000000..eb41eecf9
--- /dev/null
+++ b/libjava/gnu/awt/j2d/MappedRaster.java
@@ -0,0 +1,72 @@
+/* Copyright (C) 2000  Free Software Foundation
+
+   This file is part of libgcj.
+
+This software is copyrighted work licensed under the terms of the
+Libgcj License.  Please consult the file "LIBGCJ_LICENSE" for
+details.  */
+
+package gnu.awt.j2d;
+
+import java.awt.image.WritableRaster;
+import java.awt.image.ColorModel;
+
+/* The raster and associated properties of a mapped screen region.
+ * The compositing capabilities of backends are often insufficient.
+ * The backend may not support alpha blending, or may not support some
+ * other special compositing rule.  This means that compositing must
+ * sometimes be done within the rendering pipeline.  The general
+ * compositing operation consists of combining new color and alpha
+ * values with existing color values on the drawing surface, to find
+ * the new color values for the drawing surface. The way the values
+ * are combined, determines what kind of compositing operation that is
+ * performed.  The default compositing operation is alpha compositing.
+ *
+ * <p>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().
+ *
+ * <p>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;
+  }
+}