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

[Eli Zaretskii]

> From: Tomas Hlavaty <tom@logand.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 03 Dec 2020 22:02:47 +0100
> 
> >> The images do not travel via pipe.  Only meta-data like filenames,
> >> coordinates and handles.
> >
> > Yes, I understood that much.  But that doesn't matter: communicating
> > with a spell-checker in the flyspell-mode case also sends just a small
> > number of words in each direction, and yet the slow-down is
> > considerable, sometimes downright annoying.
> 
> Is it an appropriate comparison?

Yes, IME.  It shows what happens when Emacs needs to communicate with
an external subprocess at a high frequency.  Which is what will happen
if your proposed design will be used as a general-purpose feature for
drawing images in Emacs.

> I do not intent to scroll through a large buffer with lots images.  Even
> if I did, there is no evidence that it would suffer the problems in the
> above example.  w3m manages just fine.  My use case is something like
> image-mode or doc-view or pdf-tools.  emacs-framebuffer already does
> that for many image and document types and I have no problems with
> speed.

So you are talking about making Emacs support only your use case?  Not
about a feature that allows any other legitimate use case in Emacs
which could involve images?

> > Sending the image spec and receiving the dimensions and other image
> > attributes, yes.  And I presume that the sub-process needs some time
> > to calculate the answer (because at least some queries require to load
> > and process an image).
> 
> This is a non-issue.  Images usually do not change those attributes
> quickly, if at all.  So this can usually be cached or even calculated
> just once.

That "once" is what I'm talking about.  Imagine going through a
directory of image files one by one.

> Again, my use-case is like that of image-mode, doc-view and pdf-tools.
> There is a file, say /tmp/a.png, I open the file in a buffer and the
> buffer will show the png image.  Or there is a file, say /tmp/a.pdf, I
> open the file in a buffer and the buffer will show the pdf document.

That's a very limited use case.  So much so that I doubt if it's even
justified.  After all, you can already display images on the console,
so why do you insist to show it inside an Emacs window, of all the
places.  People are already complaining about the limitations of
doc-view and similar modes.

> > Emacs doesn't draw anything because it knows what's on the glass and
> > what _should_ be on the glass, and compares the two to decide what
> > should be redrawn.  But you want to draw on parts of the screen behind
> > Emacs's back, so it won't know whether something changed.  And you
> > OTOH have no way of knowing where Emacs have redrawn something during
> > the last redisplay cycle.  So you will have to redraw your images each
> > time Emacs finishes a redisplay cycle, regardless of whether it
> > changed anything on the glass in the area of an image.  These
> > redisplay cycles happen at very high frequency -- usually, Emacs
> > enters redisplay, quickly decides what needs to be redrawn, and then
> > does whatever has to be done and exits redisplay.  It tries very hard
> > not to redraw the parts that haven't changed, and that is why there's
> > no flickering.  But I don't see how you could prevent the flickering
> > of those add-on images, because without knowing which parts of the
> > screen changed, you will have to redraw them very frequently.
> 
> This is not an issue.
> 
> You can try and see it easily.
> 
> Start emacs on the console.
> 
> Start shell in Emacs: M-x shell
> 
> Execute: $ cat /dev/urandom >/dev/fb0
> 
> Observe what Emacs draws.  I can see blinking cursor.  Part of the
> *shell* buffer was drawn and line and column indicators on the
> mode-line.  Everything else remains unchanged.

What you don't see is the frantic activity going on in the display
code behind the scenes.

Look, you can disregard what I'm saying and then later learn this
stuff the hard way.  It's okay, it will be a fine journey and very
educational, I can assure you.  I'm just trying to warn you about the
hidden rocks under the surface.  I will stop now.