[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Recenter video
Re: Recenter video
Wed, 23 Jun 2010 11:44:33 +0200
On Wed, Jun 23, 2010 at 5:06 AM, Eli Zaretskii <address@hidden> wrote:
>> From: Lennart Borgman <address@hidden>
>> Date: Wed, 23 Jun 2010 02:41:08 +0200
>> I can see the "jumping scrolling", but the bug here is not the same as
>> the one I have tried to fix. Here I can see it enters the
>> "clear_glyph" path in try_scrolling and I think this is what Eli have
>> been working on.
> If you still don't use the latest changes on the trunk, it's a small
> wonder that you see recentering inside try_scrolling.
What do you mean? What do you not expect to happen?
>> I do not think Eli's changes cure the problem I have seen (but I am
>> not sure) and my changes alone can't cure your problem (but it cured
>> the problem I saw when scrolling window.c).
> The problem is that your changes are incorrect: they violate the
> redisplay protocol that doesn't allow using the current glyph matrix
> if the last redisplay cycle was paused (a.k.a. interrupted) because
> more input arrived. The window_end_valid flag being nil means that
> the redisplay was not finished, and in that case we cannot use the
> try_scrolling method.
I can't see that this happens because of my change. The test for
window_end_valid flag is still there with my patch. The only thing I
have changed is when clip_changed is set because of changes in
clipping. Everything else remains the same.
Can you please explain exactly what you mean?
> So your changes could work in some special
> cases, but using them means we will certainly see redisplay bugs in
> the future.
> The only way to fix this case correctly is either to force redisplay
> finish with its job, at least for a single window, before it pauses,
> or improve the code that sets the window_end_valid flag so that it
> does not give up too easily.
> But to make such changes reliably I need to reproduce the problem on
> my machine. Until now, I can only reproduce it extremely rarely (like
> once in the whole scroll of window.c, and only sometimes), even if I
> load my CPU with 2 programs each of which eats up 100% of CPU