Some AWT feedback

[Norman Hendrich <hendrich at informatik dot uni-hamburg dot de>]

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