weird behaviour when visuals keep moving down beyond the last row

[joseluis]

I've made an example that showcases the problem. It's intented to be run best using a small terminal size.

It first shows an ncplane moving outside the terminal window, and dissapearing in the horizon without any problem. But when trying to do the same with an ncvisual the result doesn't look right.

In kitty, when the plane reaches the bottom border, the plane stops displacing over the Y axis but it keeps moving over the X axis even after the right border is surpassed, but then it displaces negatively 1 cell in the Y axis.

In the rest of the terminals I've tried (wezterm, xterm) when the visual reaches the bottom border it leaves a long trail of rendered visuals in its path.

[dankamongmen]

yep, this is known. i think i have a bug open on it somewhere else; let me look.

[dankamongmen]

so here are the facts of the situation:

• for sixels, we must never generally allow the last row to be broached; doing so will lead to madness
• for kitty, doing so is fine so long as we supply C=1
• otherwise (older kitty), we must not allow the last row to be breached

so the difficulty here is what to do when that last line is broached. we want to allow its "logical" broaching, where (say) a 2-row graphic is placed on the penultimate line, resulting in only its top line being displayed. doing so requires cutting up the graphic on the fly, which requires the ability to restore it (imagine moving to the bottom, then moving up towards the top).

in a mosaic world (#1563), this is beyond trivial. in a non-mosaic world, this is tough, but obviously doable. the big difference between this and regular wipes is that we must actually excise the lower lines entirely.

ideally i'd resolve this via mosaics.

[joseluis]

The mosaic world looks fantastic. This could wait for it. But I see you removed that from the 3.0 milestone. I guess it's not gonna be so easy, huh.

[dankamongmen]

The mosaic world looks fantastic. This could wait for it. But I see you removed that from the 3.0 milestone. I guess it's not gonna be so easy, huh.

it will be the most difficult part of this project, and even if i do it perfectly, experimentation suggests that some terminals will slow to a crawl using this method =[ but it's absolutely the way to go, and will fix pretty much all existing problems with bitmap graphics.

i expect it to be the primary effort of 3.x development.

[dankamongmen]

see also #1539

[dankamongmen]

this is not the same as #2379, but rather a superset of it. that one just covers not creating sixel visuals that overlap the lowest row.

this is moving to trans3.0, and it'll be done with mosaics.

until then, we might want to prevent this from happening via a guard in ncplane_move_yx(), but we'd probably need place it in multiple places...idk.

[dankamongmen]

see also #2566