alacritty & wezterm visual output is off by 1 row, and other visual problems.

[joseluis]

Problems with wezterm:

I noticed in several examples starting looking bad in wezterm.

E.g. the pixel-cell example in this repo shows the original pixel cell duplicated in the row under it:

The visual example in notcurses-rs repo shows a last row of colored pixels that should be completely covered, (and it is in other terminals):

In the same repo, the plotters-examples shows the info panel duplicated one row down as well.

Problems with alacritty:

I noticed similar problems happens with Alacritty. Output is also off by 1 row, but also happens that the background black color is shown as transparent?:

Note that this example shows perfectly well when I'm running it in alacritty inside tmux, i.e. without pixel support.

with xterm everything shows OK:

[dankamongmen]

yeah, i haven't been able to build wezterm on my desktop recently. this is a recent nightly?

[joseluis]

this is the latest stable from august, I'll try the latest nightly

[joseluis]

it happens the same with the latest nightly in all previous examples except the visual one, which strangely is the only one that looks good now.

[dankamongmen]

i just made some changes which might or might not affect this; i'd appreciate a retest if it's no trouble.

[dankamongmen]

i downloaded Downloads/WezTerm-nightly-Ubuntu16.04.AppImage (despite me having a Debian Unstable machine; hopefully this isn't an issue). i did indeed notice some troubles. most worrying is this entry in the logs:

 2021-09-20T06:24:16.891Z ERROR wezterm_term::terminalstate::performer > kitty_img: data should have been materialized in coalesce_kitty_accumulation: invalid input parameter
 2021-09-20T06:24:16.892Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id

when running the interp PoC...

[dankamongmen]

i downloaded Downloads/WezTerm-nightly-Ubuntu16.04.AppImage (despite me having a Debian Unstable machine; hopefully this isn't an issue). i did indeed notice some troubles. most worrying is this entry in the logs:

 2021-09-20T06:24:16.891Z ERROR wezterm_term::terminalstate::performer > kitty_img: data should have been materialized in coalesce_kitty_accumulation: invalid input parameter
 2021-09-20T06:24:16.892Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id

when running the interp PoC...

this corresponds with the third image not being visible

[dankamongmen]

i'm seeing problems running bitmapstates on WezTerm. i seem to recall some possible problems with its implementation of the animation protocol? but i'm not sure that would be relevant to your problems; i'd need tear apart your code.

[dankamongmen]

ok with WezTerm 20210930-172131-959da7f0 bitmapstates is working fine.

[dankamongmen]

yeah most everything is looking exactly like i'd expect in WezTerm =[. i'm using the following config:

[schwarzgerat](1) $ cat ~/.config/wezterm/wezterm.lua 
-- wezterm config --
local config = {
    warn_about_missing_glyphs = false,
    enable_kitty_graphics = true,
}
return config
[schwarzgerat](0) $ 

[dankamongmen]

i just upgraded to 20211010-192942-d461c1c0, and get the same good results, though glyphs all suddenly look like shit through what i'm pretty sure is no fault of my own. wezterm changes a lot from day to day. just like us, i suppose.

[dankamongmen]

alright, i've been dreading this one, but let me put some time into it today.

[dankamongmen]

ok with wezterm TERM_PROGRAM_VERSION="20211021-185611-04768fd1" i'm running interp and only getting one output, so that's definitely a problem.

i'm going to resolve that, and then if you could file these problems where they still remain as individual issues, that would help me tremendously.

[dankamongmen]

interp on current wezterm:

[dankamongmen]

we're seeing this in the wezterm console:

 2021-10-26T12:55:40.413Z INFO  wezterm_term::terminalstate::kitty     > using 335558976 RAM for images, pruned 89856
 2021-10-26T12:55:40.415Z INFO  wezterm_term::terminalstate::kitty     > using 335560224 RAM for images, pruned 89856
 2021-10-26T12:55:40.417Z INFO  wezterm_term::terminalstate::kitty     > using 335560224 RAM for images, pruned 89856
 2021-10-26T12:55:40.418Z INFO  wezterm_term::terminalstate::kitty     > using 335560224 RAM for images, pruned 89856
 2021-10-26T12:55:40.418Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id
 2021-10-26T12:55:40.418Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id
 2021-10-26T12:55:40.418Z ERROR wezterm_term::terminalstate::performer > kitty_img: no matching image id

[dankamongmen]

we try to position five different consecutive image IDs:

^[[2;1H^[_Ga=p,i=9127379,p=1,q=2^[\^[[4;2H^[_Ga=p,i=9127380,p=1,q=2^[\^[[4;15H^[_Ga=p,i=9127381,p=1,q=2^[\^[[4;28H^[_Ga=p,i=9127382,p=1,q=2^[\^[[4;41H^[_Ga=p,i=9127383,p=1,q=2^[\

and we definitely seem to have loaded these....

[dankamongmen]

yeah it looks like wezterm is not doing LRU for its graphic management? that seems a recent regression. anyway, this has nothing to do with the originally-reported problem.

[dankamongmen]

yeah on a fresh wezterm this isn't happening.

[dankamongmen]

it does look like shit, though

and this is closer to what @joseluis was reporting in the original bug, so i'll work on fixing this (and file a bug upstream)

[dankamongmen]

we already have a bug filed on wezterm, wez/wezterm#1156

[dankamongmen]

hrmmm but it doesn't reliably look like shit, argh

[dankamongmen]

hrm i got the enlongated cellpix graphic as soon as i switched from kitty graphics in wezterm to sixel. @joseluis , i assume you're using sixel with wezterm?

[joseluis]

hrm i got the enlongated cellpix graphic as soon as i switched from kitty graphics in wezterm to sixel. @joseluis , i assume you're using sixel with wezterm?

yes! I wasn't aware it supported the kitty protocol too, lol

[dankamongmen]

ncplane_new_internal:543:Created new 2x1 plane "bmap" @ 1x0
ncvisual_render_pixels:1052:pblit: 26x12 <- 0x0 of 26/12 stride 64 @0x0 0x555f2dc117e0 12
ncvisual_render_pixels:1069:cblit: rows/cols: 2x1 plane: 2/1 out: 30/12
ncplane_resize_internal:728:2x1 @ 1/0 → 2/1 @ 1/0 (want 2x1 from 0/0)
ncplane_new_internal:543:Created new 6x12 plane "" @ 3x1
ncplane_new_internal:543:Created new 6x12 plane "bmap" @ 3x1
ncvisual_render_pixels:1052:pblit: 156x144 <- 0x0 of 26/12 stride 64 @0x0 0x555f2dc117e0 12
ncvisual_render_pixels:1069:cblit: rows/cols: 6x12 plane: 6/12 out: 156/144
[swscaler @ 0x555f2dc368c0] Forcing full internal H chroma due to input having non subsampled chroma
ncplane_resize_internal:728:6x12 @ 3/1 → 6/12 @ 3/1 (want 6x12 from 0/0)
ncplane_new_internal:543:Created new 6x12 plane "" @ 3x14
ncvisual_render_pixels:1052:pblit: 156x144 <- 0x0 of 26/12 stride 64 @0x0 0x555f2dc117e0 12
ncvisual_render_pixels:1069:cblit: rows/cols: 6x12 plane: 6/12 out: 156/144
ncplane_resize_internal:728:6x12 @ 3/14 → 6/12 @ 3/14 (want 6x12 from 0/0)
ncplane_new_internal:543:Created new 6x12 plane "" @ 3x27
[swscaler @ 0x555f2dc368c0] Forcing full internal H chroma due to input having non subsampled chroma
ncvisual_render_pixels:1052:pblit: 156x144 <- 0x0 of 156/144 stride 576 @0x0 0x555f2dc6d8c0 12
ncvisual_render_pixels:1069:cblit: rows/cols: 6x12 plane: 6/12 out: 156/144
ncplane_resize_internal:728:6x12 @ 3/27 → 6/12 @ 3/27 (want 6x12 from 0/0)
ncplane_new_internal:543:Created new 6x12 plane "" @ 3x40
ncvisual_render_pixels:1052:pblit: 156x144 <- 0x0 of 156/144 stride 576 @0x0 0x555f2dc6d890 12
ncvisual_render_pixels:1069:cblit: rows/cols: 6x12 plane: 6/12 out: 156/144
ncplane_resize_internal:728:6x12 @ 3/40 → 6/12 @ 3/40 (want 6x12 from 0/0)
ncplane_resize_internal:728:38x84 @ 0/0 → 38/84 @ 0/0 (want 38x84 from 0/0)
engorge_crender_vector:1499:Resizing rvec (0) for 0x555f2dc11010 to 3192
notcurses_rasterize_inner:1213:pile 0x555f2dc11010 ymax: 38 xmax: 84
notcurses_rasterize_inner:1223:Sprixel phase 1
clean_sprixels:871:Phase 1 sprixel 9127379 state 3 loc 1/0
clean_sprixels:871:Phase 1 sprixel 9127380 state 3 loc 3/1
clean_sprixels:871:Phase 1 sprixel 9127381 state 3 loc 3/14
clean_sprixels:871:Phase 1 sprixel 9127382 state 3 loc 3/27
clean_sprixels:871:Phase 1 sprixel 9127383 state 3 loc 3/40
notcurses_rasterize_inner:1228:Glyph phase 1

[dankamongmen]

this looks like a pretty straight wezterm bug. i've extracted the sixel i'm emitting, and will file a bug upstream.

longsixel.txt

[dankamongmen]

wez/wezterm#1270 has been created for this issue.

[dankamongmen]

i think the alacritty problems you mention might be due to #2142

[dankamongmen]

not much i can do about the wezterm sixel-mode problem, which is still present. i've filed that bug and will provide more info when/if i can. it works properly in wezterm's kitty mode. closing this up for 3.0.0 triage.