Hi Po Lu, any progress on this? Currently it's hard to use this mode on a
laptop, since the governor setting needs to be changed to a high
performance one to get a smooth experience, leading to increased heat
dissipation and noise. Thanks.

On Wed, Nov 9, 2022 at 12:42 AM Po Lu <luangruo@yahoo.com> wrote:

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