Re: Emacs [scratch/igc 6682d0e6c96] crash on Linux 6.6.41 KDE 6.0.5, wayland

[Eli Zaretskii]

> Date: Tue, 03 Sep 2024 15:57:05 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: execvy@gmail.com, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> > And I don't feel any pauses with the igc branch, either.
> 
> I'm not sure key repeat is a particularly good test of GC
> responsiveness; it appears to be heavily influenced by non-GC factors,
> and when holding C-n, redisplay stops at some point and only catches up
> when the key is released.
> 
> If I set the keyboard repeat rate to 255 using 'xset', which appears to
> be the maximum supported, an MPS Emacs running my production session
> (some 200 buffers) ends up exhibiting this behavior when holding C-n, so
> only the first, non-repeated command is displayed properly.  A
> newly-launched MPS Emacs does fine with xdisp.c in fundamental mode, but
> in C mode it ends up scrolling for a bit, presumably until font-lock
> does its work, then not scrolling until 'n' is released again.

I see none of this, but my auto-repeat rate is about 30/sec.

> It would be nice to change this behavior to force some redisplay even
> when Emacs can't keep up with keypresses, but I don't think this is an
> MPS issue at this point.

For me, the MPS build is much snappier scrolling through xdisp.c (in C
mode) than the "normal" build.

> Is it true that we only redisplay once all key presses have been
> handled?

We redisplay when we get back to the main loop and there's no input
pending.  Depending on the input rate and the time it takes to process
each key, it could go either way.