Andre Poenitz ha scritto:
ourselves into a corner here. We had this kind of approach (all
paragraph heights known) for a long time and switched to the
current one for performance reasons when e.g. loading/resizing
inserting in big docments.
My feeling is that, even with hundreds of outer paragraphs,
the process of summing their heights up should not be
even perceivable on modern CPUs (provided that the heights
are directly available within a vector, like it is now -- ParMetricsCache
is not a map anymore, but a vector). And, more importantly,
such process would be triggered only as a response to:
1) change of height of currently edited par
1.a) break of currently edited par (Enter)
2) cut and paste operations
3) width resize of screen
If you have serious concerns about this (probably due to the
past experience on developing LyX), the best solution would
be a "summing (balanced) tree", that would exhibit O(log n)
complexity for little updates like needed in 1) [not sure about
1.a], but probably you won't avoid the O(n) updates in case of
2) or 3).
If you look at the patch code, you'll notice that many times
(not all, though) paragraph heights are managed through
dedicated methods (tm.parHeight(), tm.computeHeight(par1, par2)),
instead of using the "standard" par_metrics_[p].height(), just
in view of such possibility.
T.
