[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59134: 29.0.50; Pixel scroll precision mode is very CPU intensive an
From: |
Po Lu |
Subject: |
bug#59134: 29.0.50; Pixel scroll precision mode is very CPU intensive and governor sensitive |
Date: |
Wed, 09 Nov 2022 08:42:48 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Luke Fernandes <luke124273@googlemail.com> writes:
> Not so much a bug as a request for an improvement/feature request.
>
> When using pixel-scroll-precision-mode in Emacs, scrolling will be laggy or
> choppy when the Linux kernel cpu governor is set to more power saving
> modes, seemingly because clocks are less responsive to load and do not
> rise from their idle state (on my Intel hexacore mobile Xeon, this is
> 800 Mhz) until a few seconds into the scroll, if at all. When the
> governor is set to performance, clocks will go from mid-table to max/base
> clock (I have
> turbo boost disabled) instantly and stay there for the duration of the
> scroll - and the scroll is buttery smooth.
>
> On chrome or firefox, scrolling will in contrast be completely smooth even if
> CPU
> clocks remain at 800 MHz (say, under the most restrictive governor
> policies or a maximum clock limit) for the entire scroll.
>
> It is undesirable that a power balancing governor setting, which works
> well for most or all other applications, should cause lag and stuttering
> in smooth pixel scrolling in Emacs. I realise there are performance
> constraints within Emacs' design, but if there's any way we can get
> smooth scrolling to be more workable at lower clocks that would be great.
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.34, cairo version 1.17.6) of 2022-09-26 built on Putty4-7manjaro
> Repository revision: 93b9cf41846b40cd050b56f6e83b590330be255e
> Repository branch: master
> Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
> System Description: Manjaro Linux
I know of this problem and will try to fix it. But unfortunately it
isn't very high on my priority list, so it will probably not be fixed
until next year.