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.

N/A

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.
  xxxxx@xxxxx   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
     */
 

 
    /**
     * 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!
  xxxxx@xxxxx   2005-03-15 00:55:46 GMT

Will this fix also be available in JDK 1.5.x?

Is it possible to have this fix in an updated 1.5 release?

Thanks in advance,
Marco

Sir,
can I use the existing netbeans project  that developed in netbeans 5.5 and jdk 1.5._06 for this bug fixed version jdk-6u1-ea-bin-b02-windows-i586-debug-12_jan_2007.jar.

I have the problem of  hanging the  jframe   sometimes.

Can you just explain little bit what i  need to for JDK1.5 to resolve this issue

Can you just explain little bit what i  need to do for JDK1.5 to resolve this issue