Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 4665237
Votes 58
Synopsis REGRESSION: JInternalFrame outline dragging is very slow to respond
Category java:classes_2d
Reported Against 1.4 , hopper-beta
Release Fixed 1.4.2(mantis)
State 10-Fix Delivered, bug
Priority: 3-Medium
Related Bugs 4686738 , 4711587 , 4771101
Submit Date 09-APR-2002
Description




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) 
======================================================================
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.
 xxxxx@xxxxx  2002-10-01
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.
 xxxxx@xxxxx  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.
 xxxxx@xxxxx  2002-06-10

According to Jim, XOR is now being done in software.  We need to add platform
acceleration back in.
 xxxxx@xxxxx  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).
 xxxxx@xxxxx  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).
 xxxxx@xxxxx  2002-10-25
Comments
  
  Include a link with my name & email   

Submitted On 27-JUN-2002
qwerty09867
I see this regression on windows 2000 sp2 with:

java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


Submitted On 03-JUL-2002
ginop
I reproduced the problem using 1.4.1beta on windows 2000 
sp2.

The problem seems to be worst with 1.4.1beta than 
1.4.0_01.  
With 1.4.0_01, we can drag internal frames without any 
problems unless moving it under a non modal JDialog.
With 1.4.1beta, dragging internal frames is always slow.


Submitted On 29-AUG-2002
sellhorn
Argh! This is horrible on windows too !

It's actually faster for me to turn on, to the
live mode dragging. I tried this on Win2K
& java 1.4.1-beta.

Will try with 1.4.1-rc, I'm praying it fixes it!!!


Submitted On 25-SEP-2002
aanecito
Oh no! I am seeing the same thing and high CPU loading in 
W2K


Submitted On 26-SEP-2002
omurata
XOR mode drawing speed in java 1.4.1 FCS is getting worse 
than java 1.4.0_02 


Submitted On 02-OCT-2002
sellhorn
Which release is 'mantis'? Is that 1.4.2, and what's
the schedule for that?


Submitted On 21-MAR-2003
chakradhar
Mantis Release is 1.4.2. To be released some time this year.

Does anyone know how to get a Beta version of 1.4.2 ?



PLEASE NOTE: JDK6 is formerly known as Project Mustang