On Wed, 14 Feb 2018, Allin Cottrell wrote: > On Wed, 14 Feb 2018, Sven Schreiber wrote: > >> we have vaguely mentioned some slowness of (GUI) gretl, but we (or I) >> haven't been able to pin things down. Maybe I now have something >> reproducible (on Windows 7 here, latest snapshot): >> >> 1) start gretl >> 2) open a dataset (don't know whether that's necessary) >> 3) open the console window (via toolbar button) >> 4) click on a menu >> -> It takes a noticeable time for the menu to open/unfold, and also when >> changing to a different menu. > > I'm not really seeing a problem on Linux, but the console enters a wait > loop to respond to commands and maybe the way that loop was defined was not > allowing sufficient cycles for updating the GUI. I've made a change that > might help in my working copy but unfortunately I can't push it right now > as sourceforge git access isn't working. Hm. I guess you mean <diff> @@ -436,10 +436,11 @@ static int console_get_line (void *p) /* wait for a command to be entered via the console */ while (!command_entered) { - if (gtk_events_pending()) { + /* 2018-02-14: was "if" rather than "while" below */ + while (gtk_events_pending()) { gtk_main_iteration(); } - g_usleep(1000); + /* g_usleep(1000); */ } command_entered = 0; </diff> After pulling this in, my gretl_x11 uses 100% of one CPU when the console is open.