Active Rendering with Swing (swing rendering off the EDT)

[CommanderKeith]

Thanks fletchergames. You are using Swing’s double-buffering then which must be some kind of VolatileImage rather than a BufferStrategy. I suppose I’ll have to do that kind of double-buffering also. It’s a real pity that Applets don’t have their own BufferStrategy like Windows. Because porting an app to become an applet is meant to be painless. I can’t see a reason why Applet should not have a BufferStrategy. Maybe I’ll post it as an RFE.

@fletchergames

You can call setIgnoreRepaint(false) on your main frame and then just call the repaint method during your main loop to do active rendering. (The repaint method still works when the repaint is ignored - it just doesn’t seem to get called unless you call it directly.)

Sounds like using repaint() is working for you, but its not really active rendering since your painting will be done in Swing’s Event Dispatch Thread. Repaint() will just put a paint request in the EDT’s EventQueue, rather than painting straight away on the thread that you called repaint from.

[fletchergames]

I thought you were supposed to paint to Swing components from the EventQueue because Swing components aren’t synchronized.

[CommanderKeith]

That’s right. That’s why you can’t paint Swing components in your without calling repaint() like what you’re doing or using the solution given here to synchronise the EDT with your game loop thread.

[Kova]

@fletchergames

I thought you were supposed to paint to Swing components from the EventQueue because Swing components aren’t synchronized.

except for the Applet thing, we’re discussing just that, painting swing in our thread

[CommanderKeith]

For the benefit of anyone still interested in this stuff, I just did a benchmark of

active-rendering Swing using the SynchronizedEventQueue vs passive rendering Swing using SwingUtilities.invokeAndWait(Runnable);

The active rendering was twice as fast (500FPS vs 250FPS). I hazard a guess that this is probably because synchronizing is quicker than starting a new thread which is run while the EDT pauses.

So the moral of the story is: if you want Swing in your game use active rendering like is done in the file SwingActiveRendering.java below!

The three files needed are attached below this message. (note that you won’t see them unless you’re logged in as a member)

Keith

[Kova]

@CommanderKeith

So the moral of the story is: if you want Swing in your game use active rendering like is done in the file SwingActiveRendering.java below!

I must add that this is tricky, and it doesn’t work all the times (example, my custom color picker doesn’t work, doesn’t render well). There is alternative which doesn’t mess with events and repaint managers, but you must subclass every swing component you are want to use. I described it here somewhere.

[beowulf03809]

@CommanderKeith

For the benefit of anyone still interested in this stuff…

Thanx! I am most definetly still interrested in this subject (just desperately lacking in time lately).

[Tennie]

Please don’t kill me for asking this question…

but in terms of practicality, what’s the difference between 500FPS and 250 FPS? arent both incredibly faster than the eye can process anyway?

Oh and I posted a question related to passive rendering in swing in the newless clubbies section, so if anyone has time, please check that out at: http://www.java-gaming.org/forums/index.php?topic=16269.0

Thanks a ton 8)

[Kova]

@Tennie

but in terms of practicality, what’s the difference between 500FPS and 250 FPS? arent both incredibly faster than the eye can process anyway?

250 fps = you can add more stuff to the game and keep it playable
500 fps = you can add twice as more stuff

[Corale]

I am giving this a bump while saying thank you guys! It’s a topic not to be forgotten, and that goes for the predecessor too.