Madjack, your perspective is wrong, you dont have to update stuff, the render thread does it for you, you simply should not block it 
Its like a java application where you press a button and the whole UI freezes while the file is downloaded because you did it on the EDT/AWT thread or an OSX application where you block the runloop with a UI binding. Its common practice to have the “update loop” and run extensive processes on other threads.
normen said:
Madjack, your perspective is wrong, you dont have to update stuff, the render thread does it for you, you simply should not block it ;) Its like a java application where you press a button and the whole UI freezes while the file is downloaded because you did it on the EDT/AWT thread or an OSX application where you block the runloop with a UI binding. Its common practice to have the "update loop" and run extensive processes on other threads.
normen, you won't hear me argue against that. But for some, me included, this is not something we might be aware of. A mention of it would be most welcome in the wiki.
My original thoughts were, since Nifty was now part of jME3, that updating would be taken care of by itself. Not something I would have to worry or take care of.
Anyway. The problem has been solved and hopefully what I went through will help someone else. :)
Cheers too you all!
Again, you dont have to update anything yourself. If you use nifty as shown in the example its done for you. You dont have to call nifty.update() as that is done in the Nifty AppState. But you should not keep the application from doing that by blocking the thread. The idea of the main loop is the first tutorial really…
I don’t use nifty.update. Nifty isn’t even known to the main class.
I’m using an Atomic class that holds the variables telling my event manager that there were some changes in the GUI. In update() I check that Atomic class if there was a change since last time it went through and if there is, let update() go through updateGUI().
It’s not pretty, but it works.
Just use the normal enqueue() method when you are on another thread to do the GUI updates… These will be worked off at the right moment when the update() loop is running:
[snippet id=“10”]
normen said:
Just use the normal enqueue() method when you are on another thread to do the GUI updates.. These will be worked off at the right moment when the update() loop is running:
[snippet id="10"]
*sigh*
I've been acquainted with Callable for barely 12 hours and you throw some more at me. :P I wonder which way would work faster though... Ahhh! Don't do that to me normen. :P