JDK-4699831 : Win32: Vertical scrolling produces incorrect results on secondary screen
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0,1.4.2_06
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2002-06-10
  • Updated: 2008-07-17
  • Resolved: 2008-07-17
Related Reports
Duplicate :  
JDK-5086872 - Refactor Swing's painting code to be more pluggable
Duplicate :  
JDK-6229329 - JScrollPanes wider than the primary screen do not render correctly on multi-monitor systems.
Relates :  
JDK-6231735 - bad JFrame paint performance on Windows secondary screen
Description
Vertical scrolling in Swing apps doesn't work well when window is 
spanned across multiple screens on windows.

To reproduce, run SwingSet2 demo, go to the JTable tab. Resize the
app window to span across the screens and try to scroll vertically. Notice
that the image on the secondary screen is distorted.

My configuration: Win2K, GeForce 3 GTS + Matrox Millenium. DirectX 8.1.
The problem was reported on other configurations as well.


###@###.### 2002-06-10
Comments
WORK AROUND No workaround found so far. noddraw and ddoffscreen do not help. ###@###.### 2002-06-10 My customer has successfully worked around this by adding the following code to override the RepaintManager: /** * Returns the maximum double buffer size. * * @return a Dimension object representing the maximum size */ Dimension doubleBufferMaxSizeX = new Dimension(5000,5000); public Dimension getDoubleBufferMaximumSize() { return doubleBufferMaxSizeX; } ###@###.### 2005-2-22 10:40:31 GMT
22-02-2005
EVALUATION This appears to be a swing problem. Swing creates a backbuffer no larger than the size of the primary screen - see RepaintManager's _getOffscreenBuffer and getDoubleBufferMaximumSize() methods. The latter uses Toolkit.getScreenSize() to determine the maximum bb size. But when a window is spanned across multiple screen the area that needs to be updated may actually be larger than the backbuffer's width: the newly exposed area after the scroll, in this case. Note that this bug doesn't manifest on Unix with Xinerama because Toolkit.getScreenSize returns the combined dimensions of the visible area. Swing should either be calculating maximum repaint area and creating the appropriate backbuffer, or may be if the area to be repainted doesn't fit into the current backbuffer, split the area and render it in pieces. Reassigning to Swing for further evaluation. ###@###.### 2003-08-29 JViewport should handle tiling, if necessary. ###@###.### 2003-09-02 This was actually fixed as part of 5086872. I'm not closing out as a duplicate as there may be an escalation on this. ###@###.### 2005-2-22 18:38:41 GMT
02-09-2003