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: 2017-05-16
  • Resolved: 2005-04-13
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 :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
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
2005-03-15