Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[Tomas Hlavaty <tom@logand.com>]

On Thu 03 Dec 2020 at 17:13, Eli Zaretskii <eliz@gnu.org> wrote:
>> > It seems like unless you're going to teach Emacs to entirely draw
>> > itself to the framebuffer, there will always be glitches like the
>> > cursor messing up images since TUI Emacs won't be aware of what pixels
>> > of the framebuffer have been drawn over independently of the linux VT
>> > displaying lines of Emacs' characters.
>> 
>> The cursor could be turned off.
>> 
>> Are there other glitches which cannot be solved?
>
> 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.

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

If I do not do anything, Emacs will not do anything (except updating
clock in the mode-line perhaps, which is outside the buffer with the
image).

Now after that single event, the image should be redrawn but that's it.