Re: Xlib AWT peers and Java 2D

["Rolf W. Rasmussen" <rolfwr at ii dot uib dot no>]

On Sun, Oct 08, 2000 at 04:40:34PM -0600, Tom Tromey wrote:
> How does your non-Java image loading work?  Do you use things like
> libtiff, libjpeg, etc?

I've only created code for libjpeg so far. The idea is to create an image
i/o API, that will allow arbitrary image codecs to be plugged in. This will
allow any type of codecs to be implemented/wrapped, libtiff, libjpeg,
libungif, libpng, pixbuf, imlib, etc., all as separate modules.

There are basically two ways of loading images that needs to be satisfied:

1. Incremental loading using ImageProducer.

2. Efficiently stuffing the pixels in an BufferedImage with sample/color
   models matching the source image.

The old libjpeg code I have isn't quite there, but it defines an extended
ImageProducer API, that allows quick image transfers by by way of
WritableRaster objects. The main idea is to reduce the number of steps
before the image reaches the screen.

Using the API I have in mind, it is possible, given correct image
depth, etc., to allow libjpeg to decode the image directly into the
shared memory region of a pixmap.

> Rolf> gnu.gcj.xlib: The CNI based Xlib classes. 
> 
> This one is definitely fine.
> 
> Rolf> gnu.awt.xlib: The X based AWT peer toolkit.
> Rolf> gnu.awt.j2d: The Java 2D graphics pipeline classes.
> Rolf> gnu.awt: Misc. support classes I envision would be useful for any
> Rolf> 	 AWT toolkit implementation.
> 
> Maybe this should be raised on the Classpath list as well.
> 
> Classpath tends to use gnu.java.awt.* (ie, more full path name).
> For the peers they would use gnu.java.awt.peer.xlib.*.

I saw the recent gtk patches used gnu.awt.gtk. This was my main motivation
for using gnu.awt.xlib rather than gnu.java.awt.peer.xlib.

> I don't know the answer.  But could it be done if we could modify Gtk?
> That might be possible (though I don't have any inside knowledge about
> it or anything like that).

What is really needed, is to allow GTK components to be drawn using any
kind of java.awt.Graphic instance. This might involve redirecting
paint requests back to a java Graphic object at the GDK level. I can
imagine this will quickly become very messy.

-- 
Rolf W. Rasmussen