JDK-4895978 : High CPU utilization with Matrox graphic adapters and Multiple Display
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.2,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: generic,x86
  • Submitted: 2003-07-24
  • Updated: 2013-11-01
  • Resolved: 2003-08-27
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.
Other
1.4.2_02 02Fixed
Related Reports
Duplicate :  
JDK-4899321 - issue Swing back buffer issue has performance impact
Relates :  
JDK-6231735 - bad JFrame paint performance on Windows secondary screen
Description
We have a customer application which when invoked with 1.4.2 show high
CPU utilization. The utilization range upto 80% at times and has an average
of 38%.

Some basic profiling made with Optimizeit shows Java 2D method like
sun.java2d.pipe.DrawImage.blitSurfaceData consuming high CPU (37.9%).

The problem was reproduced in-house with the following configuration:

Pentium 4 2.8 GHz 
1 GB RAM
Windows 2000 SP2
Matrox G200 Adapter
3 Display Monitors

The steps to download, configure and run the test case is provided in the comments section.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger FIXED IN: 1.4.2_02 tiger INTEGRATED IN: 1.4.2_02 tiger tiger-b19
14-06-2004
EVALUATION I believe this is a dup of a similar one filed against the way that Swing manages the Volatile back buffer on multiscreen systems, but I am forwarding the bug to Swing to let them make that call. ###@###.### 2003-08-05 This is likely only applicable to multi-headed machines. Swing uses the same VolatileImage on all GraphicsConfiguration, which causes us to recreate the VolatileImage every time we render on the other monitor. The fix is to cache VolatileImages per GC in the RepaintManager. ###@###.### 2003-08-12
12-08-2003