I'm guessing this is going to be more directed towards Irrisor, but perhaps someone else has enough experience with the Swing integration for jME to tell me if this might help. As anyone who has done much with the jME Swing integration knows it can drop your FPS significantly and I was wondering if splitting out all the jME Swing integration aspects out into another thread might increase performance? To me this seems like the only major down-side to the Swing integration is the major impact it can have on the game's performance when interacting with Swing.
I'm afraid the slow-downs occur because of how heavy Swing is and that we're really not going to be able to do much to fix that, but the idea came to mind so I thought I'd mention it.
I'm not sure what the slowdown you are seeing. By default the swing stuff is in another thread, at least the AWT event stuff is. Are you talking about the part where it's rendered to a texture?
I'm still getting very good performace out of swing w/ jME. Any slowdowns are all related to the complexity of the 3d scene. I have different JPanels in my desktop that I show/hide as needed. And I'm using synth look and feel which theoretically might make swing slower.
What slowdown are you seeing?
Swing already has its AWT thread, but what I see JMEDesktop causes a performance only hit if you update components very frequently.
One example: I use JProgressBar on a JInternalFrame for a status in the game. As long as I updated it every frame the FPS was bad. I changed the update function to compare the previous value with the value to set and only update if there is a difference. This way my game is at the same speed than without the progress bars i.e. there is no performance hit.
You can easily find such things with a profiler. If it spends a considerable CPU time in the AWT thread you are updating too rapidly.
With the Swing integration you have to be careful as it can slow down your game. I don't think that threading would help in this regard. You just have to think what to update when. It doesn't make sense to update a Swing component hundreds of times a second anyway.
All my swing updates are event driven so that updates to the swing gui only happen from 'time-to-time'.
I've used a standard method of subverting the AWT system event queue to allow for the render/update system (which actually handles the mouse) to tell my swing about things within the render/update thread. This is how I update my my progress bar during a thread loading scene nodes.
I also use this as I do pixel level picking and need to update the swing dynamically based on MouseInput.onMove() override within my InputHandler.
I can do this kind of dynamics with virtually no overhead.
See:
Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent()
Limit updates and Swing events. Eg. see http://www.jmonkeyengine.com/jmeforum/index.php?topic=3854.0
Yes llama… I know .
Thus in the I check against the desktop with
public boolean isOnUI( int x, int y) {
y = desktopPane.getHeight() - y;
Component comp = desktopPane.getComponentAt( x, y);
if( comp != null && !comp.equals( desktopPane) && comp.isVisible() && comp.isEnabled()) {
return true;
}
return false;
}
to determine in which cases to even bother with local 'in scene' mouse events or 'ui' mouse events, when needed.
It's a directionality thing. I don't allow the desktop to respond to onMove(), it's my scene that determines when onMove() would generate a particular update with the UI.
Most of that is very dependant upon the implementation for the purposes of the game.