[Octave-bug-tracker] [bug #55940] pause() takes too long if you call it a bunch

[Rik]

Update of bug #55940 (project octave):

                  Status:            Works For Me => Confirmed              

    _______________________________________________________

Follow-up Comment #5:

So, I guess we can confirm this as being real, but only for Mac platforms.

The Octave code for the sleep() call is in libinterp/corefcn/utils.cc
(sleep).

As a further test, could you try changing the pause amount to an integral
number of seconds (i.e., try 1) and see what happens?

Looking at the code, it is much more complicated than one would have first
thought.  I imagined that Octave was just calling the library function sleep
or nanosleep with the appropriate delay.

Instead, in order to have the interpreter respond interactively to signals
(such as Ctrl+C), the total delay is split in to 100 millisecond segments and
after every segment Octave checks whether there has been a signal event.  It
*also* runs any GUI or plot events if the do_graphics_events input to the
function is true.  That could be where the variable delay is getting
inserted.

I think, irregardless of the fact that this seems to work on Linux, that this
is not the right strategy.  I think we should use something similar to what
Pantxo coded for movie.m which I will quote below.


  ## Initialize the timer
  t = tau = 1/fps;
  timerid = tic ();

  for ii = idx
    cdata = mov(ii).cdata;
    if (isempty (cdata))
      error ("movie: empty image data at frame %d", ii);
    endif
    set (him, "cdata", cdata);

    if (! isempty (mov(ii).colormap))
      set (hax, "colormap", mov(ii).colormap)
    endif

    pause (t - toc (timerid));
    t += tau;
  endfor


The point is that any work done in the loop is accounted for and reduces the
length of the pause.  If the time to pause is negative--because so much work
was done in the loop--then pause is skipped which gets the delay engine back
on track.

This would need to be re-coded in C++, but it isn't that hard. 


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?55940>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/