Last line in terminal while playing animation is not used / empty / only cursor

[crmabs]

Hello
And I start with the highest five for this amazing stuff. Respect.

What is the proper way to use the last line of the terminal while playing back animation? Basically I want to display chafa stuff fullscreen - from top to bottom.
https://photos.app.goo.gl/w6Z55vwFN2DrWbd68
The brownish gap is the last line in the image.

I used tput smcup to check if it makes any difference. It does not in my case. The whole thing runs in a fullscreen alacritty like a greased lightning but I'm not able to properly solve this.
Well, I'm saying "not able" because one can always resize the terminal / the window itself - adding one more line / some more height pixels - and the last line gets offscreen. But I have a hunch that there is a less hacky solution.

Many thanks!
Andras

[hpjansson]

Hi, thanks for filing the issue.

There is currently no convenient way to do this. The reason is that chafa is more like a printer than a viewer -- it doesn't try to take over the whole terminal display, but rather leaves the cursor enabled and prints images inline. Terminals don't always do what we want (for example, sixels by default leave the cursor on the row below the image, and the Kitty terminal will wrap the cursor around when something is printed in the last column, effectively placing it on the next row). So I reserved the row below the image to park the cursor between frames, to ensure it doesn't scroll out the topmost row of the image.

That said, here's a potential workaround. The following pipeline will tell chafa to use the entire terminal and adds a sed step to remove the end-of-frame newline:

chafa --clear file.gif -s $(tput cols)x$(tput lines) | sed '$!N; s/\n\(.\[0H\)/\1/; P;D'

When doing this, animations will only play once (since it's a pipeline, chafa assumes it is non-interactive and prefers to not get stuck). If you're building chafa yourself, and you have the latest master as of right now, you should be able to add -d inf to the command line and have the animation play forever.

This is obviously pretty inconvenient, so maybe we need a --fullscreen switch or something like that. The backend has support for arbitrary escape sequences now, so it's better suited to it than before.

Let's keep this issue open until I can implement it. And please let me know if you're still having trouble!

[crmabs]

Works! And for my current purposes it's a perfect solution: I needed to hold out the last frame.
I thought sed would kill the performance, but it did not affect it at all. Just by looking at it - no measurements done. So, many thanks for the solution!

I love the idea to have a --fullscreen switch in general. First I only found chafa a cool geek toy - nothing useful - but recently I got totally hooked on it. We got multiple (30+) machines with projectors as displays and many administrative / configuration tasks are aided with chafa. "Can you print it with bigger letters?" IPs, names, config values, etc. So, the jaw dropping combo is to watch an .svg file with chafa and pump the required text or even graphics into that svg.
Other brilliant usage of the mentioned setup is when I manage those multiple machines with cluster-shh so each machine has a small terminal window open with very small letters and I just want to print out a status or something and I don't want to lean close to the monitor and read the small letters.

[kovidgoyal]

You use C=1 in the kitty graphics protocol to not have the cursor move when placing images. See the note at the end of https://sw.kovidgoyal.net/kitty/graphics-protocol/#display-images-on-screen

[crmabs]

kitty did not run on nvidia jetson nano. it was missing opengl driver or something like that. so i went for alacritty. i assume c=1 won't work there. does it?

[hpjansson]

@crmabs Cool -- this story made my day :)

@kovidgoyal I did notice that, but thought 0.20.0 was a bit too recent. I'd like to support older versions too, with a window of 2-3 years or so. And bottom-right is similar to how sixels does it; it'd be nice to handle both the same way.

I'm not ripping on Kitty at all by the way, it's great. The issue is rather that predicting the cursor position after output is hard with four different image protocols (sixels, kitty, iterm, character art) and terminals with subtle differences in how they treat output in the final row/column.

Just to clarify what I'm talking about, with C=0 I'd expect the cursor to behave like it does with text in the final column -- a newline there gets swallowed. In the attached screenshot, both images are followed by a newline, but it leaves a blank row after the first image and not the second. Similar example with plain text below.

[kovidgoyal]

On Wed, Sep 08, 2021 at 08:15:32AM -0700, Hans Petter Jansson wrote: @crmabs Cool -- this story made my day :) @kovidgoyal I did notice that, but thought 0.20.0 was a bit too recent. I'd like to support older versions too, with a window of 2-3 years or so. And bottom-right is similar to how sixels does it; it'd be nice to handle both the same way.

You expect newer versions of chafa to be installed on systems with older versions of kitty?

I'm not ripping on Kitty at all by the way, it's great. The issue is rather that predicting the cursor position after output is hard with four different image protocols (sixels, kitty, iterm, character art) and terminals with subtle differences in how they treat output in the final row/column.

Yeah sure, I was just pointing out C=1 in case you missed it.

[hpjansson]

You expect newer versions of chafa to be installed on systems with older versions of kitty?

Yes. There are many ways it can happen. Packagers may be behind on one package but not the other, or the user installed chafa from source, or placed the statically linked binary on an older workstation distro. Or maybe they're ssh'ing into a newly installed server and running chafa there, but the kitty on their workstation is older.

[hpjansson]

kitty did not run on nvidia jetson nano. it was missing opengl driver or something like that. so i went for alacritty. i assume c=1 won't work there. does it?

No, C=1 is a parameter to kitty's image protocol, which is not implemented in alacritty afaict. It looks like they're working on sixel support, by the way: alacritty/alacritty#4763

[ghost]

This doesn't work in all sixel terminals yet, but: if you set DECSDM, and draw your image in a larger transparent picture that starts at the top-left corner (which might require knowing the cell aspect ratio, depending on what you're trying to do), then you can put the picture anywhere onscreen (though practically only within 1000x1000 thanks to xterm not providing means to make that limit bigger -- XTSMGRAPHICS isn't working). (Also reset DECSDM when you're done!)

So lol, lots of ifs and and buts, yet the result could be cool.

[hpjansson]

Hah, that's pretty clever. Still a little too clever for Chafa, perhaps -- I'm trying to limit the hacks to keep it maintainable (not only do terminal emulators do different things, with corner cases/"recent" features like this it's more likely that their behaviors will change over time, so it's hard to have it keep working outside a carefully controlled environment. Or so I imagine :)

[ghost]

I'm trying to limit the hacks to keep it maintainable

I really appreciate that as an explicit design goal. :)

Off-topic...

It's a large part of why I haven't included image protocol(s) that treat text-and-images as fundamentally different entities: it would either be too easy to make things that could never appear similar to that on stock xterm e.g. image-->text-->image in one cell, or alternatively I would need a game-engine-like composition model that an application started in ncurses-land would have a hard time migrating up to as operations on image layer(s) would be entirely different to the text layer.

Though I am willing to get into "Good Image Protocol" if that is implemented, because it has an explicit rule that text operations will work on image cells the same way. And contradicting myself a little, image-->text-->image does have a semi-graceful fallback available for stock xterm, so I guess the real hurdle for me mentally is the images-and-text-are-different idea.

[hpjansson]

@crmabs I ended up making this a little bit more flexible. You can now get fullscreen with --margin-bottom 0, or if you're just viewing a still frame and have a tall prompt --margin-bottom <height_of_prompt> can be used to prevent the image from scrolling out when the prompt is shown. I'd add it to an alias to save some typing.