Some AWT feedback

Sun Feb 6 12:07:00 GMT 2005

Dear AWT experts,
I still have problems with GCJ+AWT on my system, even after upgrading
to current/recommended versions of glib,atk,gtk,pango,fontconfig,freetype2,
libpixman,and cairo. I last tried gcc-4.0-20050130 snapshot, configured 
with 
 --enable-languages=c,c++,java
 --enable-threads=posix
 --enable-java-awt=gtk
 --enable-gtk-cairo
on a Linux system (SuSE 8.2, kernel 2.4.20).
Could one of the Gurus please post a little status report whether any
of the following problems are resolved on his/her "golden development"
system and setup, or on the GUI branch?
On my system, simple AWT applications work ok. Here is the status about
a few more complex things:
0) gcj can compile my AWT and Swing apps without problems.
1) Showing a FileDialog crashes glib... I get an incomplete dialog window,
 and a few glib warnings, and then the app is dead. (Note that I don't
 usually use gnome at all, gimp works fine, gtk-demo works fine).
2) I found the annoying canvas-subclass-repaints-itself-over-and-over
 bug I reported back in August of last year. As it turned out, two 
 different features of gcj/awt result in this behaviour:

 I have (had :-)) one class that uses the following idiom

 class X extends Canvas {
 public void paint( Graphics g ) {
 setBackground( Color.gray );
 ... // custom painting
 }
 }

 Unfortunately, calling setBackground() on a Component results in another
 call to paint() via a property-change mechanism in GCJ 
 in Component.setBackground().

 I understand the motivation for this, but either the JDK simply does not
 do this at all, or Sun checks whether the color actually changed before
 calling repaint(). Could we do this in gcj, too?

3) Another perpetual repaint loop arises when components use themselves
 as ImageObservers for drawImage() calls - but not always. Instead of
 debugging this thoroughly, I just use null instead of an ImageObserver
 right now:

 class Y extends Canvas {
 public void paint( Graphics g ) {
 g.drawImage( theImage, theX, theY, null ); // works
 g.drawImage( theImage, theX, theY, this ); // repaint loop in gcj !?
 }
 } 

4) MouseEvents seem to carry the right mouse-button masks (BUTTON2_MASK, etc.)
 However, when queried via InputEvent.isShiftDown(), isAltDown(), 
 isMetaDown(), a MouseEvent always returns false. Not good!

5) Calls to the "synchronous" variants of Graphics.drawImage still fail
 when the actual drawing is shifted to negative coordinates (source 
 to target, that is to the upper left). For example,

 g = targetImage.getGraphics();
 g.drawImage( sourceImage, -100, -50, null )

 works, while

 g = targetImage.getGraphics();
 g.drawImage( sourceImage, 
 0, 0, width, height,
 xoffset, yoffset, xoffset+width, yoffset+width,
 null )

 fails when xoffset and/or yoffset are > 0.

6) Is java.awt.image.BufferedImage( TYPE_INT_RGB ) or TYPE_INT_ARGB
 expected to work? Using a getGraphics() on a BufferedImage crashes
 my gcj applications... 

7) Several of my applications just crash ("Abort") after a few seconds,
 usually shortly after showing the main application window for the first
 time. No stacktrace, no messages. GDB tells me about a SIGPWR signal
 and crashes when asked for more details.

 Is there *ANY* way to debug complex, multithreaded GTK+ applications
 on Linux? 

A Swing challenge follows in my next post :-) 

- Norman