Re: interactive game demo for gnuplot

[Juhász P. <pet...@gm...>]

On Sun, 2013-08-25 at 13:14 -0700, sfeam (Ethan Merritt) wrote:
> On Sunday, 25 August 2013, Juhász Péter wrote:
> > On Sun, 2013-08-25 at 10:29 -0700, sfeam (Ethan Merritt) wrote:
> > > On Sunday, 25 August 2013, Juhász Péter wrote:
> > > > On Thu, 2013-08-22 at 13:39 +0200, Petr Mikulik wrote:
> > > > > > Struck by sudden inspiration (and also motivated by the feel that the
> > > > > > "new" control flow capabilities are not advertised enough in the
> > > > > > existing demos), I wrote a small game demo, in pure gnuplot. I donate it
> > > > > > for the demo suite.
> > > > > 
> > > > > Really cool!
> > > 
> > > The other excellent feature of such demos is that they exercise parts
> > > of the program that don't otherwise get a lot of coverage in testing.
> > > The failure of "nibbles" on qt or wxt provided a convenient diagnostic
> > > tool for identifying and repairing a fundamental limitation on our
> > > mousing implementation.  So this week's gnuplot is that much better
> > > than last weeks, and all because of nibbles :-)    
> > > (which now, by the way, works fine on both qt and wxt). 
> > > 
> > > 	Ethan
> > > 
> > 
> > ... and just to underline the validity this statement, I've checked the
> > second (Xixit) demo with the latest CVS version, and found that
> > yesterday's change has the unwanted side effect that the shortest
> > possible pause interval is now 1/20 second, which effectively breaks the
> > game.
> 
> Really?   With which terminal?
> The 20 per second polling only kicks in if the requested pause
> is greater than 1/20 second. It should not affect shorter pauses.
> 
> ~~~~~~
>     if (term->waitforinput)             /* If the terminal supports it */
>         while (sleep_time > 0.05) {     /* we poll 20 times a second */
>             usleep(50000-1000);         /* Sleep for 49 msec */
>             check_for_mouse_events();   /* This sleeps for another 1 msec */
>             sleep_time -= 0.05;
>         }
>     usleep((useconds_t)(sleep_time * 1e6));
>     check_for_mouse_events();
> ~~~~~~
> 
> I did put an explicit 1 msec timeout in the individual terminal routines
> term->waitforintput().  I am not sure that this is a good idea, but the
> only scenario that I can see it affecting is a loop that would otherwise
> be limited purely  by computation speed.   This timeout can be 
> removed easily enough - I will experiment.

I tested with the x11 terminal.
I may have misinterpreted the symptoms: the apparent choppiness, and the
apparently longer pause after a triplet of block lands or cancels.

I do see something now that may hold a clue: press and hold the down key
to drop the blocks faster. In the old version I normally use the motion
appears smooth and the new blocks appear as soon as the old ones land,
meaning that the intended game logic works as intended.

In the new version the new blocks don't appear at all until you release
the down key, and then only after a noticeable pause (and the game logic
is apparently messed up, because several replots, among other things,
seem to be skipped.)

This indicates that the event handling somehow blocks the main thread.

> 
> However, running xixit here reveals a totally different problem.
> I get this after a couple of minutes when I run using the x11 terminal:
> 
>   gnuplot> load '/home/merritt/cvs/contrib/xixit.plt'
>   _XF86BigfontQueryFont: could not attach shm segment
>   XIO:  fatal IO error 12 (Cannot allocate memory) on X server ":0.0"
>       after 502085 requests (502084 known processed) with 1 events remaining.
> 
> That probably indicates either a failure to release memory somewhere
> in gnuplot_x11, or an event loop that isn't keeping up with the demo.
> I.e. it loops too quickly rather than too slowly.
> 
> > I don't know if pause intervals shorter than that have a real use case,
> > but perhaps this solution is not as solid as first thought.
> 
> I'm more worried that the 1/20 second limit you are seeing comes
> from something totally unintended.  That would mean that checking
> for mouse events in a computational loop, which was intended to
> be essentially free, may have a noticeable cost.

For what it's worth, I did some informal testing on the performance of
various versions with a synthetic test:

perl -le 'print "set term $TERM";for(1..5000){print "plot x,
".(sin($_/1000))."*x; $PAUSE"}' > fos; time $GNUPLOT fos

where $TERM was either wxt or x11, $PAUSE either "pause 0.005 or
nothing, and $GNUPLOT an old 4.5 version from 2011, cvs from 2013-08-22,
and current cvs.

Times are in seconds.

	wxt	wxt	x11(*)	x11
	nopause pause	nopause	pause
4.5	10.483	16.488	7.326	6.166
cvs/23	9.595	16.645	3.597	6.410	
cvs/25	12.387	19.387	9.969	8.665

(*) means that the iteration count was raised to 5000 in those tests to
get a comparable runtime.

So it looks that yesterday's modifications do incur some performance
penalty, both with and without pauses.




> 
> 	Ethan
> 
> 
> > Peter
> > 
> > 
>