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

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  yantar92@posteo.net,  acm@muc.de,
>   incal@dataswamp.org,  emacs-devel@gnu.org
> Date: Wed, 20 Sep 2023 20:21:39 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > On the high-level design level, it should be clear without any need
> > for benchmarking that separating redisplay from the main thread could
> > bring benefits.  Isn't that what every GUI application out there does?
> > So trying to think about that is always a good thing, IMO.
> 
> Au contraire, almost all GUI program limit redisplay to their main
> threads.

??? On Windows at least, the UI thread is a separate thread, not
necessarily the main one.  We have that in Emacs on Windows.

> Emacs is not a video game, for which the touchstone of performance is a
> measurement taken in ``frames-per-second''.  It is a text editor that
> only updates the display subsequent to an editing operation.  That is,
> unless you perform more than 60 edits per second and expect an
> intervening redisplay after each edit.

This sounds as if you are talking about something other than Emacs,
really.  Try running some day with all the redisplay optimizations
turned off and with enough windows/frames visible, and you will see
how far we are from 60 fps goal.  There's a lot of room for
improvement even without being a video game, just an editor.

Or visit Reddit and see how many users complain that Emacs is slower
in displaying stuff than, say, VSCode.