Closed AnonymouX47 closed 1 year ago
This should be resolved now in main
.
It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.
Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.
If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg
file on macOS, a .zip
file on Windows and an .AppImage
file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.
If you are eager and can build from source then you may be able to try this out more quickly.
Version 20230513-073621-bdb173f1
still panics with the following traceback:
Are you certain you are actually running that build?
Run wezterm --version
to confirm
Oh, sorry... I just ran
RUST_BACKTRACE=full cargo run --release --bin wezterm -- -n start
after I pulled (which actually reported the latest version with --version
).
I ran cargo build --release
again and now I get the following INFO log:
16:29:27.344 INFO wezterm_gui::termwindow::render::paint > Not enough texture space (texture dimensions 4096x4096 exceeed the max dimension 2048 supported by your GPU); will retry render with images disabled
One problem though, is that the same log gets reported every time I scroll or switch away from and back to the window, even though the image was transmitted only once.
By the way, what's the cause of this?... Images this large weren't a problem before.
The behavior could also happen in previous releases if you explicitly set front_end="WebGPU"
. The OpenGL front end already had similar logic to handle this same case when using front_end="OpenGL"
, which was the default in previous releases.
The issue is that the image is too large to fit in a single texture, so when combined with the images from the glyphs you want to display we're out of luck.
The way this is "handled" safely in wezterm is to try again but without trying to use any of the texture space for attached images. The error condition will trigger each time we try to render the display, and be resolved in the same way until you clear the display of any image cells.
Oh, I see.
From the reference for front_end
:
Does
The functionality described in this section requires a nightly build of wezterm.
mean the front_end
config only applies in nightly builds?
If not, does
The default is
"WebGpu"
. In earlier versions it was"OpenGL"
.
apply only to nightly builds?
_To be clear, "WebGPU"
doesn't seem to be the default on the latest non-nightly release but I just want to be sure that won't change anytime soon... cos it'll be quite surprising to normal users when images just suddenly don't appear :)_
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
Kwin
WezTerm version
20230510-062945-6d8e2666
Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?
Yes, and I updated the version box above to show the version of the nightly that I tried
Describe the bug
When drawing high-resolution images using any of the supported protocols (sixel, iterm2, kitty), the terminal emulator crashes immediately.
To Reproduce
Sample image: 927026.png
chafa -f <format> 927026.png
, for format in {iterm2, kitty, sixel}chafa -s x$(($LINES * 2)) -f <format> 927026.png
The image is successfully drawn when the size is smaller e.g with
chafa -s x10 ...
(spans 10 lines). I don't know what exactly the image resolution (or data size) threshold is.NOTE: I did not use
wezterm imgcat
orkitten icat
for the sake and consistency and becausewezterm imgcat
always transmits image data to the terminal as it is in the file, no resizing, compression, etc. Hence, Wezterm always crashes when usingwezterm imgcat
. This brings us back to https://github.com/wez/wezterm/issues/3264.Configuration
no config
Expected Behavior
The image should be drawn, as it was before (tested and works as expected in the latest stable release
20230408-112425-69ae8472
).Logs
Anything else?
I understand this only happens in the nightly release but I though it was worth reporting since I stumbled upon it while re-testing for some other bugs I had discovered a while back.