Closed joseluis closed 2 years ago
yeah, i haven't been able to build wezterm on my desktop recently. this is a recent nightly?
this is the latest stable from august, I'll try the latest nightly
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.
i just made some changes which might or might not affect this; i'd appreciate a retest if it's no trouble.
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...
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
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.
ok with WezTerm 20210930-172131-959da7f0 bitmapstates
is working fine.
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) $
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.
alright, i've been dreading this one, but let me put some time into it today.
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.
interp
on current wezterm:
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
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....
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.
yeah on a fresh wezterm this isn't happening.
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)
we already have a bug filed on wezterm, https://github.com/wez/wezterm/issues/1156
hrmmm but it doesn't reliably look like shit, argh
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?
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
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
this looks like a pretty straight wezterm bug. i've extracted the sixel i'm emitting, and will file a bug upstream.
https://github.com/wez/wezterm/issues/1270 has been created for this issue.
i think the alacritty problems you mention might be due to #2142
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.
Problems with wezterm:
I noticed in several examples starting looking bad in wezterm.
E.g. the![image](https://user-images.githubusercontent.com/5832068/133604044-7c9f3f49-8b83-4658-8444-5965504776a9.png)
pixel-cell
example in this repo shows the original pixel cell duplicated in the row under it:The![image](https://user-images.githubusercontent.com/5832068/133603796-61059c58-462a-45a8-908c-0d53ff9a1f53.png)
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![image](https://user-images.githubusercontent.com/5832068/133603599-cdb9e2bf-6d81-4c47-9dd3-5914ea2539a2.png)
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?:![image](https://user-images.githubusercontent.com/5832068/133604503-957c7920-af72-4a44-8b92-ffc929700f4b.png)
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:![image](https://user-images.githubusercontent.com/5832068/133604640-dedef19a-099a-4e4d-8cc9-367d1bccf4bf.png)