Re: Emacs design and architecture. How about copy-on-write?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> We don't have to interpret "60 fps" too literally.  A possible
> Emacs-friendly interpretation is "60 display updates per second", for
> example.  Here's an experiment to try:
>
>   (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
>
> Then visit a large file and lean on C-z.
>
> Another possibility is to lean of C-v.
>
>> I don't type 60 characters per second -- so there is no reason for Emacs
>> to display at 60 frames per second.
>
> Leaning on a key, as in the examples above, will produce input events
> at a relatively high rate (albeit usually lower than 60 per sec), each
> one of them requiring some kind of redisplay.  Even leaning on C-f
> triggers redisplay at high rate.  I suggest to try this in various
> non-dash-Q configurations and see how we fare in these situations.
> There's nothing outlandish in expecting an editor to keep up with
> high-rate scrolling commands, I hope you agree with that at least.

I agree, but slow scrolling is not redisplay's fault.  If I type:

  M-: (jit-lock-fontify-all) RET

or enable c-ts-mode prior to leaning on C-v, within an Emacs session
with a 790 MiB resident set that has been executing continuously for 32
days, then Emacs scrolls (xterm.c and xdisp.c) as fast as any other
editor on my system.  Conceivably even faster than some others, that is
to say the VS Code demonstration site at vscode.dev.

> You can doubt all you want, but some of what they say is definitely
> related to redisplay, IMNSHO.

Any examples?  Because my experience with p-s-p-m demonstrates that
redisplay is absolutely capable of matching the display refresh rate
while scrolling, the very cornerstone of
`pixel-scroll-precision-use-momentum'.