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.
  xxxxx@xxxxx   2005-2-22 17:20: customer  GMT

Drag the window to the primary display and back.  Which isn't acceptable to the customer.
  xxxxx@xxxxx   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.
  xxxxx@xxxxx   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);

  xxxxx@xxxxx   2005-03-02 16:02:08 GMT
  xxxxx@xxxxx   2005-03-02 16:03:21 GMT

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

  xxxxx@xxxxx   2005-2-28 15:14:00 GMT

I have experienced this exact same problem, and was required to use the appropriate GraphicsConfiguration to get it to work.  However, just creating a no-arg JFrame() and then using setLocation() to place it on a secondary screen, causes all the problems listed above.  This problem persists using JDK1.5.0_03... So, NOT FIXED.

BTW, my video card is: ATI Movility Radeon 9600 Series

I have experienced this exact same problem, and was required to use the appropriate GraphicsConfiguration to get it to work.  However, just creating a no-arg JFrame() and then using setLocation() to place it on a secondary screen, causes all the problems listed above.  This problem persists using JDK1.5.0_03... So, NOT FIXED.

BTW, my video card is: ATI Movility Radeon 9600 Series

- Eric Bergerson eb@object.com

Note that the bug this one is closed as a duplicate of (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4868278) has been fixed in mustang (Java6) and 5.0u5, and you're apparently using 5.0u3, so no surprise it's not fixed for you.

Thanks,
  Dmitri
Java2D Team

I am experiencing a rather similar problem with Mustang, too. Reproducing the problem is as easy as creating a JFrame like this:

new JFrame().setVisible(true);

Whenever I try to resize the frame on the primary monitor, it resizes very slowly. If I try to repaint() it, that's also very slow.

However, if I move the empty frame to the secondary screen, resize works just fine and repaint() also works fine. If I move the frame back to the primary screen, the problem returns too, without exception.

This is on Windows XP SP2 with JRE 1.6.0_07 and with an ATi Mobility Radeon X1400, Lenovo drivers (2D Driver Version: 6.14.10.6764).