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

Feature request: Kitty terminal graphics protocol #315

Open
MayeulC opened this issue Aug 30, 2021 · 4 comments
Open

Feature request: Kitty terminal graphics protocol #315

MayeulC opened this issue Aug 30, 2021 · 4 comments

Comments

@MayeulC
Copy link

MayeulC commented Aug 30, 2021

As a faster, more efficient and generally better alternative to sixels, kitty designed and implemented a custom protocol for graphics. It is supported by a few clients, such as ranger for displaying image previews.

It would be nice if darktile were to implement this as well.

@eylles
Copy link

eylles commented Sep 1, 2021

Is it really faster tho? old clunker xterm can somehow draw sixels fast enough to justify stuff like termplay and the sixel driver for retroarch https://github.com/saitoha/libsixel

@kovidgoyal
Copy link

Of course it's faster. See hackerb9/lsix#49 or https://nick-black.com/dankwiki/index.php?title=Notcurses#Pixel_blitters and these comparisons ignore the fact that image quality is much higher with the kitty protocol and they dont even really use the kitty protocol to its full potential, by ignoring the local client side channels.

@eylles
Copy link

eylles commented Sep 1, 2021

huh interesting, also i had no idea vte added sixel recently in their latest releases.

@hackerb9
Copy link

hackerb9 commented Sep 2, 2021

I'm all for Kitty as long as darktile continues to support sixel as well. Kitty doesn't work with ImageMagick, so my lsix program depends on sixel.

Kitty is faster, but I don't think that's the major benefit. Sixels are fast enough for what people use them for. Kitty opens up whole new potential uses.

Sixels were designed for embedding static graphics within text interfaces. Kitty is a completely different graphics paradigm that adds a lot of functionality.

For example, an application could send several animations over to the terminal and then not have to worry about updating them since the terminal will handle it. The terminal remembers each image/animation that has been sent and the program can refer to them by tags to manipulate them instead of having to send an entire bitmap over again.

Another example, if you wanted to implement a Commodore 64 style video game using sixels, you could, but the application (or an underlying library) would have to calculate what regions needed to be erased as each "sprite" moved. With Kitty, the application could just tell the terminal "move this image here".

Kitty does have better image quality, but again, I think that's not its biggest selling point because the sixel protocol has been extended to higher colour depths and most people don't notice. Perhaps the thing I most appreciate visually is that Kitty has 8-bit transparency whereas Sixel only has 1-bit.

There are a few features of sixel that I don't think Kitty has yet, but that's probably because there hasn't been a demand. For example, Kitty doesn't seem to write images in the same plane as text, so if you draw over text with graphics and then try to draw text over the graphics, it won't work. I could be wrong, but I believe you have to pick a plane above or below the text. However, unlike sixel, Kitty is under @kovidgoyal's active development, so the protocol can still be updated to address any deficiencies.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants