I am tracking down the excessive number of repaints when a Frame is created
and shown. I have observed that RESIZE events are being generated when
a frame is MOVED. The following stack trace was obtained by modifying
EventQueue.postEvent:

java.awt.event.ComponentEvent[COMPONENT_RESIZED (276,200 600x500)] on frame1
java.lang.Exception
at java.awt.EventQueue.postEvent(EventQueue.java:88)
at java.awt.EventQueue.postEvent(EventQueue.java:62)
at sun.awt.motif.MToolkit.postEvent(MToolkit.java:298)
at sun.awt.motif.MComponentPeer.postEvent(MComponentPeer.java:250)
at sun.awt.motif.MFramePeer.handleResize(MFramePeer.java:160)
at sun.awt.motif.MComponentPeer.setBounds(MComponentPeer.java:494)
at java.awt.Component.reshape(Component.java:942)
at java.awt.Component.setBounds(Component.java:893)
at java.awt.Component.move(Component.java:770)
at java.awt.Component.setLocation(Component.java:762)
at javasoft.sqe.javatest.tool.ToolFrame.showCentered(ToolFrame.java:127)
at javasoft.sqe.javatest.tool.Main.showTool(Main.java:221)
at javasoft.sqe.javatest.tool.Main.go(Main.java:137)
at javasoft.sqe.javatest.Main.run(Main.java:103)
at javasoft.sqe.javatest.tool.Main.main(Main.java:57)

If you look closely, you will see that Component.setLocation is being
called, which is going through the setBounds routine which handles both
move and resize. However, even though we are just calling setLocation(),
MFramePeer.handleResize() is being called, which is posting a RESIZE event.
This causes the Frame to call invalidate/validate/repaint which causes
unnecessary repainting of the Frame.

Comparing the code for 1.1.5 and 1.1.6, check out awt_Frame.c line 448.
In 1.1.5, this is
case ConfigureNotify:
which is followed by the following comment and code:

        /* We can detect the difference between a move and a resize
         * by checking the send_event flag on the event; if it's true,
         * then it's indeed a move, if it's false, then this is a resize
         * and we do not want to process it as a "move" (for resizes
         * the x,y values are misleadingly set to 0,0, and so just
         * checking for an x,y delta won't work).
         */
        if ((targetPtr->x != event->xconfigure.x ||
            targetPtr->y != event->xconfigure.y) &&
            event->xconfigure.send_event == TRUE) {

In 1.1.6, the ConfigureNotify has been replaced by a ReparentNotify
and the comments and code to distinguish between move and resize have been
deleted. Although I do not completely understand what is going on, it seems
like this might explain the observed effects of getting RESIZE events from
a call of setLocation.


See also bug 4138965 which addresses the issue of why events are generated
in both MFramePeer.handleResize() and Component.reshape(). Combined with this
bug, it explains the SIGNIFICANT amount of flashing when an application is
started.