-
-
Notifications
You must be signed in to change notification settings - Fork 114
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
Comments
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 |
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. |
huh interesting, also i had no idea vte added sixel recently in their latest releases. |
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. |
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.
The text was updated successfully, but these errors were encountered: