Andre Poenitz wrote: >> 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...
Mmm... I think this would be pretty bad. >> 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). My main concern is that is much more difficult to go the nonlazy -> lazy route as we have done (and Andre' and myself invested a good deal of time doing it) than the other way around. So we should make this decision very carefully. PS: I *think* I agree with Andre on this point, but I rather not say it 'cause lately I'm not guessing right ;-) A/
