JDK-6231735 : bad JFrame paint performance on Windows secondary screen
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2_06
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-02-22
  • Updated: 2010-05-07
  • Resolved: 2005-02-28
Related Reports
Duplicate :  
JDK-4868278 - Problem with Action button tooltips with some multiple monitor configurations
Relates :  
JDK-4699831 - Win32: Vertical scrolling produces incorrect results on secondary screen
Relates :  
JDK-4895978 - High CPU utilization with Matrox graphic adapters and Multiple Display
Description
When run on most XP systems with multiple displays, starting this Java application on a non-Primary display, and clicking [Start], the repaint of the objects in the table is very slow.  Drag the JFrame to the Primary display and it's far faster, and dragging it back to the Second or whichever other screen leaves it running faster for the lifetime of that JFrame.  Sometimes the painting performance is fine to start with, but if you cause another window to take focus - especially if it pops over the JFrame in so doing - then at that point performance drops off considerably.

This has been seen mostly with Matrox and NVidia dual-display cards.  Less luck is had reproducing with ATI-based cards.
###@###.### 2005-2-22 17:20:02 GMT
Comments
EVALUATION Submitter indicates this happens with specific video cards, so, sounds like more of a 2D issue. We should verify they are using 1.4.2_06. It sounds a lot like 4895978, which was fixed in 1.4.2_02. ###@###.### 2005-2-25 21:56:05 GMT This is a duplicate of 4868278: Problem with Action button tooltips with some multiple monitor configurations which has been fixed in mustang by awt. However, the fix hasn't been integrated yet (will be into b26, I think). I've verified that the fix addressed the problem with awt's nightly build: /net/jano.sfbay/export/disk26/awt/MUSTANG-NIGHTLY-BUILDS/2005-02-22-Tue.mustang ###@###.### 2005-2-28 15:14:00 GMT
25-02-2005
WORK AROUND Drag the window to the primary display and back. Which isn't acceptable to the customer. ###@###.### 2005-2-22 17:20:02 GMT Change the Frame creation to something like: JFrame j = new JFrame(); j.getContentPane().setLayout(new BorderLayout()); j.getContentPane().add(s, BorderLayout.CENTER); j.getContentPane().add(b, BorderLayout.SOUTH); j.pack(); j.setResizable(false); j.setResizable(true); j.setBounds(point.x, point.y, 400, 400); j.setVisible(true); and it works fine. ###@###.### 2005-03-02 15:37:43 GMT Another way to do it is to use proper APIs for dealing with multiscreen configurations - GraphicsDevice, GraphicsConfiguration classes. For example, here's how to create a frame on the second screen: GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); GraphicsDevice gd[] = ge.getScreenDevices(); // make sure there's a second screen - if the size of // the GD array is > 1, than there is. Device 0 is the // default screen. GraphicsConfiguration secondScreenGC = gd[1].getDefaultConfiguration(); // this is the key, to pass a GraphicsConfiguration // object associated with the desired screen to // JFrame (or any other toplevels) constructor. JFrame j = new JFrame(secondScreenGC); j.setVisible(true); One can also use the following method to position the toplevel window relative to the screen's origin: GraphicsConfiguration.getBounds(); Prior to showing: Rectangle secondScreenBounds = secondScreenGC.getBounds(); j.setLocation(secondScreenBounds.x+ 100, secondScreenBounds.y+100); j.setVisible(true); ###@###.### 2005-03-02 16:02:08 GMT ###@###.### 2005-03-02 16:03:21 GMT
22-02-2005