Re: Implementing image support for kitty terminal

[Jose A Ortega Ruiz <jao@gnu.org>]

On Fri, Sep 09 2022, Eli Zaretskii wrote:

>> From: Jose A Ortega Ruiz <jao@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 09 Sep 2022 00:32:32 +0100
>> 
>> also, a term emacs running inside kitty or foot in wayland is very
>> noticeably faster than the graphical counterpart
>
> That advantage will almost certainly go away, at least partially,
> if/when we implement the new backend as proposed by Gerd, because some
> of that advantage is due to the simplicity of the TTY frame geometry
> and text layout, something that will be lost as soon as we support
> variable-height screen lines on TTY frames.

hmm. in the image display protocol that kitty supports, everything can
be done, if desired, in terms of rows and columns, and the terminal
itself works, as far as i understand, in terms of character cells:
couldn't we retain that modus operandi?  for instance, displaying an
image would amount (logically) to displaying a bunch of lines of text,
all of the same length, with the only peculiarity that maybe the cells
on the borders wouldn't look completely filled.  (i was at first even
imagining an admittedly obnoxious hack consisting of simply writing
first n rows of m arbitrary characters, and then using the image
protocol to ask kitty to fill that character rectangle with the image,
because i thought that for the TTY terminal it was easy to determine the
rows and columns available in a given window around a given position).

jao