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