This content has been marked as final. Show 6 replies
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.
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?
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.
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
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 ...:( )