Re: [lmi] UI updates during long operations

[Greg Chicares]

On 2018-06-26 23:08, Vadim Zeitlin wrote:
> On Tue, 26 Jun 2018 22:33:39 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> In the changeset I'm just about to push, I've
> GC>  - reverted the busy-cursor commit that started this thread;
> GC>  - called wxWindow::Update() when writing to the statusbar as you 
> suggested;
> 
>  This is the point where I should mention that I haven't actually tested
> this. Update() is supposed to work, but there can sometimes be
> complications with the native controls (of which wxStatusBar is one). Did
> it actually solve the problem of "missing" updates?

No. The problem has been solved (the statusbar now shows a smooth iteration
count, instead of the "choppy" count noted previously), but calling Update()
is not the change that solved it--at least not with 'wine'. If I experimentally
suppress the Update() call recently added in 'alert_wx.cpp':

                 b->SetStatusText(s);
-                b->Update();
+//              b->Update();

and retest, the statusbar still updates smoothly. Apparently it was the
removal of the bogus wxSafeYield() call that solved the problem.

I'm not inclined to remove the Update() call, though, unless we find that it
actually causes a problem. It seems natural and correct. And it doesn't have
seem to have any effect on the overhead of displaying data on the statusbar.

> GC>  - added a status-bar counter in CensusView::DoCopyCensus(), in lieu of
> GC>    the former busy cursor.
> GC> The last of those three changes is experimental, as it raises an 
> interesting
> GC> question: would you rather see chatter on the statusbar during an 
> operation
> GC> that takes an appreciable fraction of a second for a 1691-cell census (and
> GC> presumably several seconds for one with more than 10000 cells), or would
> GC> you rather have that operation take only half as long? Or--perhaps even
> GC> better--in a case like this, since we're already using something like the
> GC> progress-meter API, would we be better off with the 100-msec-delayed busy
> GC> cursor previously discussed, assuming that its overhead is less than this
> GC> rather hungry statusbar's? OTOH, because counting to 1691 on the statusbar
> GC> adds the same amount of time to any 1691-fold operation, if it's 
> negligible
> GC> for one, should we deem it negligible for any operation?
> 
>  Typically, the status bar wouldn't be updated on every loop iteration, but
> on every 10th, or maybe 100th, one (or, ideally, after every 100ms, i.e. a
> dynamically determined number of iterations). This not only lowers the time
> "wasted" on UI updates, but also avoids flicker that would surely happen if
> each loop iteration is quick enough.
> 
>  So my API would actually look like this:
At one extreme, we just add a single line, and the statusbar indicates
that work is underway and the program has not frozen. At the other
extreme, we have heavyweight solutions like a progress dialog. Between
the extremes are various other possible designs.

Revisiting this someday, we might find a good general solution and use
it uniformly throughout lmi. Right now, we need to put this aside in
order to focus on PDF modernization. (But first there's one politically
urgent task I need to address.)