Re: using timers in the GUI

[John W. Eaton]

On 02/19/2013 02:26 AM, Jacob Dawid wrote:
> > 1) It is somewhat inefficient to be updating the workspace so often.
> > From the code, it appears that the workspace tree is rebuilt every
> > half second if Octave is sitting idle at the command line. If one's
> > workspace variables become numerous, not a difficult thing, that could
> > be a lot of unnecessary machine cycles. Being event driven is more
> > efficient.
>
> That is true, but at the time of development there was no possibility to
> have it work without making major changes (ie. implementing a
> thread-safe event system into octave core).
>
>
> > One way would be to do a variable-by-variable comparison in the GUI
> > code. A before and after tree, as it were. Another approach is that
> > if John could make the variable table shared memory and include some
> > flag for each variable that is changed or added whenever the value of
> > that object changes, it might be easier to figure out. Then again,
> > setting such a flag again-and-again within a big loop might be less
> > efficient than just doing a before and after variable comparison.
> > That design element can be a future project, but I think that using
> > some method other than a timer would be a good change early on.
>
> Comparing variable by variable was extremely inefficient for large sets
> of data, as I found out. It was much faster to drop the old data and
> renew it again. Anyways, I agree that your suggestion 1) would be the
> proper way to handle things.

Maybe I'm missing something, but what comparison is needed other than
comparing the lists of variable names, types, and sizes?  That is all
the information that is displayed, isn't it?

I still don't understand the use of the timer.  The attached patch
seems to work for me.  If I understand correctly the way things work
with the patch applied, an event will be triggered from the readline
idle loop to update the workspace view.  That function will then call
the workspace model to update the info stored there, then redisplay
it.  Currently this is just happening on each call, but we could limit
that to once per prompt instead of ten times per second when Octave is
sitting and waiting for input.

A similar approach could be used for the history widget.  The second 
patch attached to this message makes that change.  Again, I don't think 
it makes sense to update the history list ten times per second, or at 
some other arbitrary interval.  The list will only change when Octave 
accepts a line of input or when it is modified through some GUI menu 
item.  Shouldn't it be safe to process the GUI "update history" action 
when Octave adds the entry to the history list?  For changes made 
through GUI menus, we can schedule an event to process at the next 
"safe" time (readline event hook function, prompt function, or the point 
when Octave is accepting input).

If the list of events to process could be large, we could enforce a 
limit on the number of events that can be processed on any given trip 
through the readline event hook function.

If there is some reason that these changes can't work, I'd like to 
understand why.  It seems much simpler to call these functions without 
using timers.

jwe

workspace-diffs.txt
Description: Text document

history-diffs.txt
Description: Text document