Expensive Controls?

I need a both CPU and time expensive Control in my application. That control is attached to a Node that has many subordinate Nodes. The control performs some very complex computations of relations between the subordinate Nodes. However, afaik controls are processed in the render thread, so this expensive control drops the framerate considerably.

My main question is: how to avoid framedrop? For now I think to delegate computations to parallel threads from inside the control, and then, when the results are ready, apply them. However that may lead to some loss of real-time-ness because of the current computations being locked with the latest tpf (time per frame), and not being able to somehow incorporate the real length of time that was taken… and anyway it is impossible to predict how much time exactly the computation would take. For this particular case I can tolerate the not-realtime-ness of that, but I am also interested in any advices to somehow retain at least some closer match with realtime.

One possibility would be to collect all tasks then process them with a threadpool/similar, and block the rendertread untill all of them are done. That way you can at least do 2-8 parralel instead of sequential without a loss in temporal coherence (assuming the controls are independent from each other)

its impossible to make a suggestion really without any kind of specifics of what youre trying to accomplish.

But i think it’s likely youre looking at JMEs purpose the wrong way. The JME game loop is for visualizing/displaying your simulation. It’s not where the simulation actually exists. JME and your game simulation should use thread safe methods to interact with one another. You shoudln’t put the simulatiion inside of jme as a way to avoid having to deal with thread safety…

@Empire Phoenix: I separated the thread. There is still the framedrop because of the general CPU load, but it is far less significant (sevral magnitudes less). However, now, while all is fine, the movements of the objects, affected by the control are glitchy - they jump, because of the well-known reasons that the computation can take several render cycles to complete. Oh well, at least it is something!

@icamefromspace: no rpoblem, I can do well with any kind of multithreading, so I did just that (refer to the paragraph above). So yes, you are right, I am taking the simulation away from JME threads, but it loses time coherence. I guess there is no cure for that, unless I build some kind of a distributed system which will be able to handle the load seamlessly.

Lag the visualization a bit and interpolate positions. It’s so common there should probably be something built in.

Or block the renderthread untill all computations are done, at least you can now do 4 instead of 1 on quad cores, might be enough