Based on my (limited) understanding of Kitty's image protocol[0] (a.k.a the "Terminal graphics protocol") video support could be potentially implemented via multiple approaches, including at least:
(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].
(2) Draw image replacing an existing image with the same id.
(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").
An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:
* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.
* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.
* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].
---- footnotes ----
(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)
[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].
[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D
[4a] Motivated by the thought that at the current point in time perhaps the "essence" of a "terminal" is its linear "chronological" presentation of input/interaction/output history rather than its use of "text". (See also: "lab notebooks" & some tiling window manager features.)
(1) Draw image repeatedly using the "don't move cursor" cursor movement policy[1a][1b].
(2) Draw image replacing an existing image with the same id.
(3) Use animation configured to use "loading mode"[2] ("in this mode when reaching the last frame, instead of looping, the terminal will wait for the arrival of more frames").
An actual terminal graphics/image protocol enables some IMO[3] pretty cool possibilities:
* A while back I implemented a proof-of-concept that displayed a simple interactive egui (a Rust immediate mode GUI project) GUI within WezTerm via the protocol.
* Later I discovered someone had gone as far as making a port[5] of the OpenGL gears demo to kitty terminal graphics protocol.
* And there's even a "full graphical web browser for Kitty terminal with mouse and keyboard support"[6][7].
---- footnotes ----
(Content advisory for links: Kitty terminal graphics protocol spec includes a sample image whose subject has requested that the image no longer be used for such purposes.)
[0] https://sw.kovidgoyal.net/kitty/graphics-protocol/#terminal-...
[1a] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...
[1b] This approach appears to be the method used by the mpv implementation: https://github.com/mpv-player/mpv/commit/874e28f4a41a916bb56...
[2] https://sw.kovidgoyal.net/kitty/graphics-protocol/#controlli...
[3] I'm aware that not everyone will think static or dynamic image display is something a terminal "should do" but to me it seems better to have actual image support in terminals rather than use (already currently used) existing "hacks" that provide a poor facsimile of support[4].
[4] Then again, I'm also of the opinion[4a] that perhaps terminals should support actual graphical UIs rather than the poor facsimile of them delivered by TUIs. *cough* :D
[4a] Motivated by the thought that at the current point in time perhaps the "essence" of a "terminal" is its linear "chronological" presentation of input/interaction/output history rather than its use of "text". (See also: "lab notebooks" & some tiling window manager features.)
[5] https://github.com/michaeljclark/glkitty
[6] https://github.com/chase/awrit
[7] Which I imagine DEC is turning in its grave about. :)