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



Reply via email to