I'm not sure about that. Specially since there's no difference in the scrollbar size in a mid-sized document vs a big document like UG, because most toolkits have a minimum size for the widget.
Small documents are important too.
It shouldn't jump at all (otherwise is just a bug).
The size should not change more than a few pixels either.
Constant time per paragraph, O(number of paragraphs) total time
And can't we afford this? If so, our paragraph list traversal sucks and should be changed.
The biggest problem seems to be very high insets, like long tabulars
Great, then try to address those, and see what is the next problem. This is exactly the approach I'm advocating.
This could be, the question is how to do this consistently. Otherwise we will always have problems with corner cases.
It is still monotoneously better than ignoring the problem.
Ultimately, if such patching up does not fix the problem, we have to admit that it was a mistake, and introduce full document word breaking again.
It may be, but I am afraid that we cannot afford this.
We used to be able to afford it, so it is affordable. It might not be feasible with the current rewritten core, but then the rewrite is not complete or a failure.
An alternative you didn't mention would be to have background computation of the exact size (including full rebreak etc).
This is similar to what web-browsers do as they receive the data, so that might be acceptable. But I thought the problem was that keeping the data up-to-date as the document changes is the problem? You will not avoid that can of worms with background rebreak.
Regards, Asger
