GNU bug report logs - #29737
27.0.50; pixel-scroll-mode is laggy

Previous Next

Full log

View this message in rfc822 format

From: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
To: eliz <at> gnu.org
Cc: tkk <at> misasa.okayama-u.ac.jp, valentjedi <at> gmail.com, 29737 <at> debbugs.gnu.org
Subject: bug#29737: 27.0.50; pixel-scroll-mode is laggy
Date: Sun, 07 Jan 2018 11:06:26 +0900 (JST)

>> Date: Mon, 01 Jan 2018 09:58:38 +0900 (JST)
>> Cc: eliz <at> gnu.org, 29737 <at> debbugs.gnu.org, tkk <at> misasa.okayama-u.ac.jp
>> From: Tak Kunihiro <tkk <at> misasa.okayama-u.ac.jp>
>>
>> I think that on scrolling of 1000 lines, smooth scroll is not
>> necessary.  User wants smooth scrolling only for the first spin of
>> mouse wheel.
>>
>> This patch introduces a new variable `pixel-dead-time' and
>> `pixel-last-scroll-time'.  When another scroll request was delivered
>> within `pixel-dead-time', very likely user does not want smooth
>> scrolling.
>>
>> On such situation, `scroll-down' is called instead of
>> `pixel-scroll-pixel-down'.  On theory there should not be lag because
>> of smoothing.
>>
>> I tested the revised pixel-scroll-mode for a week and confirmed that
>> works good.  When `pixel-dead-time' is zero, its behavior is the same
>> as before.  I think `pixel-dead-time' 0.1 works better.
>>
>> I'm sending ChangeLog and a patch relative to the current master.
>
> There was no response, but do you think we should push this
> regardless?  (It should go to the release branch, not to master.)

I think I understood what the laggy meant.  The laggy scroll is slow
scroll with too frequent redisplay.  If my understanding is correct, I
am sure this patch fixes the laggy problem.

I think it is good to avoid the laggy situation.  Thus I think, to
push this patch to the release branch is a good idea.

Previous Next

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