[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rik
Subject: [Octave-bug-tracker] [bug #55940] pause() takes too long if you call it a bunch
Date: Mon, 18 Mar 2019 11:50:57 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

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

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

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);
    set (him, "cdata", cdata);

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

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

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:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]