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.
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.
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 ...:( )