Using the animation feature of kitty graphics protocol

[AnonymouX47]

Hello!

Found out about your project recently and I seem to like what you're doing so far.

I just dropped by to say some others and I recently had a discussion at hpjansson/chafa#104 on using the animation feature of Kitty graphics protocol and thought it could be really useful and applicable to what you're doing here.

Last I checked, every frame was being transmitted as a separate image (and seems to still be the case)... which isn't really the best (except the images are being deleted) for a streaming (indefinite end) source. I think using the animation feature of the protocol, if supported (currently, only kitty does), would be better.

Another (actually simpler but maybe not as appropriate) approach would be to use two alternating IDs and then delete the image with one ID immediately after displaying the image with the other ID. This would work on any terminal emulator that at least implements image deletion by ID.

By the way, the animation feature also provides a lot of functionality that can improve performance of updates between frames such as "differential" updates.

Thanks and well done! 👍🏾

I feel this would've been more appropriate in a "discussion" but that doesn't seem to be enabled.

[chase]

@AnonymouX47 Thanks for chiming in!

You're totally right. I considered using the animation portion of the protocol, but honestly I just wanted to get it working first to see if it was even feasible. I saw that the glkitty/kitty_gears demo just transmitted every frame the current way and let Kitty collect the garbage after it hits the buffer limit, so I went with that.

I'll take a look at the discussion later, any insight into other implementations is definitely helpful for me.

I think probably for the immediate term, adding the simpler double buffering approach probably makes sense because I don't have a lot of spare time to spend on this project for the next two months or so.

Using the animation protocol and differential updates would definitely make sense, since Chromium Embedded Framework also exposes a list of the rects of areas that need to be repainted:

awrit/awrit/tui.cc

Line 33 in 45bd066

void Paint(const std::vector<CefRect>& dirtyRects, const void* buffer,

It might be a few weeks until I get around to this, so if you or anyone else wants to contribute this as a feature, I would really appreciate it.

[AnonymouX47]

I think probably for the immediate term, adding the simpler double buffering approach probably makes sense because I don't have a lot of spare time to spend on this project for the next two months or so.

I see... that's OK. No rush 😃.

Chromium Embedded Framework also exposes a list of the rects of areas that need to be repainted

Oh, great! That makes the job even easier.

It might be a few weeks until I get around to this, so if you or anyone else wants to contribute this as a feature, I would really appreciate it.

I would love to but unfortunately, I don't write C++ (and don't intend to anytime soon). I'm also really occupied with a couple of projects at the moment. 🥲

That said, See dankamongmen/notcurses#1898 which was mentioned during the discussion I referenced initially. NotCurses happens to be the only popular project I know of that uses this aspect of the protocol well and quite extensively. The author's thoughts, comments and implementation can all be found from there.

[chase]

@AnonymouX47 thanks for bringing this to my attention so long ago. It's definitely the right way to handle things!

The latest version uses the animation protocol to compose frames from separate windows onto a base frame image, keeps up with my 240Hz monitor on a 1920x1080 sized window, so far so good!

Need to fix the dirty paint region stuff and resizing though 😂

[AnonymouX47]

It's a pleasure. 😃

Wow! Glad to hear that. Well done.

Just one thing... As I noted in the original post, only Kitty supports this aspect the protocol (last I checked, the situation was still there same). So, it'll be good to use it conditionally i.e only on TEs that support it and continue to use the existing method on other TEs.

[AnonymouX47]

ghostty-org/ghostty#5255 is the tracking issue for this protocol feature for Ghostty.