JDK-6792551 : JDesktopPane and getGraphics() bug
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u10
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2009-01-12
  • Updated: 2011-02-16
  • Resolved: 2009-01-14
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
XP SP3 Family, NVIDIA GeForce 7300 LE

A DESCRIPTION OF THE PROBLEM :
First, sorry for my english, I am french.

when i using a JDesktopPane, if I call the method getGraphics() from a component linked with this (child or parent?), moving of internal frame will lag (only if setDragMode is defined to JDesktopPane.OUTLINE_DRAG_MODE).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See source code to reproduce this bug

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Moving the internal frame don't lagging
ACTUAL -
Moving the internal frame lagging

ERROR MESSAGES/STACK TRACES THAT OCCUR :
No error message

REPRODUCIBILITY :
This bug can be reproduced always.

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

import javax.swing.JDesktopPane;
import javax.swing.JFrame;
import javax.swing.JInternalFrame;
import javax.swing.JPanel;


public class BugTester
{
	public static void main(String[] args) throws Throwable
	{
		// Creation of panel
		JPanel panel = new JPanel();

		// Creation of internal frame
		JInternalFrame internalFrame = new JInternalFrame("My child frame");
		internalFrame.getContentPane().add(panel, BorderLayout.CENTER);
		internalFrame.setVisible(true);
		internalFrame.setLocation(20, 20);
		internalFrame.setSize(300, 300);

		// Creation of desktop pane
		JDesktopPane destopPane = new JDesktopPane();
		destopPane.setDragMode(JDesktopPane.OUTLINE_DRAG_MODE);	// IMPORTANT !!!! don't bug if not defined
		destopPane.add(internalFrame);

		// We show internal frame
		internalFrame.setSelected(true);

		// Frame
		JFrame frame = new JFrame("JDesktopPane and getGraphics() bug tester");
		frame.setSize(500, 500);
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setLocationRelativeTo(null);
		frame.setContentPane(destopPane);
		frame.setVisible(true);

		// Waiting 2000 ms
		System.out.println("Waiting 2000 ms...");
		Thread.sleep(2000);
		System.out.println("Wait OK ! Moving the internal frame must lag now...");

		// Getting graphic context from panel
		panel.getGraphics();
	}
}

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

CUSTOMER SUBMITTED WORKAROUND :
don't using getGraphics()

Release Regression From : 6u6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.

Comments
EVALUATION After deeper look the main reason of this problem was revealed, all said above is true, we really turn off double buffering in this case, but java2D introduced a regression in 6u10 after which XOR operation performes very slow for the default pipeline and it leads to a such dramatic lag I verified that -Dsun.java2d.d3d=false as a java paramater fixes the problem closed as duplicate of 6635462
14-01-2009

EVALUATION One of the big features of the JDK 6 was the "true double buffering" see #4967886 for more information The idea of that fix is to have a back buffer per window, so when the window is exposed we no longer generate a paint event, instead we copy directly from the offscreen buffer This works when the users follow Swing painting guidlines (override paintComponent(), call repaint() etc...) but fail when they paint directly to the screen When the user calls getGraphics() on a component it disables the double buffer of the parent rootPane (by the way the Thread.sleep() is unnecessary) see JComponent.getGraphicsInvoked() The best way to never have this problem is to never call getGraphics() and follow the Swing painting guidelines downgraded to P4
13-01-2009