JDK-6245040 : Gray rect fix causes delay in maximization
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2005-03-23
  • Updated: 2010-04-02
  • 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
Relates :  
JDK-6307563 - Unxpected IAE at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel
Relates :  
JDK-4967886 - Swing should provide full double buffering per window
Relates :  
JDK-6277252 - 6245040, maximization delay, is back
Relates :  
JDK-6245083 - Swing shouldn't blit during maximization
Description
After the gray rect fix (bug number 4967886) there is a noticeable delay in maximization on Windows (NT and 2000).

For example, consider SwingSet2:

- Move SwingSet2 to the center of the screen
- Hit the maximize button

Here's what happens:

1) The native Window holding SwingSet2 grows to fill the screen
2) The GUI content moves to the top left, but the rest of the Window remains damaged / not repainted.
3) GUI is repainted correctly to fill the entire window

Between steps 2 and 3, there is a noticeable delay (on my machine close to a second). This is a regression introduced by the gray rect fix.

I saw this problem on my NT machine. Dual processor. NVidia GeForce2-GTS.
###@###.### reports the same problem on Windows 2000. His machine information is attached as an HTML file.

Also attached is a screen-shot captured by ###@###.### during the delay between steps 2 and 3.
###@###.### 2005-03-23 19:28:02 GMT
Comments
EVALUATION Prior to Swing using a buffer strategy per window the back buffer would only be the size of the client area. Now that Swing uses a buffer strategy per window that is no longer the case. In particular BltBufferStrategy creates the image the same size as the window. It turns out that on Windows when you maximize the window the size of the window is actually bigger (wider) than the display size. On some machines this causes problems and appears to be what caused this slowdown. The fix is to change BltBufferStrategy to create the image the size of the client area. That way we don't trigger this bug. ###@###.### 2005-04-05 21:13:28 GMT
05-04-2005