On Sun, Nov 11, 2007 at 04:39:22PM +0100, Tommaso Cucinotta wrote: > 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
4) Loading of a document. > 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). I think loading/resizing in 4 second is ok. 20 is rather not. I know, it's not that bad, I am exaggerating. And of course one could provide some more versose status message (as in 23/5490 paragraphs done) giving the impression that 'something' happens... > 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. The patch as such looks like a sensible implementation of the idea (plus/minus some minor quirks). However, as this is quite intrusive change of concept I'd rather make sure the concept is sound. And I do not really want to rely on gut feelings only here (my gut says: Id shoul be ok as we used to o it like that for a while and the lazy rebreaking was not too much of a success and machines are faster tofday then five years ago). Andre'
