[lmi] Correctness and performance of varying column width mode in the census view

[Vadim Zeitlin]

 Hello,

 I'm struggling with choosing the right two out of the following three
goals for the automatic column fitting in the census view:

1. Correct.
2. Fast.
3. Simple.

and would like to ask for your help with determining the ones to pursue.

 The basic problem here is that computing the best size of the column means
iterating over all rows and, when there are a lot of them, as can be the
case for the large censuses, it inevitably takes a long time. The saving
grace of using wxDataViewCtrl in the census view was that, however long it
took, we couldn't do much outside of it because its API is limited by the
possibilities of the native GTK and Cocoa controls it uses under Linux and
macOS, respectively, and so we basically had a straightforward choice
between (1) and (2) and we chose (1), meaning that updating the value of
any cell, e.g. entering a longer name in the corresponding column,
correctly updated the column width, but doing it in big (~10,000 rows)
censuses was very slow under MSW and would have probably been unbearably
slow under GTK, as the native control used there doesn't use the special
optimizations we implemented to speed this up in the generic one.

 With the new grid-based censuses we've actually chosen (2) for now,
because (1) is too slow even under MSW, as wxGrid lacks these optimizations
as well and IMO it's clearly unacceptable to have to wait for several dozen
seconds after changing any field. We could make wxGrid as fast as wxDVC
using the same tricks but this "fast" is still not really fast, i.e. it can
be a few seconds, which is much better in comparison, but still annoying
enough to prevent anybody from actually using varying column widths in
practice.

 And the extra confounding factor here is that with wxGrid we can make it
really fast, i.e. eliminate any noticeable delay completely, as it's under
our control. The only problem is that this would get us (1)+(2) at the
expense of (3) as we'd need to use more complicated code to track the cells
whose widths would need to be recomputed instead of dumbly recomputing all
of them all the time. Some of this complexity could be hidden by wxGrid
itself, but some of it would still remain in lmi code.

 IMO this is nevertheless still the best thing to do, as (3) only affects
us, lmi developers, while (1) and (2) are important for lmi users. However
I'm not totally certain if it's the best thing to do _right now_ because
the grid patch already has a lot of new code and it's not clear if it's a
good idea to add even more of it to it. OTOH I also think that perhaps
you'd actually prefer to deal with all of this in one fell swoop rather
than have to return to this code later, if we implement these optimizations
in a separate patch.

 So what would be the best, from your point of view:

(A) Implement fast column auto-sizing in the grid-based census view, even
    if it adds more code to an already big patch, i.e. choose (1)+(2).

(B) Keep things as simple as possible in the initial PR and improve them
    later, i.e. choose (3)+(x). Concerning the value of "x", I'm almost
    certain that it should be (2), as (1) is just completely unusable right 
    now (in fact, even (2) is not so fast, but at least we can avoid doing
    it all the time if we sacrifice (1)), but please let me know if you
    disagree.

? Of course, if you see some (C) allowing to have our cake, eat it and
invest it for the future, please let me know, but right now I don't think
it's possible, so something will have to give.

 Again, in the long term, I think (1)+(2)+(as much of 3 as possible) is the
best thing to do and I'd really like to do it, as it would be a tangible
advantage of the new version for the users, but I'd like even more to avoid
overloading you with too much new code.

 Thanks in advance for your guidance,
VZ

pgpwng3Zo5__O.pgp
Description: PGP signature