Re: using timers in the GUI

[Torsten]

On 20.03.2013 17:59, Daniel J Sebald wrote:
> On 03/20/2013 03:22 AM, John W. Eaton wrote:
>> 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?
> 
> One feature I'm imagining is placing the cursor above a variable in the
> workspace and the tool tip displays the variable's contents in some way.
>  However, I don't think that requires comparison at all, just retrieving
> data.

The contents of the variables are displayed, too.

> 
>> 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.
> 
> Those changes look good.  They are pretty much what was discussed as a
> more event-driven scheme, and use Qt signal/slot as designed.  If it
> seems to run properly, go with it.  The timer code will always be in the
> repository if some issue comes up.

Yes, the patches work fine and should also fix bug #38537.
Octave now consumes approximately 12% of cpu time on my system with only
a few variables in the workspace (without the patch 3..4%). So limiting
to one update per prompt would be helpful.

Torsten