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.