Re: Would there be a drawback of using the same graphical toolkit on every platform?

[Eli Zaretskii]

> Date: Sat, 19 Feb 2022 19:20:35 +0000
> From: emacsq <laszlomail@protonmail.com>
> Cc: Po Lu <luangruo@yahoo.com>,
>  emacsq via Users list for the GNU Emacs text editor
>  <help-gnu-emacs@gnu.org>
> 
> > That is because
> > Emacs reverse the framowork roles, which does not work always well with 
> > toolkits
> > that are designed to be in driving seat of the application main loop and
> > display. There is an interesting post about Emacs and how it threats 
> > graphical displays by D. Colascione
> 
> An excerpt:
> 
> "One simple approach to implementing redisplay is to just redraw all the 
> frames, windows, and buffers from scratch. This approach might be good enough 
> for a shitty 2016 video game like Nuclide or Eclipse, but not Emacs.
> Emacs was designed for much more constrained systems. Men were men, women 
> were women, and bandwidth was expensive. Consequently, Emacs tries very hard 
> to optimize redisplay."

This is almost unrelated to the issue at hand, which AFAIU is what
toolkits to use.  Toolkits have almost no role in the Emacs redisplay
and no influence on it

> Since today bandwidth is not expensive, does this mean Emacs could
> move avay from the current redisplay to a simpler method which just
> redraws everything when required?

No.  Redrawing all the windows on all the frames would be unbearably
slow, even today.  A small example: in Emacs, even moving the cursor
one buffer position to the right or to the left triggers a redisplay
cycle.  Redrawing everything upon each cursor movement would be very
slow and will cause an annoying flickering.

Redisplay optimizations still count, even today.  One (but not the
only one) reason is that computers became faster, but people's
expectations from them changed accordingly.  No one would like to have
a 0.5 sec delay in response to some command like cursor motion of
window scroll.