JDK-4895361 : 1.4 REGRESSION: Performance problem with awt Panel.add(), slow in 1.4
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1_03,1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2003-07-24
  • Updated: 2003-09-24
  • Resolved: 2003-09-24
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
5.0 tigerFixed
Related Reports
Relates :  
Description

Name: jk109818			Date: 07/23/2003


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

FULL OPERATING SYSTEM VERSION :Microsoft Windows 2000
[Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
This bug appears to be new with Java 1.4.  I could
not reproduce it in 1.3

Frequently, but not always:  Creating a Panel and adding it
to a Frame that is currently being displayed causes a 3-5
second delay.  It seems to *only* happen if the Panel is
given bounds before being added.

====>> When the delay happens, the CPU is maxxed.  This
does not appear to be a swapping problem.

This is highly variable; sometimes it won't happen for 100
trials, sometimes every try for 10 straight.

Indirect evidence leads me to believe that the delay is
happening in the peer creation for the Panel, but don't
take this hint too seriously.




REGRESSION.  Last worked in version 1.3

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the included code.  (The problem happens for stand-
alone apps like the included code and happens from applets
using the 1.4.0 and 1.4.1 plugins)


EXPECTED VERSUS ACTUAL BEHAVIOR :
It should be printing numbers on the order of 0 to 100.

It sometimes prints numbers like 0 or 10; sometimes prints
numbers like 3532.  When it prints the large numbers, the
system is unresponsive during the 3.5 seconds and the CPU
is maxxed out.



REPRODUCIBILITY :
This bug can be reproduced often.

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

class Test4 {
    
    public static void main(String[] args) {
	try {
	    start();
	} catch (Throwable t) {  t.printStackTrace(); }
    }

    public static void start() throws Throwable {
	Frame f = new Frame();
	f.setLayout(new BorderLayout());
	f.setBounds(100, 100, 800, 800);
	f.show();

	Panel p = new Panel();
	p.setBackground(Color.red);
	System.err.println("Adding");
	p.setBounds(0, 0, 100, 100);
	long t1 = System.currentTimeMillis();
	f.add(p, BorderLayout.CENTER);
	long t2 = System.currentTimeMillis();
	System.out.println(t2-t1);

    }
}
---------- END SOURCE ----------

CUSTOMER WORKAROUND :
set the bounds of the Panel *after* adding it to the Frame.

This bug report may be the whole story or it may be just
the tip of some iceberg.  If anybody knows the full extent
of the problem and workaround, I'd really appreciate a
description.  If this was a single small piece of code it
would be no big deal, but we have a large body of code that
may have to be rearranged.

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

(Incident Review ID: 178751) 
======================================================================

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

EVALUATION I'm pretty sure this is a duplicate of several other related bugs: 4673954, 4745222, 4873526, 4878438, 4884034. Once the problem is fixed, we'll retest and hopefully be able to close them all out. The work-around we've found is to call setVisible(false) before calling add(). ###@###.### 2003-07-23 This is indeed a duplicate of 4745222. It has been fixed in tiger. ###@###.### 2003-09-15 4745222 has been integrated into Tiger, so I am marking this bug as integrated as well. ###@###.### 2003-09-23
15-09-2003

WORK AROUND + p.setVisible(false); f.add(p, BorderLayout.CENTER); + p.setVisible(true); ###@###.### 2003-07-23
23-07-2003