Bug ID: JDK-4967886 Swing should provide full double buffering per window

JDK-4967886 : Swing should provide full double buffering per window

Type: Enhancement
Component: client-libs
Sub-Component: javax.swing
Affected Version: 1.1,1.1.6,1.2.0,1.3.0,5.0,5.0u1,6

Priority: P3
Status: Resolved
Resolution: Fixed
OS:
generic,linux,solaris_2.6,solaris_7,solaris_10,windows_98,windows_nt,windows_2000,windows_xp generic,linux,solaris_2.6,solaris_7,solaris_10,windows_98,windows_nt,windows_2000,windows_xp
CPU: generic,x86,sparc

Submitted: 2003-12-12
Updated: 2019-05-14
Resolved: 2005-04-13

Versions (Unresolved/Resolved/Fixed)

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.

JDK 6
6 b32Fixed

Related Reports

Duplicate :	JDK-6497150 - Flickering by resizing JWindow or JFrame
Duplicate :	JDK-4155103 - JFrame, JDialog, JWindow, and JApplet don't use RepaintManager
Duplicate :	JDK-6267126 - Flickering when a new JFrame is launched
Duplicate :	JDK-5091604 - Swing applications paint grey rectangles before actual content gets painted
Duplicate :	JDK-6215263 - REGRESSION: paint() method not called on JFrame on JDK 1.5
Duplicate :	JDK-2120486 - Swing applications paint grey rectangles before actual content gets painted
Duplicate :	JDK-6329495 - Improve painting performance (fix gray boxes)
Duplicate :	JDK-4718434 - Component.BltBufferStrategy doesn't clean up VolatileImage's on strategy switch
Relates :	JDK-4463500 - ColorChooser Demo in the SwingSet 2 Demo does not repaint correctly on Dual CPUs
Relates :	JDK-6290253 - Yokogawa applet fails to repaint in Mustang
Relates :	JDK-6331762 - REGRESSION: Wrong FontMetrics set when painting custom components in JScrollPane
Relates :	JDK-6575402 - Top-level Memory Leak in BufferStrategyPaintManager
Relates :	JDK-6245040 - Gray rect fix causes delay in maximization
Relates :	JDK-6363382 - JApplet fails to draw as expected on Windows
Relates :	JDK-6415012 - REGRESSION: Screen flickers in FullScreen mode when using 6.0
Relates :	JDK-5008179 - Regression: Synchronization change to SwingSet2 causing repaint problems
Relates :	JDK-6409815 - REGRESSION: JSplitPane.setDividerLocation is no longer respected
Relates :	JDK-6354265 - REGRESSION: Display artifacts occur with IntelliJ and 1.6
Relates :	JDK-6401996 - REGRESSION: painting of backgrounds spill outside drop down list bounds
Relates :	JDK-6261582 - Enable buffer-per-window (aka the gray rect fix) on unix platforms
Relates :	JDK-6415339 - Swing doesn't refresh properly
Relates :	JDK-6226290 - OGL: optimize FlipBufferStrategy/COPIED
Relates :	JDK-6462383 - Unbounded memory leak in Windows XP JRE for Applets and applications that open JFrame's
Relates :	JDK-4960743 - Should consider using backing store on XAWT
Relates :	JDK-6255371 - REGRESSION: JDialog shows painting artifacts on first showing
Relates :	JDK-6351820 - 6351820: JFrame is painted incorrectly the first time.

Description

Swing provides double buffering on an application basis.  Performance could
be greatly improved if double buffering were provided on a per window basis
and if native expose events copied directly from the double buffer.

Comments

EVALUATION On desktops that provide hardware acceleration blitting is almost free, so that if swing maintained a buffer per window exposes become almost free. To enable this we would need to change the RepaintManager to maintain a buffer per window and change the painting architecture to paint the component at it's location in the window. ###@###.### 2003-12-12 Here's the set of API changes made for this: java.awt.Window.getBufferStrategy() and java.awt.Canvas.getBufferStrategy() will go from: /** * @return the buffer strategy used by this component * @see #createBufferStrategy * @since 1.4 */ to: /** * Returns the <code>BufferStrategy</code> used by this component. This * will return null if a <code>BufferStrategy</code> has not yet * been created or has been disposed. * * @return the buffer strategy used by this component * @see #createBufferStrategy * @since 1.4 */ public BufferStrategy getBufferStrategy(); java.awt.image.BufferStrategy and it's two public subclasses java.awt.Component.BltBufferStrategy and java.awt.Component.FlipBufferStrategy will get the new method: /** * Releases system resources currently consumed by this * <code>BufferStrategy</code> and * removes it from the associated Component. After invoking this * method, <code>getBufferStrategy</code> will return null. Trying * to use a <code>BufferStrategy</code> after it has been disposed will * result in undefined behavior. * * @see Component#createBufferStrategy * @see Component#getBufferStrategy * @since 1.6 */ public void dispose(); All will share the same doc. javax.swing.JFrame, JDialog, JWindow and JApplet will now override repaint: /** * Repaints the specified rectangle of this component within * <code>time</code> milliseconds. Refer to <code>RepaintManager</code> * for details on how the repaint is handled. * * @param time maximum time in milliseconds before update * @param x the <i>x</i> coordinate * @param y the <i>y</i> coordinate * @param width the width * @param height the height * @see RepaintManager * @since 1.6 */ public void repaint(long time, int x, int y, int width, int height); And javax.swing.RepaintManager will get the following class level javadoc: * As of 1.6 <code>RepaintManager</code> handles repaint requests * for Swing's top level components (<code>JApplet</code>, * <code>JWindow</code>, <code>JFrame</code> and <code>JDialog</code>). * Any calls to <code>repaint</code> on one of these will call into the * appropriate <code>addDirtyRegion</code> method. And two new methods: /** * Adds <code>window</code> to the list of <code>Component</code>s that * need to be repainted. * * @param window Window to repaint, null results in nothing happening. * @param x X coordinate of the region to repaint * @param y Y coordinate of the region to repaint * @param w Width of the region to repaint * @param h Height of the region to repaint * @see JFrame#repaint * @see JWindow#repaint * @see JDialog#repaint * @since 1.6 */ public void addDirtyRegion(Window window, int x, int y, int w, int h); /** * Adds <code>applet</code> to the list of <code>Component</code>s that * need to be repainted. * * @param applet Applet to repaint, null results in nothing happening. * @param x X coordinate of the region to repaint * @param y Y coordinate of the region to repaint * @param w Width of the region to repaint * @param h Height of the region to repaint * @see JApplet#repaint * @since 1.6 */ public void addDirtyRegion(Applet applet, int x, int y, int w, int h); JComponent's setDoubleBuffered was documenting a bit too much implementation. The old spec is: /** * Sets whether the this component should use a buffer to paint. * If set to true, all the drawing from this component will be done * in an offscreen painting buffer. The offscreen painting buffer will * the be copied onto the screen. * Swings painting system always uses a maximum of one double buffer. * If a <code>Component</code> is buffered and one of its ancestor * is also buffered, the ancestor buffer will be used. * * @param aFlag if true, set this component to be double buffered */ public void setDoubleBuffered(boolean aFlag); I'm going to remove the line: * Swings painting system always uses a maximum of one double buffer. javax.swing.JRootPane will now override setDoubleBuffered. It will have the same spec as JComponent: /** * {@inheritDoc} * @since 1.6 */ public void setDoubleBuffered(boolean aFlag); As a result of this work Swing's RepaintManager will manage painting of top level components (JFrame, JDialog, JApplet, JWindow). When appropriate Swing will use a BufferStrategy for these windows and when an expose event is received copy directly from the back buffer! ###@###.### 2005-03-15 00:55:46 GMT

15-03-2005