6 Replies Latest reply on May 25, 2012 8:55 AM by 939356

    Painting across Dual Monitors is very slow

      Our application is displaying a very odd problem. I'll try to describe it to the best of my ability.

      Our application has a JFrame with a chart in it. The chart displays a cross-hair as the user moves the mouse over it, so any painting slow-down is very visible.

      If the chart is:
      - Only on my primary monitor, painting is fine.
      - JFrame starts in the second 1/2 of my primary monitor and stretches onto my secondary monitor, painting is fine.
      - Only on my secondary monitior, painting is fine
      - *Primarily on my primary monitor, but stretches onto my secondary monitor, painting noticibly slows down*

      We have an EDT monitor that we can turn on to monitor EDT performance, and when the painting slows down I see a lot of InvocationEvents for the WToolkit.

      Any ideas?

      Thank you for any help!
        • 2. Re: Painting across Dual Monitors is very slow
          could you quantitize your gerneralization of "noticably"?

          While I've not studied the JVM, my bet would be that it's just painting 2 seperate instances and using clipping to get rid of what is not shown and it's having a bit of problems with the division of the object. So what do do? You'd have to override the paint/paintComponent to get a better handling of the division of the work to render the two object instances.
          • 3. Re: Painting across Dual Monitors is very slow
            So to describe the situation, we have a JFrame with a Chart in it. Our chart shows a cross-hair as the the user moves the mouse around in the chart. When the chart is fully on one monitor, then the crosshair moves quickly, staying in sync with the mouse. However, when the chart is over two monitors, then the crosshair becomes sluggish and noticibly becomes out of sync with the mouse movement.

            This is our simplest way to reproduce the problem.

            However, the real user experience issue, is that our application supports MDI (JFrame with JInternalFrames). Customers then stretch the parent JFrame across both monitors. In this case, the JInternalFrame with the chart displays this same slowdown, even if the JInternalFrame is located on one monitor. This case isn't as consistent as the original scenario, but seems to occur most frequently after the user has locked their Windows account and then unlocked.

            I see the processor churning when we get into this state, and we have an EDT monitor that is showing the EDT is slowing down.

            This is the scenario we are trying to fix. Does this spark any ideas?
            • 4. Re: Painting across Dual Monitors is very slow
              When you use a profiler, what is causing the slowdown? Do you get more paints or do single paints become much slower? How is you chart painted - just an image with the cross hair painted on top or is the entire chart repainted each time?

              I guess because of the split over to monitors the painting is not hardware accelerated anymore, but that's just a guess.
              • 5. Re: Painting across Dual Monitors is very slow
                I have the same issue with an application.

                (i use a custom rendering thread synchronized with swing thread. I limit the fps around 30)

                A) When the application is on the primary monitor, it works very well (fps around 30).

                B) When the application is on primary and secondary monitors (so the frame size is 3200x1024); no problem (fps around 30)

                C) When the application is only on the second monitor, the fps falls around 11.

                Running the profiler shows a difference, i can't really explain why.

                On case C, sun.java2d.SunGraphics2D.drawImage() take 9499ms / 16000

                On case A and B, sun.java2d.SunGraphics2D.drawImage() no call

                Any clues ?

                After some testing, i notice JFrame switch from a sun.java2d.opengl.WGLGraphicsConfig (cases A & B) to java.awt.GraphicsConfiguration (case C) ...

                is there a workaround ? (maybe it's possible to recreate a new JFrame on second monitor to get a WGL acceleration, but in case of applet, afaik it's not possible)

                (Excuse me for my bad english)

                Edited by: 936353 on 24 mai 2012 04:47
                • 6. Re: Painting across Dual Monitors is very slow
                  I write response :

                  In fact, on simple dual monitor configuration, the primary display is hardware accelerated, the other is not.
                  It's a Direct 3D / Open gl limitation .
                  So when the Frame is fully (or the major part) on second monitor, rendering is done through the sofware rendering.

                  The only solution to have all display hardware accelerated is to use 3D vision or AMD Eyefinity.
                  (For gaming why not, but for application ...:( )