Sixel image rendered on the last line of terminal causes a scroll, messes up the whole screen

[benjajaja]

There is DECSDM, but this causes the image to be rendered at 0,0 no matter what, and the implementations also seem to be wildly different.

No idea how to fix it other than not rendering in the last line of the terminal.

[j4james]

In theory it should be possible to render a Sixel image on the last line, but you need to limit the height to a multiple of 6 that will fit in the cell height. For example, if your cell height is 20px, you can fit an 18px high Sixel image in that space, but anything more than that is going to round up to a height of 24px, which will trigger a scroll.

So if you really want to fill the last line, you'd have to start your image a couple of rows up, so you can use a height that's both a multiple of 6, and a multiple of the cell height. For example, with a cell height of 20px, you can output a 60px image, with the first 40px being transparent. That would exactly span the bottom 3 rows, and shouldn't trigger a scroll.

In practice, though, many terminals incorrectly position the text cursor below the image, so they will still trigger a scroll even when the image fits. That's a terminal bug though, and it's worth noting that those terminals will potentially not even be able to fill the second last line of the screen without scrolling.

As for DECSDM, I know some apps/libraries have used that specifically for writing to the last line. But as you've noted, it forces the image to start at 0,0, so you have to add a lot of padding to get the image in the correct position. And again that depends on the terminal supporting transparency.

You should also be aware that DECSDM isn't universally supported, and for a long time many terminals implemented it backwards, because some of the DEC documentation had it backwards. I think most have corrected that by now, but it's possible there may be some that still have it backwards.

[janTatesa]

Is it possible to just disable scrolling in the terminal with some sort of a control sequence?

[benjajaja]

We must render in multiples of the font-size, to avoid stale character artifacts, so we can't really try to do some multiple of six for sixels.

So I don't think we can do much about this, the best we can do is put a big fat warning in the readme, and advise to never render an image on the last line of the screen.

[janTatesa]

What if we automatically cropped the image to avoid the scrolling?

[benjajaja]

We could maybe do that for specifically for sixels, but I would make it configurable, because some users might not need this, for example if the program never renders in the last row because it has a status bar, or always has a border, or something like that.

[janTatesa]

If the image is not rendered in the last line it would not crop the image. A config option is not necessary as it can be detected with the library

[benjajaja]

I'm not sure if I understand correctly, but I think you mean that the library can detect if we're rendering in the last line of the screen, which I think is not possible. The library renders into a buffer, which might be the screen, or something else.

[janTatesa]

But even if the buffer is not the screen, rendering the image beyond the buffers bounds is not the desired behaviour

[benjajaja]

But the issue is not rendering beyond the buffer, the issue is rendering into the last line of the buffer (or given area), and the library not possibly knowing whether that last line would be the last line of the screen.

[janTatesa]

Then I guess add an .on_last_line method to turn on the feature

[AutumnMeowMeow]

As for DECSDM, I know some apps/libraries have used that specifically for writing to the last line. But as you've noted, it forces the image to start at 0,0, so you have to add a lot of padding to get the image in the correct position. And again that depends on the terminal supporting transparency.

Also, xterm for a long time (maybe still) has a hardcoded max of 1000x1000 pixels, so anything more than 1000x1000 pixels away from won't be renderable. (xterm actually would not even place the image at all if it was bigger than the max size, rather than truncate.)

[j4james]

Also, xterm for a long time (maybe still) has a hardcoded max of 1000x1000 pixels

That's still the default, but it can be increased with the maxGraphicSize resource (at least according to the documentation).

[benjajaja]

Closing, as this doesn't seem possible to fix.

[AutumnMeowMeow]

This is actually possible now without DECSDM in at least two terminals via DECSET 8452. xterm does document support for it, but did scroll: I think that xterm may accept this as a bug to fix. For now, one can use DECSDM on xterm, and DECSET 8452 on other terminals that report support for it (via DECRQM/DECRPM), and get images on the bottom row with sixel.

Here is foot displaying sixel images without scrolling: https://gitlab.com/-/project/6684366/uploads/576368b45315a940e2c623f9b66495e3/simplescreenrecorder-2025-11-16_10.13.10.mp4