JDK-6518077 : Modal dialogs open slowly with JRE 1.6.0 sun.awt.X11.XToolkit
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6,6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,solaris,solaris_7,solaris_10
  • CPU: x86,sparc
  • Submitted: 2007-01-26
  • Updated: 2011-03-07
  • Resolved: 2011-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u16-revFixed 7 b14Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
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 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.
23-03-2007

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.
29-01-2007