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

Previous Next

Full log

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

From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, alan <at> idiocy.org, 42406 <at> debbugs.gnu.org
Subject: Re: bug#42406: Mouse-wheel scrolling can be flickering
Date: Tue, 15 Dec 2020 21:12:24 +0100

5 frames

> Am 15.12.2020 um 21:05 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> 
>> From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
>> Date: Tue, 15 Dec 2020 20:52:25 +0100
>> Cc: martin rudalics <rudalics <at> gmx.at>,
>> Alan Third <alan <at> idiocy.org>,
>> 42406 <at> debbugs.gnu.org
>> 
>> Just using the mouse, moving the vertical scroll-bars up and down. As with mouse-wheel scrolling, performance decreases with the number of open frames, in the sense that scrolling becomes more and more sticky.
> 
> As long as you invoke scrolling commands (and that's what the scroll
> bar eventually does in Emacs), you will always have the same problem:
> scrolling commands cause Emacs redraw all the frames.  If the NS port
> does that inefficiently, you will see performance hit.  The general
> assumption in the Emacs display engine is that the absolute majority
> of the frame's display will not actually be redrawn on the glass,
> because Emacs knows they don't need to.  If the NS port violates this,
> or if it is too slow to redraw the frame decorations that Emacs cannot
> control directly (i.e. it cannot know whether they need to be
> redrawn), then the performance you see will be worse than expected.
> 
> How many frames do you need to create before just dragging the
> scroll-bar thumb slows down enough to be tangible? 2? 5? 10? more?

Previous Next

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