Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kitty protocol: Sending a sequence of PNG images shows only the last #3918

Closed
hzeller opened this issue Jul 1, 2023 · 6 comments
Closed
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.

Comments

@hzeller
Copy link

hzeller commented Jul 1, 2023

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

wezterm 20230629-080200-f376468f

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

Sending a sequence of PNG encoded in kitty image format with direct placement <ESC>_Ga=T,f=100 seems to write them out but then immediately blank once the next image is received. Only the last image stays.

To Reproduce

zcat the following file on the terminal. It contains three images, but only the last one is shown (the previous ones are briefly flickering(

sample-kitty-sequence.terminal.gz

(attempt the same in kitty or Konsole and you get all images)

Wezterm Kitty
wezterm-output kitty-output

Configuration

no config

Expected Behavior

All images are shown

Logs

wezterm version: 20230629-080200-f376468f x86_64-unknown-linux-gnu
Window Environment: X11 KWin
WebGPU: name=NVIDIA GeForce RTX 2080, device_type=DiscreteGpu, backend=Vulkan, driver=NVIDIA, driver_info=535.54.03, vendor=4318, device=7810

Anything else?

I am maintaining timg and because of strong flickering of animations with the iterm2 protocol ( #3882 ) I now attempted to just use the Kitty protocol by default on wezterm; kitty works well with animations.
But then I found that an image sequence is not displayed...

@hzeller hzeller added the bug Something isn't working label Jul 1, 2023
@kovidgoyal
Copy link

See the first item here: #986 (comment) to workaround you will need to send the images with ids or numbers (dont recall if weztem supports image numbers or not, if not then ids).

hzeller added a commit to hzeller/timg that referenced this issue Jul 1, 2023
This is a compromise: makes WezTerm work with the kitty graphics
protocol: if no ID is given, it assumes ID=0 and overwrites
previous images if multiple images are given.

Working around wez/wezterm#3918
@hzeller
Copy link
Author

hzeller commented Jul 2, 2023

Thanks @kovidgoyal , I now worked around it with IDs in timg.
I had to be careful handing them out in e.g. animations as wezterm seems to store all images in GPU textures which filled up quickly. So for animations I'll just use two IDs that are used as flip buffers.

@arodland
Copy link

I also ran into this while testing gnuplot's kitty graphics support in wezterm. In short, if you use gnuplot 6.1 and do set terminal kitty scroll, and plot something (e.g. plot [-10:10] sin(x)) it will show up correctly, but if you run another plot command, the previous one will disappear from the scrollback.

Images without IDs should all be considered unique, rather than being treated just like an image with ID 0. They should only be removed if they're evicted by storage quota.

I can look into fixing it, but I'm not a rust person.

wez added a commit that referenced this issue Jan 28, 2024
refs: #1156
refs: #1156
refs: #1663
refs: #2084
refs: #2422
refs: #2761
refs: #3918
refs: #4233
refs: #4847
@wez
Copy link
Owner

wez commented Jan 28, 2024

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.

@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Jan 28, 2024
@arodland
Copy link

Confirmed:

image

@wez wez closed this as completed Feb 3, 2024
Copy link
Contributor

github-actions bot commented Mar 5, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 5, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.
Projects
None yet
Development

No branches or pull requests

4 participants