[Bug AWT/20630] New: Image APIs should use BufferedImage exclusively

[Bug AWT/20630] New: Image APIs should use BufferedImage exclusively

[fitzsim at redhat dot com]

The Java 1.1 imaging APIs were designed to be asynchronous, for loading images
over slow networks.  The design is very complicated and hard to implement.  In
1.2 BufferedImages seem to have replaced Images.  So, for example,
Component.createImage() is declared to return an Image, but actually returns a
BufferedImage.  This makes the APIs synchronous -- which should make them much
simpler to implement.

We should do the same in our AWT implementation.  This will involve the following:

- removing all uses of ImageObserver, except when reporting errors in image
loading, and when reporting a new frame in animated gifs

- replacing GtkImage with BufferedImage

- merging GtkImagePainter into GdkGraphics2D

- making the switch to using GdkGraphics2D exclusively

-- 
           Summary: Image APIs should use BufferedImage exclusively
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: AWT
        AssignedTo: fitzsim at redhat dot com
        ReportedBy: fitzsim at redhat dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630

[Bug AWT/20630] Image APIs should use BufferedImage exclusively

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-24 22:14 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-03-24 22:14:44
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630

[Bug AWT/20630] Image APIs should use BufferedImage exclusively

[sven at physto dot se]

------- Additional Comments From sven at physto dot se  2005-06-01 08:06 -------
Ok, in light of my reworking of GtkImage, I should add some thoughts here:

- GtkImagePainter is gone. GtkImage now does its own drawing, and wraps a GdkPixbuf.

- ImageObserver use is pretty much elimated for GtkImage use now, although it
should be reintroduced for animated gif support. This can probably be done
nicely within the GtkImage class without involving other stuff. 

- GtkImage should probably be kept to a small extent even in the future, if only
for internal Component usage. (I'm thinking about animated-gif support for
ImageIcon buttons for instance)

- Component and Toolkit.createImage can create two kinds of images, either from
a file (essentially immutable), and drawable (createImage(int, int)). The latter
should definitely become a BufferedImage with Graphics2D. (as BufferedImage is
drawable and its getGraphics() method should return a Graphics2D object)

The former should probably be implemented on top of ImageIO in the future.
Although the question remains if that'll make things a bit too complicated for
animated gifs?

- the Graphics peer now supports drawing BufferedImages (although slowly)
through the ImageProducer/Consumer interfaces. This should give us a chance to
get BufferedImage working at least to some extent.

Sketching out a BufferedImage strategy:

- The goal is to draw BufferedImages and be able to draw *to* BufferedImages
fast. That means no copying or converting pixel data on these operations. If we
have to choose one, it should be the latter. Copying image data after every
drawing operation would be costly indeed.

- User-defined ColorModels are allowed. So the former goal can never be realized
fully. Realistically, we should aim for the predefined BufferedImage types.

- In other words, we need to differentiate our BufferedImage drawing code for
the predefined types, and others.

- Storing the image data in Javaland memory space will make data copying
necessary, since it can be relocated by the VM. BufferedImage memory must be
natively allocated then.

- This makes me belive that wrapping these native memory buffers is what
java.awt.image.DataBuffer is for. So our current implementation wrapping java
arrays is wrong.

- Currently, Cairo only seems to support RGB-24 and RGBA-32 color models. We
really need it to support all predefined BufferedImage types. (or face copying
and converting pixel data on every draw operation)

- The easiest starting point for implementing all this should therefore be
BufferedImage.TYPE_4BYTE_ABGR.

- I still have no good idea how we should handle drawing to a BufferedImage with
a user-defined color model and pixel storage. Although I'm not sure this is an
important case either.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630

[Bug awt/20630] Image APIs should use BufferedImage exclusively

[sven at physto dot se]

------- Additional Comments From sven at physto dot se  2005-08-04 05:04 -------
(In reply to comment #2)

Apparently I was wrong; DataBuffer does indeed wrap a true Java array. E.g. With
the JDK, if a DataBuffer is constructed from a java array, changes in that array
will be reflected in the DataBuffer. Same goes for the array returned by
Databuffer.getData().

So this appears to be a bit of a conundrum. Perhaps DataBuffer could represent a
*pinned* java array, with the databuffer constructor pinning the array from the
native side and the destructor unpinning it? Is that legal? This won't help if
the array pointer returned by JNI is a copy though. Problematic.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630

[Bug awt/20630] Image APIs should use BufferedImage exclusively

[fitzsim at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630

[Bug awt/20630] GTK 2.8 peer Image and Graphics API reorganization

[fitzsim at redhat dot com]

------- Additional Comments From fitzsim at redhat dot com  2005-09-10 01:15 -------
I'm changing the summary to be more general.  Now that GTK 2.8 and Cairo 1.0 are
out we can make the transition to using Graphics2D exclusively in the GTK peers.
 This will allow us to re-organize the Image APIs to handle VolatileImages,
BufferedImages and normal Images, remove GdkGraphics, remove GdkPixbufDecoder
and split GdkGraphics2D into Image- and Component-specific graphics-contexts.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Image APIs should use       |GTK 2.8 peer Image and
                   |BufferedImage exclusively   |Graphics API reorganization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20630