GraphStream Users

Archives de la liste Aide

Re: Retrieving Mouse Clicks

Chronologique Discussions 
  • From: Antoine Dutot <antoine.dutot AT>
  • To: graphstream-users AT
  • Subject: Re: Retrieving Mouse Clicks
  • Date: Wed, 29 May 2013 08:04:10 +0200

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.


P.S. maybe we could think about the actor model...

Le 29 mai 2013 00:58, "guilhelm savin" <guilhelm.savin AT> 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.
You can find it here :

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.


2013/5/28 Sebastian Bock <sebastian.bock AT>
Hi there

Just a question to the example from the graphstream site. In the following example a while(true)-loop is used and AFAIK the pump() method is non blocking. This results in a loop which causes a 100% CPU usage.

Is this a normal behavior? Are there any other ways to retrieve mouse clicks without 100% CPU usage?

Thank you in advance

public class Clicks implements ViewerListener {
    protected boolean loop = true;
    public static void main(String args[]) {
        new Clicks();
    public Clicks() {
        // We do as usual to display a graph. This
        // connect the graph outputs to the viewer.
        // The viewer is a sink of the graph.
        Graph graph = new SingleGraph("Clicks");
        Viewer viewer = graph.display();
        // The default action when closing the view is to quit
        // the program.
        // We connect back the viewer to the graph,
        // the graph becomes a sink for the viewer.
        // We also install us as a viewer listener to
        // intercept the graphic events.
        ViewerPipe fromViewer = viewer.newViewerPipe();
        // Then we need a loop to wait for events.
        // In this loop we will need to call the
        // pump() method to copy back events that have
        // already occurred in the viewer thread inside
        // our thread.
        while(loop) {
    public void viewClosed(String id) {
        loop = false;
    public void buttonPushed(String id) {
        System.out.println("Button pushed on node "+id);
    public void buttonReleased(String id) {
        System.out.println("Button released on node "+id);


Archives gérées par MHonArc 2.6.16.

Top of page