Revision as of 22:39, 6 October 2009 by Admin (Talk | contribs)

Jump to: navigation, search


jPCT's renderers are single threaded unless you are using the AWTGLRenderer (or the JOGL-support). In that case, rendering and calculations are split into two different threads. This isn't done just for fun, but because the actual drawing has to happen in the AWT event dispatch thread, which usually isn't the thread that executes your game logic. When using one of these renderers, make sure that any GL and LWJGL(JOGL related code is executed in the dispatch thread too. To do this, put it into one of the methods that the IPaintListener-interface offers instead of executing it directly in your main thread.

It is possible to use multithreading in the "normal" GL renderer too. Just set Config.useMultipleThreads to true before initializing the renderer. All said above about the AWTGLRenderer then applies to the normal renderer too.

The software renderer doesn't support any kind of multithreading.

The threading framework

jPCT comes with a simple threading framework. It's not used ATM. If you feel the urge to use it, feel free to do so, but it's not tested very well. Use it at your own risk.

Thread safety

Just like Swing, jPCT isn't thread safe. That means, that you must not modify any jPCT object from any other thread than the thread that executes the render loop. Keep in mind, that all key and mouse listeners are running in the AWT event dispatch thread, i.e. not in your main thread. Don't modify jPCT objects from within these listeners' methods unless your render loop is executed in that thread too (which i don't recommend, but some people are doing it this way). If you want to modify a jPCT object based on mouse or key events, just set a flag in the listener and do the actual modifications in your render thread...or synchronize everything correctly, which can be much more painful and error-prone.