United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6518077 Modal dialogs open slowly with JRE 1.6.0 sun.awt.X11.XToolkit
JDK-6518077 : Modal dialogs open slowly with JRE 1.6.0 sun.awt.X11.XToolkit

Details
Type:
Enhancement
Submit Date:
2007-01-26
Status:
Closed
Updated Date:
2011-03-07
Project Name:
JDK
Resolved Date:
2011-03-07
Component:
client-libs
OS:
solaris,solaris_7,linux,solaris_10
Sub-Component:
java.awt
CPU:
x86,sparc
Priority:
P4
Resolution:
Fixed
Affected Versions:
6,6u10
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
A DESCRIPTION OF THE REQUEST :
With JRE 1.6.0 on Sparc Solaris 10 and the default awt.toolkit (sun.awt.X11.XToolkit),
it takes several seconds for a modal dialog (javax.swing.JDialog) to appear.  The
application appears frozen during this pause.
Switching to the old motif  toolkit restores the expected behavior of no pause before
modal dialogs appear.

JUSTIFICATION :
By default on JRE 1.6.0 sparc solaris, there is a several second freeze any time a modal
dialog (including JFileChooser) is opened.
JRE 1.5.0 did not exhibit this freeze behavior with either sun.awt.X11.XToolkit or
sun.awt.motif.MToolkit.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
There should be no noticable pause when opening a modal dialog.
ACTUAL -
The application freezes for several seconds before the modal dialog appears.

---------- BEGIN SOURCE ----------
class TestAModalDialog extends javax.swing.JDialog
    implements java.awt.event.ActionListener {
    public TestAModalDialog(java.awt.Frame parent) {
        super(parent, true);
        javax.swing.JButton b = new javax.swing.JButton("Dismiss");
        getContentPane().add(b);
        b.addActionListener(this);
        pack();
        setLocation(parent.getLocation());
    }
    public void actionPerformed(java.awt.event.ActionEvent e) {
       setVisible(false);
       dispose();
    }
}

class TestA extends javax.swing.JFrame
    implements java.awt.event.ActionListener {
    public TestA() {
        javax.swing.JButton b = new javax.swing.JButton("Press Me");
        getContentPane().add(b);
        b.addActionListener(this);
        pack();
        addWindowListener(new java.awt.event.WindowAdapter() {
            public void windowClosing(java.awt.event.WindowEvent evt) {
                System.exit(0);
            }
        });
        setLocation(new java.awt.Point(x,y));
        x+=100; y+=50;
    }
    public void actionPerformed(java.awt.event.ActionEvent e) {
        new TestAModalDialog(this).setVisible(true);
    }
    static int x = 0;
    static int y = 0;
    public static void main(String[] argv) {
       // put up three JFrames
       new TestA().setVisible(true);
       new TestA().setVisible(true);
       new TestA().setVisible(true);
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
switch to the motif toolkit by setting -Dawt.toolkit=sun.awt.motif.MToolkit when running java 1.6.0 on sparc solaris.

                                    

Comments
EVALUATION

When a modal dialog is shown, it blocks some or all the Java windows. This blocking is a costly operation and we need to optimize it somehow. To better notice a delay when a dialog is shown, the test provided in the description should be modified to show >10 windows instead of 3.
                                     
2007-01-29
EVALUATION

I have profiled the test a bit and found two bottlenecks: the places that reduce the speed of showing of the dialog most of all. First, the calls to XSetTransientFor in XWindowPeer.setToplevelTransientFor. Second, the calls to XQueryTree in XWindowPeer.collectJavaToplevels.

The first problem is relatively easy to fix. Most of the calls are redundant, I mean lead to setting the hint to the same value as it was already set to earlier. For example, if I have 3 windows blocked, the first's hint is set to null, the second's - to first, the third - to second's and then the second's - to first again. This can be solved by caching the current value of the hint.

The second problem is more difficult to resolve. The only way I found is to call for collectJavaToplevels only once for each modal dialog shown, and then using this set of top-levels to block all the windows blocked by this dialog, instead of calling this method for each window.

After these two improvements I see the great performance, however the dialogs are shown slower than with MToolkit. I suspect the further optimization is much more difficult, however if anyone requires it, I will have to do this.
                                     
2007-03-23



Hardware and Software, Engineered to Work Together