Re: [lmi] Census-manager Update()

[Vadim Zeitlin]

On Sat, 01 Nov 2014 22:05:38 +0000 Greg Chicares <address@hidden> wrote:

GC> For a given column in the census manager, suppose that all cells
GC> have the same value, except for one differing cell. If we edit
GC> that differing cell and remove that difference, then all cells
GC> are now the same, and the column is no longer to be shown. When
GC> is the display to be thus updated? IOW, when should the function
GC> that updates the display, CensusView::Update(), be called?

 I think the best solution for this would involve doing the work done by
update_class_names() on a separate thread and then requesting that the main
thread updates the columns only if really necessary -- which should be a
relatively rare occurrence.

GC> It is called whenever
GC>  - a cell is added or deleted; or
GC>  - a census is pasted; or
GC>  - any change is made through the tabbed "Edit" dialog.
GC> But it is not called when a value is changed through direct
GC> drill-down editing; should it be? I tried this experiment:
GC> 
GC> -- 8< --
GC> Index: census_view.cpp
GC> ===================================================================
GC> --- census_view.cpp (revision 6015)
GC> +++ census_view.cpp (working copy)
GC> @@ -748,6 +748,7 @@
GC>      Input& model = view_.cell_parms()[row];
GC>      model.Reconcile();
GC> 
GC> +    view_.Update();
GC>      view_.document().Modify(true);
GC> 
GC>      return true;
GC> -- >8 --
GC> 
GC> and concluded that we're better off without that change. It's good
GC> for a small census, but for a census with 4000 cells it made the GUI
GC> feel sluggish.

 I am not even sure how long does update_class_names() really take, but
just disabling the window and recreating all columns after each change, as
currently done by Update(), is not going to work well. At the very least,
i.e. even if we stay with a single threaded solution, both should be done
only if necessary, not unconditionally.

GC> (Maybe someday we'll be able to update only the part
GC> that shows on the screen--like a "virtual" wxGrid, IIRC).

 This is already the case, wxDataViewCtrl is always "virtual". Just
redisplaying the data in it with the new columns shouldn't take result in
any significant delay. But removing all columns and re-adding them might,
if only because of the UI flicker. I suspect -- and could try it,
especially if you could share the big test case with me -- that just
avoiding doing this unless necessary in update_visible_columns() might
already take care of the sluggishness.


GC> But there has to be a way to trigger Update() aside from the
GC> triggers documented above, so I asked myself what a reasonably
GC> ingenious user would try. The answer seemed obvious:
GC>   http://svn.savannah.nongnu.org/viewvc?view=rev&root=lmi&revision=6016

 This is indeed ingenious, but I am pretty sure fully automatic solution is
achievable as well. Definitely so if you're prepared to use a background
thread and perhaps even without it.

 Please let me know if it's worth investigating this further,
VZ