Ok, don't panic, it is not a bug, it's a feature :-)
This part of the tutorial was never intended to be run and used as it is. I recently changed it so that it compiles for another developer. But I admit it is not very clear. It is too small and nobody would want to run such a loop. Most of the time you even do not have such a loop and just call pump() before using your graph to synchronize it with the GUI (in another thread).
But when you have such a loop, the idea is that you run your simulation in this loop, and in this case you *do not want* the pump to be blocking, you temporize your loop by yourself. (Here indeed, the loop does nothing else, and therefore if you run it alone, it makes you computer hotter than needed.) In a real development scenario you use the pumping mechanism in the "main" thread, not the GUI thread, because you need such a non blocking behavior.
However, in the case where you want to use an event based model (blocking), for prototyping for example, the behavior proposed by Guilhelm is a good start but we have to document it, and in this case a system with listeners like in GUI would be better.
Indeed, as soon as GraphStream is blocking, it controls your loop (you cannot tell when your code in the loop will be allowed to run). But again, in this case you should better put your code in the GUI thread and avoid this plumbing and pumping machinery only intended to run your own non blocking simulation thread.
I will modify the tutorial to be clearer on this matter.
In the future, after a discussion, we could either add a BlockingViewerPipe as proposed by Guilhelm or a blockingPump() method, but we have to really document it, and maybe have a whole tutorial explaining the two or three ways to run a program in GraphSteam, since I thing the non-blocking pump must stay.
Antoine
P.S. maybe we could think about the actor model...
Le 29 mai 2013 00:58, "guilhelm savin" <
guilhelm.savin AT gmail.com> a écrit :
I think it's a really normal behavior if you want to turn your laptop into a heater.
But well .... we agree : this is not the aim of GraphStream.
I think there is a real problem in this case. We have to discuss it with other dev but I made a draft hack of ViewerPipe with a blocking pump method.
To use it, just change this line :
ViewerPipe fromViewer = viewer.newViewerPipe();
into :
ViewerPipe fromViewer = new BlockingViewerPipe(viewer);
Your CPU load should fall to a more acceptable rate.
Thanks for reporting this behavior.
Hope this helps.
Regards.
Guilhelm
...