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

Previous Next

Full log

View this message in rfc822 format

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

> 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.