JDK-4221185 : In Jdk1.2 (Java 2 platform), getGraphics() is dramatically slow.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1999-03-17
  • Updated: 2000-03-21
  • Resolved: 2000-03-21
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.0 betaFixed
Related Reports
Relates :  
Description

Name: vi73552			Date: 03/17/99


I attach a simple Java test program used to test the speed of
graphics. The program uses awt1.1 features only, ie, no java2D 
or swing.
Running the program on jdk1.1.7 is very fast, no problem there.
running the *same* program on jdk1.2 slows down by a factor of
about 10.
I have tried to compile it with jdk1.2, with -O flag on, no
effect. The same slowdown was valid on an WindowsNT platform,
as well as on Solaris.

import java.awt.*;
import java.awt.image.*;
import java.util.*;
//repeatedly draw a square to a canvas
class Test2 extends Frame  {

public static void main(String[] args) {
	Test2 f = new Test2();
	f.resize (400, 400);
	f.show();
	f.draw();
	System.exit(1);
}

public void draw() {
	int k;
	x[0] = 30;
	x[1] = 60;
	x[2] = 60;
	x[3] = 30;
	x[4] = 30;
	
	y[0] = 30;
	y[1] = 30;
	y[2] = 60;
	y[3] = 60;
	y[4] = 30;
	Color c ;
	for (i = 0; i < 10; i++){
		c = Color.red;
		for (j = 0; j < 200; j++) {
			for (k = 0; k <= 4; k++ ) {
				x[k] = x[k] + 1;
				y[k] = y[k] + 1;
				MyRepaint(c);
			}
		}
		c = Color.blue;
		for (j = 0; j < 200; j++) {
			for (k = 0; k <= 4; k++ ) {
				x[k] = x[k] - 1;
				y[k] = y[k] - 1;
				MyRepaint(c);
			}
		}
	}
}

public void update (Graphics g) {
	paint (g);
}

public void MyRepaint(Color c) {
	Graphics Gr;
	Gr = this.getGraphics();
	Gr.setColor (c);
	paint (Gr);
}


public void paint (Graphics g) {
	g.fillPolygon(x, y, 5);
}

public int x[] = new int[5];
public int y[] = new int[5];
public int i = 0;
public int j = 0;
}
(Review ID: 55469) 
======================================================================

Name: skT88420			Date: 05/07/99


as I wrote You on 24.03.99, there is a perfomrance bug with
JDK 1.2, even with the JIT-update 3.10.100 !!!
We isolated it and found that it occurs, when drawing to an Image
(via a Graphics-Object for offscreen-double-buffering).

To grpOffScreen.fillRect( x, y, SIZEX, SIZEY)  1'000'000-times
JDK 1.2              2800 ms 
JDK 1.1.6             640 ms 
MS JVM 5.00.3165     1700 ms

This is very bad, because some JDK 1.1 software uses double-buffering
for optimizing AWT-drawing !!!
(Review ID: 57944)
======================================================================

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

WORK AROUND Name: vi73552 Date: 03/17/99 None found. ====================================================================== Name: skT88420 Date: 05/07/99 use JDK 1.1.7b (Review ID: 57944) ======================================================================
11-06-2004

EVALUATION Even if code doesn't use the new 2D APIs, it can still use the new 2D implementation. In particular, the Graphics class is all 2D code now. Reassigning bug. david.mendenhall@eng 1999-05-18 This seems to be fixed by the new architecture. jeannette.hung@Eng 2000-01-25 This test case is primarily testing the speed of creating a graphics object. Since a new Graphics object is created for every single fillPolygon, that is the dominant factor in the times. Moving the getGraphics call to be done once per run of the test we see that the performance of the two releases is much closer. Note that the new architecture will improve the speed of creating graphics objects so that it is as fast or even faster than the 1.1.x implementation. jim.graham@Eng 2000-03-01 The results for the version of the test case which does not create a new Graphics object for every polygon fill are very close between 1.1.x and the 1.2 releases. The results for the version which does create a new Graphics object for every fill (i.e. as originally submitted) is much slower in 1.2 and 1.3 releases. But the Merlin rewrite of the Graphics2D implementation brings the performance of that version back in line with 1.1.x. In fact, the test case is actually noticeably faster than 1.1.x due to optimizations in creating Graphics objects. jim.graham@Eng 2000-03-03
03-03-2000