bug#29737: 27.0.50; pixel-scroll-mode is laggy

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Valentin Ignatyev]

[-- Attachment #1: Type: text/plain, Size: 7456 bytes --]

================
Hi! I've tried new feature `pixel-scroll-mode` on both emacs-26 and on
master branches. While I see that scrolling became pixel-wise indeed, it
is also very laggy. CPU blows up to 100% and ui hangs and freezes. It
works ok if I scroll slowly though. It happens with all my plugins and
customizations and if I run emacs with -Q flag. My OS is Arch Linux and
I also have HiDPI screen (it's MacBook 11,4, mid-2015). I've also
started this related reddit thread:
https://www.reddit.com/r/emacs/comments/7k7322/pixelscrollmode_wanted/

Thanks a lot for your work, I'd like to give an additional info, but I
don't know exactly what could be helpful.

Cheers, Velentin.
================


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-12-16 built on vjarch
Repository revision: 506270f9c80bf9bd7dad35a2f0aa6f477da6490b
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
Recent messages:
Type C-c C-c or C-c C-x to view the image as text or hex.
Can’t guess python-indent-offset, using defaults: 4
Setting up indent for shell type zsh
Indentation variables are now local.
Indentation setup for shell type zsh
Wrote /home/vj/.emacs.d/.emacs.desktop.lock
Desktop: 1 frame, 54 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.
mwheel-scroll: Beginning of buffer [3 times]
Pixel-Scroll mode enabled
pixel-scroll-down: Beginning of buffer
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-sound=alsa --with-xft --with-modules --with-x-toolkit=gtk3
 --without-gconf --without-gsettings --without-gpm --without-m17n-flt
 --without-imagemagick 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe
 -fstack-protector-strong -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now
 -fuse-ld=gold''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 FREETYPE
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES LIBSYSTEMD JSON
LCMS2

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Outline

Minor modes in effect:
  pixel-scroll-mode: t
  diff-auto-refine-mode: t
  projectile-mode: t
  global-company-mode: t
  company-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  ivy-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  evil-leader-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  shell-dirtrack-mode: t
  evil-mode: t
  evil-local-mode: t
  override-global-mode: t
  global-auto-revert-mode: t
  global-hl-line-mode: t
  desktop-save-mode: t
  cl-old-struct-compat-mode: t
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t
  view-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail cus-start cus-load pixel-scroll
colir sh-script smie executable conf-mode linum elec-pair vc-git
diff-mode ob-python org-rmail org-mhe org-irc org-info org-gnus nnir
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range message rfc822
mml mml-sec epa derived epg mm-decode mm-bodies mm-encode mailabbrev
gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs mail-utils wid-edit org-docview doc-view image-mode
org-bibtex bibtex org-bbdb org-w3m org-element avl-tree generator org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs cal-menu calendar cal-loaddefs view init yaml-mode ag
vc-svn find-dired dired dired-loaddefs projectile grep compile ibuf-ext
ibuffer ibuffer-loaddefs smartparens-config smartparens-javascript
smartparens-text smartparens-python smartparens-markdown
smartparens-html evil-smartparens smartparens virtualenvwrapper gud
company-anaconda anaconda-mode pythonic f python tramp-sh tramp
tramp-compat tramp-loaddefs trampver ucs-normalize parse-time
format-spec company-tern s dash-functional tern url-http tls gnutls
url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm rmc puny url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util mailcap
company-oddmuse company-keywords company-etags company-gtags
company-dabbrev-code company-dabbrev company-files company-capf
company-cmake company-xcode company-clang company-semantic company-eclim
company-template company-css company-nxml company-bbdb company pcase
rjsx-mode js2-mode js sgml-mode dom cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs imenu markdown-mode
color noutline outline flycheck cl-extra json map find-func help-mode rx
subr-x dash org-bullets counsel jka-compr esh-util etags xref project
swiper ivy delsel ivy-overlay ffap flx evil-surround evil-leader evil
evil-integration undo-tree diff evil-maps evil-commands flyspell ispell
evil-jumps evil-command-window evil-types evil-search evil-ex shell
pcomplete comint ansi-color evil-macros evil-repeat evil-states
evil-core advice evil-common windmove thingatpt rect evil-digraphs
evil-vars ring edmacro kmacro use-package diminish bind-key easy-mmode
finder-inf info package easymenu epg-config url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
autorevert filenotify hl-line desktop frameset cl-loaddefs cl-lib paren
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 670270 69821)
 (symbols 48 56909 2)
 (miscs 40 1143 237)
 (strings 32 160583 14753)
 (string-bytes 1 4909395)
 (vectors 16 91715)
 (vector-slots 8 1535197 58450)
 (floats 8 446 340)
 (intervals 56 4061 335)
 (buffers 992 65))

[-- Attachment #2: Type: text/html, Size: 8019 bytes --]

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Eli Zaretskii]

> From: Valentin Ignatyev <valentjedi@gmail.com>
> Date: Sun, 17 Dec 2017 03:55:34 +1000
> 
> Hi! I've tried new feature `pixel-scroll-mode` on both emacs-26 and on
> master branches. While I see that scrolling became pixel-wise indeed, it
> is also very laggy. CPU blows up to 100% and ui hangs and freezes. It
> works ok if I scroll slowly though. It happens with all my plugins and
> customizations and if I run emacs with -Q flag.

In what major mode does this happen?  Does the problem still happen if
you switch to Fundamental mode?

Also, what happens if you hold the Ctrl key while scrolling?  What if
you set mouse-wheel-progressive-speed to nil?

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Eli Zaretskii]

Please always CC the bug address.

> From: Valentin Ignatyev <valentjedi@gmail.com>
> Date: Sun, 17 Dec 2017 04:52:51 +1000
> 
> Hi again Eli! Thanks for the fast response! 
> It happens in all major modes I've tried it (org-mode, python-mode, and web-mode).
> It still happens in the fundamental mode as well (tried to scroll emacs-news in fundamental mode). Setting
> mouse-wheel-progressive-speed to nil seems to have no effect or very little effect that I can't notice.
> Scrolling with a Ctrl key is much smoother yet not lagless (it also loads CPU in about 50% or so). And it's
> looks like line-wise, not pixel-wise ;)
> 
> Just to mention, I've tried your suggestions without any additional elisp (e.g with -Q flag).

CC'ing Tak, who wrote this mode.  Tak, would you please look into
this?

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Valentin Ignatyev]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Sorry, still new to this. Will absolutely do since now on :)

On Sun, Dec 17, 2017 at 5:33 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Please always CC the bug address.
>
> > From: Valentin Ignatyev <valentjedi@gmail.com>
> > Date: Sun, 17 Dec 2017 04:52:51 +1000
> >
> > Hi again Eli! Thanks for the fast response!
> > It happens in all major modes I've tried it (org-mode, python-mode, and
> web-mode).
> > It still happens in the fundamental mode as well (tried to scroll
> emacs-news in fundamental mode). Setting
> > mouse-wheel-progressive-speed to nil seems to have no effect or very
> little effect that I can't notice.
> > Scrolling with a Ctrl key is much smoother yet not lagless (it also
> loads CPU in about 50% or so). And it's
> > looks like line-wise, not pixel-wise ;)
> >
> > Just to mention, I've tried your suggestions without any additional
> elisp (e.g with -Q flag).
>
> CC'ing Tak, who wrote this mode.  Tak, would you please look into
> this?
>
>

[-- Attachment #2: Type: text/html, Size: 1428 bytes --]

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Tak Kunihiro]

[-- Attachment #1: Type: Text/Plain, Size: 1077 bytes --]

> While I see that scrolling became pixel-wise indeed, it is also very
> laggy. CPU blows up to 100% and ui hangs and freezes. It works ok if
> I scroll slowly though. It happens with all my plugins and
> customizations and if I run emacs with -Q flag. My OS is Arch Linux
> and I also have HiDPI screen (it's MacBook 11,4, mid-2015).

On the previous commit <8eb6870be690128fb1cbc012c55093813c39830c>, I
revised two functions.  I fixed `pixel-scroll-down' but I broke
`pixel-scroll-up'.  I apologize for the careless commit.

With the current and broken `pixel-scroll-up', when EOB is shown on
top of the screen, emacs hangs (or goes in infinite while loop).  The
pixel-scroll-up should be reverted to commit
<1bda71ec3b11eeb4d06c3da094a3cb21bac18d5c>.

I'm sending ChangeLog and a patch relative to the current master.

* ChangeLog

Fix vertical cursor motion in pixel-scroll.el

* lisp/pixel-scroll.el (pixel-scroll-up): Do not try to move cursor down when EOB
is shown at the top.  This function is reverted to commit
1bda71ec3b11eeb4d06c3da094a3cb21bac18d5c. (bug#29737)


[-- Attachment #2: pixel-scroll.el.diff --]
[-- Type: Text/X-Patch, Size: 1141 bytes --]

diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
index f64a439..7024487
--- a/lisp/pixel-scroll.el
+++ b/lisp/pixel-scroll.el
@@ -110,11 +110,11 @@ This is an alternative of `scroll-up'.  Scope moves downward."
                        pixel-resolution-fine-flag
                      (frame-char-height))
                  (pixel-line-height))))
-      (while (pixel-point-at-top-p amt) ; prevent too late (multi tries)
-        (vertical-motion 1))            ; move point downward
-      (if (pixel-eob-at-top-p)          ; when end-of-the-buffer is close
-          (scroll-up 1)                 ; relay on robust method
-        (pixel-scroll-pixel-up amt))))) ; move scope downward
+      (if (pixel-eob-at-top-p)            ; when end-of-the-buffer is close
+          (scroll-up 1)                   ; relay on robust method
+        (while (pixel-point-at-top-p amt) ; prevent too late (multi tries)
+          (vertical-motion 1))            ; move point downward
+        (pixel-scroll-pixel-up amt)))))   ; move scope downward
 
 (defun pixel-scroll-down (&optional arg)
   "Scroll text of selected window down ARG lines.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Eli Zaretskii]

> Date: Sun, 17 Dec 2017 11:00:45 +0900 (JST)
> Cc: valentjedi@gmail.com, 29737@debbugs.gnu.org, tkk@misasa.okayama-u.ac.jp
> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
> 
> > While I see that scrolling became pixel-wise indeed, it is also very
> > laggy. CPU blows up to 100% and ui hangs and freezes. It works ok if
> > I scroll slowly though. It happens with all my plugins and
> > customizations and if I run emacs with -Q flag. My OS is Arch Linux
> > and I also have HiDPI screen (it's MacBook 11,4, mid-2015).
> 
> On the previous commit <8eb6870be690128fb1cbc012c55093813c39830c>, I
> revised two functions.  I fixed `pixel-scroll-down' but I broke
> `pixel-scroll-up'.  I apologize for the careless commit.
> 
> With the current and broken `pixel-scroll-up', when EOB is shown on
> top of the screen, emacs hangs (or goes in infinite while loop).  The
> pixel-scroll-up should be reverted to commit
> <1bda71ec3b11eeb4d06c3da094a3cb21bac18d5c>.
> 
> I'm sending ChangeLog and a patch relative to the current master.

I'd like to fix this on the release branch, not on master.  Is the
patch you sent good to go to the release branch?  Does it solve the
display lags mentioned in the bug report?

Thanks.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Tak Kunihiro]

>>> While I see that scrolling became pixel-wise indeed, it is also very
>>> laggy. CPU blows up to 100% and ui hangs and freezes. It works ok if
>>> I scroll slowly though. It happens with all my plugins and
>>> customizations and if I run emacs with -Q flag. My OS is Arch Linux
>>> and I also have HiDPI screen (it's MacBook 11,4, mid-2015).
>>
>> On the previous commit <8eb6870be690128fb1cbc012c55093813c39830c>, I
>> revised two functions.  I fixed `pixel-scroll-down' but I broke
>> `pixel-scroll-up'.  I apologize for the careless commit.
>>
>> With the current and broken `pixel-scroll-up', when EOB is shown on
>> top of the screen, emacs hangs (or goes in infinite while loop).  The
>> pixel-scroll-up should be reverted to commit
>> <1bda71ec3b11eeb4d06c3da094a3cb21bac18d5c>.
>>
>> I'm sending ChangeLog and a patch relative to the current master.
>
> I'd like to fix this on the release branch, not on master.  Is the
> patch you sent good to go to the release branch?  Does it solve the
> display lags mentioned in the bug report?

Yes, the patch I sent is good to go to the release branch.

I'm not 100% sure what 'the display lag' meant.  I think the bug is
the source of 'the display lag'.

After the patch, at least I tested with MacBook and do not recognize
'the display lag'.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Eli Zaretskii]

> Date: Sat, 23 Dec 2017 12:18:56 +0900 (JST)
> Cc: valentjedi@gmail.com, 29737@debbugs.gnu.org, tkk@misasa.okayama-u.ac.jp
> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
> 
> > I'd like to fix this on the release branch, not on master.  Is the
> > patch you sent good to go to the release branch?  Does it solve the
> > display lags mentioned in the bug report?
> 
> Yes, the patch I sent is good to go to the release branch.

Thanks, pushed to the release branch.

> I'm not 100% sure what 'the display lag' meant.

It meant very slow scrolling, with redisplay falling far behind.
After applying the patch, I see a definite improvement on my system.

> After the patch, at least I tested with MacBook and do not recognize
> 'the display lag'.

Right.  Valentin, could you please see whether this change makes the
problem go away, or at least makes it much less of a problem?  TIA.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Valentin Ignatyev]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

Hi all.
I just tested this fix. While it doesn't solve the issue, I saw a little
improvement. And now I see the lag pattern. When I slowly start scrolling,
it scrolls for a while and then jumps about 10 rows at the time, then
scrolls a bit more and jumps again
If I swipe my trackpad too fast, emacs instantly eats 100% CPU and hangs
infinitely (it hangs not every time, but rather once in a while. It can
just go to the end of the file).
If I scroll with Ctrl-key as Eli suggested in the first thread mail, it
scrolls better than before the fix, but I still see this lag pattern
(scroll a bit and then jump), but in the smaller scale and it doesn't kill
emacs.
Setting mouse-wheel-progressive-speed to nil seem to make no difference.

Btw, while I do use macbook, my OS is Arch Linux here :)
I think I'll try to compile latest emacs-26 branch on macos itself and tell
there is defference. Maybe it'll shrink down the scope

Thanks for your work on this, I really appreciate it


On Sat, Dec 23, 2017 at 7:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 23 Dec 2017 12:18:56 +0900 (JST)
> > Cc: valentjedi@gmail.com, 29737@debbugs.gnu.org,
> tkk@misasa.okayama-u.ac.jp
> > From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
> >
> > > I'd like to fix this on the release branch, not on master.  Is the
> > > patch you sent good to go to the release branch?  Does it solve the
> > > display lags mentioned in the bug report?
> >
> > Yes, the patch I sent is good to go to the release branch.
>
> Thanks, pushed to the release branch.
>
> > I'm not 100% sure what 'the display lag' meant.
>
> It meant very slow scrolling, with redisplay falling far behind.
> After applying the patch, I see a definite improvement on my system.
>
> > After the patch, at least I tested with MacBook and do not recognize
> > 'the display lag'.
>
> Right.  Valentin, could you please see whether this change makes the
> problem go away, or at least makes it much less of a problem?  TIA.
>

[-- Attachment #2: Type: text/html, Size: 2818 bytes --]

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Valentin Ignatyev]

[-- Attachment #1: Type: text/plain, Size: 2477 bytes --]

Just tried it on mac os. pixel-scroll-mode works much better here though
there is still small noticeable lag. And also I can see that scroll up
lagging more than scroll down.
Hope it'll help


--------------------------------
С уважением,
Игнатьев Валентин

On Sat, Dec 23, 2017 at 9:30 PM, Valentin Ignatyev <valentjedi@gmail.com>
wrote:

> Hi all.
> I just tested this fix. While it doesn't solve the issue, I saw a little
> improvement. And now I see the lag pattern. When I slowly start scrolling,
> it scrolls for a while and then jumps about 10 rows at the time, then
> scrolls a bit more and jumps again
> If I swipe my trackpad too fast, emacs instantly eats 100% CPU and hangs
> infinitely (it hangs not every time, but rather once in a while. It can
> just go to the end of the file).
> If I scroll with Ctrl-key as Eli suggested in the first thread mail, it
> scrolls better than before the fix, but I still see this lag pattern
> (scroll a bit and then jump), but in the smaller scale and it doesn't kill
> emacs.
> Setting mouse-wheel-progressive-speed to nil seem to make no difference.
>
> Btw, while I do use macbook, my OS is Arch Linux here :)
> I think I'll try to compile latest emacs-26 branch on macos itself and
> tell there is defference. Maybe it'll shrink down the scope
>
> Thanks for your work on this, I really appreciate it
>
>
>
> On Sat, Dec 23, 2017 at 7:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> > Date: Sat, 23 Dec 2017 12:18:56 +0900 (JST)
>> > Cc: valentjedi@gmail.com, 29737@debbugs.gnu.org,
>> tkk@misasa.okayama-u.ac.jp
>> > From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
>> >
>> > > I'd like to fix this on the release branch, not on master.  Is the
>> > > patch you sent good to go to the release branch?  Does it solve the
>> > > display lags mentioned in the bug report?
>> >
>> > Yes, the patch I sent is good to go to the release branch.
>>
>> Thanks, pushed to the release branch.
>>
>> > I'm not 100% sure what 'the display lag' meant.
>>
>> It meant very slow scrolling, with redisplay falling far behind.
>> After applying the patch, I see a definite improvement on my system.
>>
>> > After the patch, at least I tested with MacBook and do not recognize
>> > 'the display lag'.
>>
>> Right.  Valentin, could you please see whether this change makes the
>> problem go away, or at least makes it much less of a problem?  TIA.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3788 bytes --]

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Tak Kunihiro]

> When I slowly start scrolling, it scrolls for a while and then jumps
> about 10 rows at the time, then scrolls a bit more and jumps again
> If I swipe my trackpad too fast, emacs instantly eats 100% CPU and
> hangs infinitely (it hangs not every time, but rather once in a
> while.  It can just go to the end of the file).
>
> If I scroll with Ctrl-key as Eli suggested in the first thread mail,
> it scrolls better than before the fix, but I still see this lag
> pattern (scroll a bit and then jump), but in the smaller scale and
> it doesn't kill emacs.  Setting mouse-wheel-progressive-speed to nil
> seem to make no difference.
>
> Btw, while I do use macbook, my OS is Arch Linux here.  Just tried
> it on mac os. pixel-scroll-mode works much better here though there
> is still small noticeable lag. And also I can see that scroll up
> lagging more than scroll down.

Can you try scrolling with following configuration?

  (setq mouse-wheel-scroll-amount '(1 ((shift) . 5) ((control))))
  (setq mouse-wheel-progressive-speed nil)

Those are two that are already suggested by Eli.  Please try both at
the same time.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Valentin Ignatyev]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

I've tried these both at the same time already. As I've said - scrolling
down is a bit laggy (and it eats the CPU and turns on my fans up high). And
scroll up is much laggier. It's when I scroll slowly. If I do quick swipe -
emacs hangs and then jumps to the line when scrolling must end.

On Sun, Dec 24, 2017 at 12:28 PM, Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
wrote:

> > When I slowly start scrolling, it scrolls for a while and then jumps
> > about 10 rows at the time, then scrolls a bit more and jumps again
> > If I swipe my trackpad too fast, emacs instantly eats 100% CPU and
> > hangs infinitely (it hangs not every time, but rather once in a
> > while.  It can just go to the end of the file).
> >
> > If I scroll with Ctrl-key as Eli suggested in the first thread mail,
> > it scrolls better than before the fix, but I still see this lag
> > pattern (scroll a bit and then jump), but in the smaller scale and
> > it doesn't kill emacs.  Setting mouse-wheel-progressive-speed to nil
> > seem to make no difference.
> >
> > Btw, while I do use macbook, my OS is Arch Linux here.  Just tried
> > it on mac os. pixel-scroll-mode works much better here though there
> > is still small noticeable lag. And also I can see that scroll up
> > lagging more than scroll down.
>
> Can you try scrolling with following configuration?
>
>   (setq mouse-wheel-scroll-amount '(1 ((shift) . 5) ((control))))
>   (setq mouse-wheel-progressive-speed nil)
>
> Those are two that are already suggested by Eli.  Please try both at
> the same time.
>

[-- Attachment #2: Type: text/html, Size: 2040 bytes --]

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Tak Kunihiro]

[-- Attachment #1: Type: Text/Plain, Size: 582 bytes --]

>>Can you try scrolling with following configuration?
>>
>>  (setq mouse-wheel-scroll-amount '(1 ((shift) . 5) ((control))))
>>  (setq mouse-wheel-progressive-speed nil)
>>
>>Those are two that are already suggested by Eli.  Please try both at
>>the same time.

> I've tried these both at the same time already. As I've said -
> scrolling down is a bit laggy (and it eats the CPU and turns on my
> fans up high). And scroll up is much laggier. It's when I scroll
> slowly.

I got what the laggy meant.  I think we want the second spin to be
coarse.  How about something like below?

[-- Attachment #2: pixel-scroll.el.diff --]
[-- Type: Text/X-Patch, Size: 4609 bytes --]

diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
index 70244873b4..92563a2b71 100644
--- a/lisp/pixel-scroll.el
+++ b/lisp/pixel-scroll.el
@@ -82,6 +82,15 @@ case you need scrolling resolution of a pixel, set to 1.  After a
 pixel scroll, typing \\[next-line] or \\[previous-line] scrolls the window to make it
 fully visible, and undoes the effect of the pixel-level scroll.")
 
+(defvar pixel-dead-time 0.1
+  "Interval that requires for the next smooth scrolling in seconds.
+When there is a scrolling request within this period, the
+scrolling will be carried out without pixel resolution.  If zero,
+scrolling is with pixel resolution always.")
+
+(defvar pixel-last-scroll-time 0
+  "Time when the last scrolling was made in seconds since the epoch.")
+
 ;;;###autoload
 (define-minor-mode pixel-scroll-mode
   "A minor mode to scroll text pixel-by-pixel.
@@ -104,35 +113,50 @@ if ARG is omitted or nil."
 This is an alternative of `scroll-up'.  Scope moves downward."
   (interactive)
   (or arg (setq arg 1))
-  (dotimes (ii arg) ; move scope downward
-    (let ((amt (if pixel-resolution-fine-flag
-                   (if (integerp pixel-resolution-fine-flag)
-                       pixel-resolution-fine-flag
-                     (frame-char-height))
-                 (pixel-line-height))))
-      (if (pixel-eob-at-top-p)            ; when end-of-the-buffer is close
-          (scroll-up 1)                   ; relay on robust method
-        (while (pixel-point-at-top-p amt) ; prevent too late (multi tries)
-          (vertical-motion 1))            ; move point downward
-        (pixel-scroll-pixel-up amt)))))   ; move scope downward
+  (if (pixel-scroll-in-rush-p)
+      (scroll-up arg)
+    (dotimes (ii arg)                    ; move scope downward
+      (let ((amt (if pixel-resolution-fine-flag
+                     (if (integerp pixel-resolution-fine-flag)
+                         pixel-resolution-fine-flag
+                       (frame-char-height))
+                   (pixel-line-height))))
+        (if (pixel-eob-at-top-p)      ; when end-of-the-buffer is close
+            (scroll-up 1)             ; relay on robust method
+          (while (pixel-point-at-top-p amt) ; prevent too late (multi tries)
+            (vertical-motion 1))            ; move point downward
+          (pixel-scroll-pixel-up amt))))))  ; move scope downward
 
 (defun pixel-scroll-down (&optional arg)
   "Scroll text of selected window down ARG lines.
 This is and alternative of `scroll-down'.  Scope moves upward."
   (interactive)
   (or arg (setq arg 1))
-  (dotimes (ii arg)
-    (let ((amt (if pixel-resolution-fine-flag
-                   (if (integerp pixel-resolution-fine-flag)
-                       pixel-resolution-fine-flag
-                     (frame-char-height))
-                 (pixel-line-height -1))))
-      (while (pixel-point-at-bottom-p amt) ; prevent too late (multi tries)
-        (vertical-motion -1))              ; move point upward
-      (if (or (pixel-bob-at-top-p amt)     ; when beginning-of-the-buffer is seen
-              (pixel-eob-at-top-p))        ; for file with a long line
-          (scroll-down 1)                  ; relay on robust method
-        (pixel-scroll-pixel-down amt)))))
+  (if (pixel-scroll-in-rush-p)
+      (scroll-down arg)
+    (dotimes (ii arg)
+      (let ((amt (if pixel-resolution-fine-flag
+                     (if (integerp pixel-resolution-fine-flag)
+                         pixel-resolution-fine-flag
+                       (frame-char-height))
+                   (pixel-line-height -1))))
+        (while (pixel-point-at-bottom-p amt) ; prevent too late (multi tries)
+          (vertical-motion -1))              ; move point upward
+        (if (or (pixel-bob-at-top-p amt) ; when beginning-of-the-buffer is seen
+                (pixel-eob-at-top-p))    ; for file with a long line
+            (scroll-down 1)              ; relay on robust method
+          (pixel-scroll-pixel-down amt))))))
+
+(defun pixel-scroll-in-rush-p ()
+  "Return if scroll is in rush.
+WHen request is delivered soon after the previous one, user is in
+hurry.  It is not ready for another smooth scroll."
+  (let* ((current-time (float-time))
+         (scroll-in-rush-p (< (- current-time pixel-last-scroll-time)
+                              pixel-dead-time)))
+    (setq pixel-last-scroll-time current-time)
+    ;; (message (if scroll-in-rush-p "normal-scroll" "pixel-scroll"))
+    scroll-in-rush-p))
 
 (defun pixel-bob-at-top-p (amt)
   "Return non-nil if window-start is at beginning of the current buffer.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Tak Kunihiro]

[-- Attachment #1: Type: Text/Plain, Size: 1152 bytes --]

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.

* ChangeLog

Add a new algorithm to avoid lag when scrolling is in rush

* lisp/pixel-scroll.el (pixel-scroll-up): Invoke 'scroll-up' when called within 'pixel-dead-time'.
(pixel-scroll-down): Invoke 'scroll-down' when called within 'pixel-dead-time'.
(pixel-dead-time): Interval that requires for the next smooth scrolling.
(pixel-last-scroll-time): Time when the last scrolling was made. (Bug#29737)


[-- Attachment #2: pixel-scroll.el.diff --]
[-- Type: Text/X-Patch, Size: 4570 bytes --]

diff --git a/lisp/pixel-scroll.el b/lisp/pixel-scroll.el
index 70244873b4..07297d61b5 100644
--- a/lisp/pixel-scroll.el
+++ b/lisp/pixel-scroll.el
@@ -82,6 +82,15 @@ pixel-resolution-fine-flag
 pixel scroll, typing \\[next-line] or \\[previous-line] scrolls the window to make it
 fully visible, and undoes the effect of the pixel-level scroll.")
 
+(defvar pixel-dead-time 0.1
+  "Interval that requires for the next smooth scrolling in second.
+On another scrolling request within this period, the scrolling
+will be carried out without pixel resolution.  If zero, scrolling
+is with pixel resolution always.")
+
+(defvar pixel-last-scroll-time 0
+  "Time when the last scrolling was made in second since the epoch.")
+
 ;;;###autoload
 (define-minor-mode pixel-scroll-mode
   "A minor mode to scroll text pixel-by-pixel.
@@ -104,35 +113,51 @@ pixel-scroll-up
 This is an alternative of `scroll-up'.  Scope moves downward."
   (interactive)
   (or arg (setq arg 1))
-  (dotimes (ii arg) ; move scope downward
-    (let ((amt (if pixel-resolution-fine-flag
-                   (if (integerp pixel-resolution-fine-flag)
-                       pixel-resolution-fine-flag
-                     (frame-char-height))
-                 (pixel-line-height))))
-      (if (pixel-eob-at-top-p)            ; when end-of-the-buffer is close
-          (scroll-up 1)                   ; relay on robust method
-        (while (pixel-point-at-top-p amt) ; prevent too late (multi tries)
-          (vertical-motion 1))            ; move point downward
-        (pixel-scroll-pixel-up amt)))))   ; move scope downward
+  (if (pixel-scroll-in-rush-p)
+      (scroll-up arg)
+    (dotimes (ii arg)                    ; move scope downward
+      (let ((amt (if pixel-resolution-fine-flag
+                     (if (integerp pixel-resolution-fine-flag)
+                         pixel-resolution-fine-flag
+                       (frame-char-height))
+                   (pixel-line-height))))
+        (if (pixel-eob-at-top-p)      ; when end-of-the-buffer is close
+            (scroll-up 1)             ; relay on robust method
+          (while (pixel-point-at-top-p amt) ; prevent too late (multi tries)
+            (vertical-motion 1))            ; move point downward
+          (pixel-scroll-pixel-up amt))))))  ; move scope downward
 
 (defun pixel-scroll-down (&optional arg)
   "Scroll text of selected window down ARG lines.
 This is and alternative of `scroll-down'.  Scope moves upward."
   (interactive)
   (or arg (setq arg 1))
-  (dotimes (ii arg)
-    (let ((amt (if pixel-resolution-fine-flag
-                   (if (integerp pixel-resolution-fine-flag)
-                       pixel-resolution-fine-flag
-                     (frame-char-height))
-                 (pixel-line-height -1))))
-      (while (pixel-point-at-bottom-p amt) ; prevent too late (multi tries)
-        (vertical-motion -1))              ; move point upward
-      (if (or (pixel-bob-at-top-p amt)     ; when beginning-of-the-buffer is seen
-              (pixel-eob-at-top-p))        ; for file with a long line
-          (scroll-down 1)                  ; relay on robust method
-        (pixel-scroll-pixel-down amt)))))
+  (if (pixel-scroll-in-rush-p)
+      (scroll-down arg)
+    (dotimes (ii arg)
+      (let ((amt (if pixel-resolution-fine-flag
+                     (if (integerp pixel-resolution-fine-flag)
+                         pixel-resolution-fine-flag
+                       (frame-char-height))
+                   (pixel-line-height -1))))
+        (while (pixel-point-at-bottom-p amt) ; prevent too late (multi tries)
+          (vertical-motion -1))              ; move point upward
+        (if (or (pixel-bob-at-top-p amt) ; when beginning-of-the-buffer is seen
+                (pixel-eob-at-top-p))    ; for file with a long line
+            (scroll-down 1)              ; relay on robust method
+          (pixel-scroll-pixel-down amt))))))
+
+(defun pixel-scroll-in-rush-p ()
+  "Return non-nil if scroll is in rush.
+When scrolling request is delivered soon after the previous one,
+user is in hurry.  When the interval is larger than
+`pixel-dead-time', it is ready for another smooth scroll and this
+returns nil."
+  (let* ((current-time (float-time))
+         (scroll-in-rush-p (< (- current-time pixel-last-scroll-time)
+                              pixel-dead-time)))
+    (setq pixel-last-scroll-time current-time)
+    scroll-in-rush-p))
 
 (defun pixel-bob-at-top-p (amt)
   "Return non-nil if window-start is at beginning of the current buffer.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Eli Zaretskii]

> Date: Mon, 01 Jan 2018 09:58:38 +0900 (JST)
> Cc: eliz@gnu.org, 29737@debbugs.gnu.org, tkk@misasa.okayama-u.ac.jp
> From: Tak Kunihiro <tkk@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.)

Thanks.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Tak Kunihiro]

>> Date: Mon, 01 Jan 2018 09:58:38 +0900 (JST)
>> Cc: eliz@gnu.org, 29737@debbugs.gnu.org, tkk@misasa.okayama-u.ac.jp
>> From: Tak Kunihiro <tkk@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.

bug#29737: 27.0.50; pixel-scroll-mode is laggy

[Eli Zaretskii]

> Date: Sun, 07 Jan 2018 11:06:26 +0900 (JST)
> Cc: valentjedi@gmail.com, 29737@debbugs.gnu.org, tkk@misasa.okayama-u.ac.jp
> From: Tak Kunihiro <tkk@misasa.okayama-u.ac.jp>
> 
> 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.

I pushed the changes, and I'm marking this bug done.

Thanks.