Some AWT feedback

Wed Feb 9 11:51:00 GMT 2005

Hi,
On Fri, 2005年02月04日 at 15:03 +0100, Norman Hendrich wrote:
>> 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).
>
I investigated this one. I fixed the warnings and the dialog does
display now but the app still crashes when I try to change directories.
It looks like gnomevfs expects to be called only from the glib main
loop, so we'll have to find a way to ensure that. There is already a
bug filed for this one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19453
> 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?

I'll fix this in my current round of painting fixes. Can you file a bug
report with a test case?
>> 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... 

Can you file bug reports in gcc.gnu.org/bugzilla with test cases (where
you have them) for 3, 4, 5 and 6?
>>> 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.

Put the following lines in ~/.gdbinit:
handle SIGPWR nostop noprint
handle SIGXCPU nostop noprint
and re-run under gdb. Then you'll see where it's actually failing. If
gdb is crashing, try CVS gdb.
>> Is there *ANY* way to debug complex, multithreaded GTK+ applications
> on Linux? 

Well, it's pretty difficult, which is part of the reason these things
take so long to fix :( There are some tricks you should know about
though:
In GtkToolkit.gtkInit, call:
XSynchronize (GDK_DISPLAY_XDISPLAY (gdk_display_get_default ()), 1);
I'll be adding this in an #ifdef block when I next commit.
There's also DEBUG_LOCKING in gtkpeer.h. Enable it to see where the gdk
critical section is entered and exited. This one's good for debugging
deadlocks in the peers.
Another useful debugging tool is xwininfo, coupled with calls to
GDK_WINDOW_XID in your GTK code. xwininfo will tell you information
about a window that you click on. See also the -tree option which dumps
a window's hierarchy. It's very handy.
Thanks for testing this stuff and reporting back. I will fix all of
these things eventually, but it'd be great if you could file everything
in bugzilla so I won't forget about the individual issues.
Tom