emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was R


From: Eli Zaretskii
Subject: Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)
Date: Fri, 04 Dec 2020 10:00:25 +0200

> From: Tomas Hlavaty <tom@logand.com>
> Cc: akira@akirakyle.com, emacs-devel@gnu.org
> Date: Thu, 03 Dec 2020 22:15:08 +0100
> 
> > Even turning the cursor off doesn't guarantee that Emacs will not
> > trigger overwriting of the images.  For example, sometimes Emacs moves
> > the cursor by writing newline characters, which could potentially
> > overwrite the image if the console implements that by writing spaces
> > or clearing each line to EOL.
> 
> But that example is a single event and does not cause glitch or
> flickering.

Why do you assume it's a single event?  Whenever Emacs decides that
moving the cursor from some coordinates to other coordinates should be
done by writing newlines, it will always do that when it needs to.
That could be every redisplay cycle, depending on the situation.

> Emacs usually does not move the cursor by writing newline characters
> because it feels like it.  And it does not do that frequently.

If you build your software on these assumptions, I can assure you it
will break in some use cases.

> If I do not do anything, Emacs will not do anything

That is profoundly incorrect.  First, "I do not do anything" doesn't
mean Emacs doesn't: there are timers running in Emacs all the time,
even if it's "emacs -Q".  More importantly, what looks to you like
"Emacs doesn't do anything" is the result of redisplay cycles that do
quite a lot of processing, before they decide that nothing should be
redrawn on the glass, and if you assume that processing will never
include moving a cursor, you are building your code on shaky grounds.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]