Re: [lmi] UI updates during long operations

[Vadim Zeitlin]

On Wed, 27 Jun 2018 15:15:05 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-06-26 23:08, Vadim Zeitlin wrote:
GC> > On Tue, 26 Jun 2018 22:33:39 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> In the changeset I'm just about to push, I've
GC> > GC>  - reverted the busy-cursor commit that started this thread;
GC> > GC>  - called wxWindow::Update() when writing to the statusbar as you 
suggested;
GC> > 
GC> >  This is the point where I should mention that I haven't actually tested
GC> > this. Update() is supposed to work, but there can sometimes be
GC> > complications with the native controls (of which wxStatusBar is one). Did
GC> > it actually solve the problem of "missing" updates?
GC> 
GC> No. The problem has been solved (the statusbar now shows a smooth iteration
GC> count, instead of the "choppy" count noted previously), but calling Update()
GC> is not the change that solved it--at least not with 'wine'. If I 
experimentally
GC> suppress the Update() call recently added in 'alert_wx.cpp':
GC> 
GC>                  b->SetStatusText(s);
GC> -                b->Update();
GC> +//              b->Update();
GC> 
GC> and retest, the statusbar still updates smoothly. Apparently it was the
GC> removal of the bogus wxSafeYield() call that solved the problem.

 This is really strange, I don't see how could yielding prevent the status
bar from updating. I've tried the following patch:

---------------------------------- >8 --------------------------------------
diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
index f765a70dac..06a26f72d3 100644
--- a/samples/minimal/minimal.cpp
+++ b/samples/minimal/minimal.cpp
@@ -190,6 +190,14 @@ void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event))
 
 void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
 {
+    for ( int i = 0; i < 100; i++ )
+    {
+        SetStatusText(wxString::Format("Step %d", i + 1));
+        wxSafeYield();
+        wxMilliSleep(100);
+    }
+    return;
+
     wxMessageBox(wxString::Format
                  (
                     "Welcome to %s!\n"
---------------------------------- >8 --------------------------------------

but I don't see the problem, neither with nor without wxSafeYield() call.
I guess it's not worth investigating this further if the problem is solved,
but it remains surprising.

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

 In fact, it seems that the documentation is correct and SetStatusText()
does indeed take care of updating the status bar: in the generic version
(used in wxGTK and other ports), this is done by explicitly calling
Update() from it. And the native MSW version clearly does do it, even
though it's not really documented to do it and, in fact, even more or less
documented to not do it as
https://docs.microsoft.com/en-us/windows/desktop/controls/sb-settext
states

        The message invalidates the portion of the window that has changed,
        causing it to display the new text when the window next receives
        the WM_PAINT message.

I.e. in practice this Update() is useless. But OTOH it doesn't really hurt
neither and I've measured its impact on the total time taken by the loop
above and it's just not noticeable, i.e. below the measurement error (BTW,
wxSafeYield() does have a small but noticeable impact of ~0.4%). So we can
either remove or keep it, as you prefer.

GC> Revisiting this someday, we might find a good general solution and use
GC> it uniformly throughout lmi. Right now, we need to put this aside in
GC> order to focus on PDF modernization.

 Please let me know if I can do anything to help you integrate my changes
from https://github.com/vadz/lmi/pull/86

 Thanks,
VZ