emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recenter video


From: Lennart Borgman
Subject: Re: Recenter video
Date: 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
>> Cc:
>>
>> 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
> resources...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]