Asger Alstrup wrote: > Alfredo Braunstein wrote: >> 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.
Sure, I am only noting that it is a feature that only *exists* in small documents. Thus, it cannot be so fundamentally important. >> 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. I wasn't saying anything about affordability, just clarifying that we need to compute the size of all paragraphs, not only onscreen ones. >> 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. Hey, don be so picky. I'm very glad we are discussing this, it is certainly much 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. I was talking in terms of man-power. >> 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. Well, we could just keep (maybe outdated) paragraphs sizes, and just update on-screen ones when drawing. Then the scrollbar computation would be only a loop over all outer paragraphs. Regards, Alfredo