If a transmit and display command does not specify an ID or a number,
then it should not be responded to. We currently automatically assign
IDs in this situation, which isn't ideal since collisions can happen
which shouldn't, but this at least fixes the glaring observable issue
where transmit-and-display commands yield unexpected OK responses.
Fixes#2190
The `q` value with chunk transmissions is a bit complicated. The initial
transmission ("start" command) `q` value is used for all subsequent
chunks UNLESS a subsequent chunk specifies a `q >= 1`. If a chunk
specifies `q >= 1`, then that `q` value is subsequently used for all
future chunks unless another chunk specifies `q >= 1`. And so on.
This commit importantly also introduces the ability to test a full Kitty
command from string request to structured response. This will let us
prevent regressions in the future and ensure that we are correctly
handling the complex underspecified behavior of Kitty Graphics.
- move wuffs code from src/ to pkg/
- eliminate stray debug logs
- make logs a warning instead of an error
- remove initialization of some structs to zero
Improve the performance of Kitty graphics by switching to the WUFFS
library for decoding PNG images and for "swizzling" G, GA, and RGB data
to RGBA formats needed by the renderers.
WUFFS claims 2-3x performance benefits over other implementations, as
well as memory-safe operations.
Although not thorougly benchmarked, performance is on par with Kitty's
graphics decoding.
https://github.com/google/wuffs
The shared memory segment size must be a multiple of page size. This
means that it may be larger than our expected image size. In this case,
we trim the padding at the end.
Adds support for using shared memory to transfer images between
the CLI and Ghostty using the Kitty image protocol. This should be
the fastest way to transfer images if the CLI program and Ghostty are
running on the same system.
Works for single image transfer using `kitten icat`:
```
kitten icat --transfer-mode=memory images/icons/icon_256x256.png
```
However trying to play a movie with `mpv` fails in Ghostty (although it
works in Kitty):
```
mpv --vo=kitty --vo-kitty-use-shm=yes --profile=sw-fast --really-quiet video.mp4
```
`mpv` appears to be sending frames using the normal image transfer
commands but always setting `more_chunks` to `true` which results in an
image never being shown by Ghostty.
Shared memory transfer on Windows remains to be implemented.
On Windows, the tmpDir function is currently using a buffer on the stack
to convert the WTF16-encoded environment variable value "TMP" to utf8
and then returns it as a slice...but that stack buffer is no longer valid
when the function returns. This was causing the "image load...temporary
file" test to fail on Windows.
I've updated the function to take an allocator but it only uses
the allocator on Windows. No allocation is needed on other platforms
because they return environment variables that are already utf8 (ascii)
encoded, and the OS pre-allocates all environment variables in the process.
To keep the conditional that determines when allocation is required, I
added the `freeTmpDir` function.
