One thing many of us have come across often is the restrictions of making a multithread capable language play nicely with the singlethread-minded opengl. Several bits of code have been floated about, but nothing really made it into the jme code base. Due to some recent tightening by lwjgl in regards to AWT, having something to ease moving GL code into the GL thread has become even more important (Swing/AWT WANTS to be multi-threaded…)
So, to get that started off, I've implemented a simple queue system. Basically it consists of an interface and a queue that holds instances of that interface. To use it, implement the interface com.jme.util.RenderThreadExecutable with it's single doAction method. Then as you need that action to occur, add the class to RenderThreadActionQueue via the static addToQueue method.
The LWJGLCanvas paintGL method already pulls an item off the queue and executes it for you. You can also do this in your own standard non-awt jme app by placing this in your render method:
RenderThreadActionQueue.processQueueItem();
That will only process one item per render call. Alternatively, if you want all waiting queue items processed, you can do:
while(!RenderThreadActionQueue.isEmpty())
RenderThreadActionQueue.processQueueItem();
This all works fine for simple things, but I'm sure we can improve on it. Feel free to throw up suggestions on this thread, especially I'd love to see how we could integrate suggestions already made elsewhere on the forum into this code (but please don't simply link to an old thread and say, "hey what about this..." ;))
What about using an InputHandler for this? Esp. it is by far more efficient regarding memory and cpu usage: The call
queue.remove(0).doAction();
is really expensive for a large ArrayList.
The drawback would be that the called objects would have to extend a class instead of implementing an interface.
And would we probably need multiple queues? This would not allow a singleton…
I know about your inputhandler JMEAction class, but IMHO it wasn't the way to go… A lot of extra code (listeners, synthetic buttons, etc.) for things that could be quite simple. I'm not sure where it would be either be less memory or cpu intensive since that method is still adding to the ArrayLists of the input system.
We could probably use a LinkedList though to alleviate concern on that.
As for mutiple queues, perhaps? Can you think of an example? It wouldn't be hard to keep the class a singleton though and allow for mutliple queues within it.
I shall sing your praises again renanse, like I haven't sung them since you introduced shadows. :-p
darkfrog
Nothing special, but it works at a basic level. :) LinkedList is done locally, will probably be committed by day's end
Oh, I did not mean to do it with JMEAction or with Actions at all (so no ArrayList and no synthetic buttons). I meant to use the Triggers (or a piece of code similar to them). As these are building a thread safe and efficient linked list.
But yes, you are right using a java.util.LinkedList would already improve cpu usage (at the cost of a bit more garbage). If you want to keep that class simple I'm fine with it, was just wondering if performance was an issue probably.
re more than one queue: right - could be a normal class with an additional static getter. I have no actual example for it though , just thought it could be useful…