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

Graphics protocol appears to make it hard to avoid deleting images sometimes #3163

Closed
lexbailey opened this issue Dec 12, 2020 · 1 comment
Closed

Comments

@lexbailey
Copy link

I have been playing with the graphics protocol in kitty, and have discovered an unexpected behaviour that's slightly annoying.

If I have a program that transmits an image with an ID and then displays it like so...

<ESC>_Gs=20,v=20,i=1;<payload><ESC>/
<ESC>_Ga=p,i=1;<ESC>/

...and then I run the program twice, so that the second instance transmits the same image again, to the same ID, and displays it just like before, then I don't end up with two copies of the image.

The ID is hard coded to 1 in my test program, If I change the ID between runs of the program then I can still see the previous images on the screen.

I'm guessing this is the intended behaviour, so that all images on the screen drawn from the same ID are surely the same image. That would make sense but if that's not the case then this might be a bug.

Assuming that this is intentional, then perhaps it would be nice to extend the graphics protocol so that this problem can be avoided somehow.

Or I'm totally misunderstanding the graphics protocol and there's already a way to do this?

Really liking kitty so far though :D
Thanks.

@kovidgoyal
Copy link
Owner

See discussion in #3111

@kovidgoyal kovidgoyal reopened this Dec 16, 2020
pull bot pushed a commit to alin23/kitty that referenced this issue Dec 16, 2020
…n image ids

Useful when multiple non co-operating programs want to share the screen.
Fixes kovidgoyal#3163
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants