GNU bug report logs - #42406
Mouse-wheel scrolling can be flickering

Previous Next

Full log

Message #42 received at 42406 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: konrad.podczeck <at> univie.ac.at, 42406 <at> debbugs.gnu.org
Subject: Re: bug#42406: Mouse-wheel scrolling can be flickering
Date: Fri, 11 Dec 2020 20:37:56 +0000

On Fri, Dec 11, 2020 at 10:18:14AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 10 Dec 2020 22:10:28 +0000
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: 42406 <at> debbugs.gnu.org
> > 
> > What appears to be happening is that scrolling with the mouse, and
> > also using C-v or M-v causes every frame to update the cursor and
> > clear the internal border, which in turn causes them all to be drawn
> > to the screen at once, which is pretty slow.
> > 
> > (It also appears to do something with scrollbars which helped me find a
> > subtle redrawing bug.)
> > 
> > Scrolling through the buffer by using C-n to move down line by line
> > only updates the frame being displayed. I'm not sure what's going on,
> > it appears to be system independent code doing this.
> 
> Any pointers to the code which causes all the frames to be updated in
> C-v/M-v case?

I don't know. I'm looking at redisplay_internal in a debugger and I
can see that consider_all_windows_p is true, which will be because
windows_or_buffers_changed == 2 == REDISPLAY_SOME or because
update_mode_lines == 42.

I can't find anywhere that sets update_mode_lines to 42...

In my case both frames are displaying different buffers. The one I'm
scrolling is displaying xdisp.c and the other is displaying *scratch*.

-- 
Alan Third

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.