Kitty graphics protocol load and display doesn't replace existing image with provided ID

[pluiedev]

Discussed in #6680

^{Originally posted by chase March 12, 2025}
Currently, from what I can tell, Ghostty will ignore the ID and allocate a new image ID instead of setting the image with that ID.

This part of the protocol is easy to miss because it's in a side note for the querying support section:

Sometimes, using an id is not appropriate, for example, if you do not want to replace a previously sent image with the same id, or if you are sending a dummy image and do not want it stored by the terminal emulator. In that case, you can use the query action, set a=q. Then the terminal emulator will try to load the image and respond with either OK or an error, as above, but it will not replace an existing image with the same id, nor will it store the image.

Or simply put, the logical opposite is: for transmission and display, it will replace an existing image with the same ID and store it.

This should make simple animation possible.

[chase]

After looking at the code for a bit, it seems like this behavior is already intended to be implemented and should be working.

ghostty/src/terminal/kitty/graphics_exec.zig

Lines 334 to 342 in 644acda

	// If the image has no ID, we assign one
	if (loading.image.id == 0) {
	loading.image.id = storage.next_image_id;
	storage.next_image_id +%= 1;
	// If the image also has no number then its auto-ID is "implicit".
	// See the doc comment on the Image.implicit_id field for more detail.
	if (loading.image.number == 0) loading.image.implicit_id = true;
	}

I'll try to figure out a minimal case to reproduce the issue. I'm guessing it has to do with not tracking evictions, but nothing certain yet.

[chase]

Simply replacing 2 image IDs seems fine and works as expected.

It does seem related to images being evicted, so maybe the case is that image.id == 0 after eviction?