JDK-4665237 : REGRESSION: JInternalFrame outline dragging is very slow to respond
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows_2000
  • CPU: generic,x86
  • Submitted: 2002-04-09
  • Updated: 2002-11-12
  • Resolved: 2002-11-12
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.
Other
1.4.2 mantisFixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description

Name: jk109818			Date: 04/09/2002


FULL PRODUCT VERSION :
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)


FULL OPERATING SYSTEM VERSION :
Redhat Linux 6.2
	glibc-2.1.3.21
	kernel 2.2.16-3smp


ADDITIONAL OPERATING SYSTEMS :
Redhat Linux 7.1
	glibc-2.2.4-19
	kernel 2.4.9-6.1smp



A DESCRIPTION OF THE PROBLEM :
Dragging JInternalFrames within a JDesktop is extremely slow
and jerky on linux (the problem does not seem to occur under
Windows).  Resizing the frame seems to have a similar
problem.  The larger the internal frame the less responsive
dragging and resizing becomes.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. See included example
2.
3.

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.swing.*;
import java.awt.*;

public class Example extends JFrame {

    public static void main(String args[]) { new Example(); }

    public Example() {
        super("eg");
        init();
        pack();
        setVisible(true);
    }

    void init() {
        // build simple interface
        JDesktopPane jdp = new JDesktopPane();
        jdp.setPreferredSize(new Dimension(600,600));
        jdp.setDragMode(JDesktopPane.OUTLINE_DRAG_MODE);
        setContentPane(jdp);

        JInternalFrame jif = new JInternalFrame("boo");
        jif.setSize(400, 400);
        jif.setVisible(true);
        jif.setResizable(true);
        getContentPane().add(jif);
    }
}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
None...and without a fix, we cannot release this software
for use on Linux.

Release Regression From : 1.3.1_03
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 139216) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b07
14-06-2004

EVALUATION Well, after investigating this a little I found that the performance regressed about 15-20x. I looked into the code a little and added some timing code. It ends up that setXORMode has regressed. I'm talking to the 2D group to look for a workaround. ###@###.### 2002-05-16 The 2D code apparently hasn't regressed it's the time it takes to send requests to the xserver. Looking into why this code regressed. ###@###.### 2002-06-10 According to Jim, XOR is now being done in software. We need to add platform acceleration back in. ###@###.### 2002-07-11 I'm committing to fix this in mantis rather than tiger since it's a serious regression for customers. The fix is as described above: reinstate platform rendering for XOR mode (using X11 on Solaris, Linux; GDI on Windows). With this fix in place, users on both platforms should see XOR performance improve back equal to or better than 1.3.1 performance. This is significant for Windows users, because XOR performance on that platform dropped tenfold between 1.4.0 and 1.4.1 (see 4711587). ###@###.### 2002-10-01 Platform (GDI/X11) XOR rendering code has been added back in, and as a result the ~70x regression on Windows and the ~10x regression on Solaris/Linux have been eliminated. Therefore, XOR performance when rendering to the screen is back to 1.3.1 levels. I've verified these performance gains with the attached testcase and in Metalworks (with outline drag mode enabled, dragging/resizing is very responsive again). ###@###.### 2002-10-25
25-10-2002

WORK AROUND In 1.4.1 (on Windows only), using the -Dsun.java2d.ddlock=true flag should help get performance back to 1.4.0 speeds, but this could cause cursor/menu flickering on Windows 2000 and XP. ###@###.### 2002-10-01
01-10-2002