Re: Implementing image support for kitty terminal

[Eli Zaretskii <eliz@gnu.org>]

> From: Jose A Ortega Ruiz <jao@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 07 Sep 2022 21:09:40 +0100
> 
> > This is a different level: the level of actually delivering the stuff
> > to the glass.  I think it's much easier than what was bothering me.  I
> > was talking about the level of layout: the one that knows how much
> > space each "display element" (character, image, stretch of white
> > space, etc.) takes on display.  On TTY frames, there's a built-in
> > assumption that every display element takes just one pixel in the
> > vertical direction, and each screen line takes one pixel on display.
> > That will have to change for image support, I presume.
> 
> in x terminal emulators, by "pixel" here you mean one terminal "cell"
> (the extend of a displayed ascii char), right?

Yes.

> >> I am assuming here that the display engine (for a tty) knows somehow
> >> that it's printing a very lage "character" that is going to spawn
> >> several rows and columns, and also that we can always tell how wide and
> >> tall the window around point is when we display this "character".
> >
> > That's exactly the problem: it currently assumes that no display
> > element takes more than one row, and that each row is exactly one
> > pixel (= one character height) tall.
> 
> aha, i see.  so what's needed, for instance, is a way of managing blocks
> of such display elements, that are always rendered all at once...

Something like that would be a significant change in the current
design, which handles each screen line separately.

> or are there better ways of accomplishing the same?

That's exactly the question: how to do better?