As of Zig 0.14.0, `@splat` can be used for array types, which eliminates
a lot of redundant syntax and makes things generally cleaner.
I've explicitly avoided applying this change in the renderer files for
now since it would just create rebasing conflicts in my renderer rework
branch which I'll be PR-ing pretty soon.
This commit changes a LOT of areas of the code to use decl literals
instead of redundantly referring to the type.
These changes were mostly driven by some regex searches and then manual
adjustment on a case-by-case basis.
I almost certainly missed quite a few places where decl literals could
be used, but this is a good first step in converting things, and other
instances can be addressed when they're discovered.
I tested GLFW+Metal and building the framework on macOS and tested a GTK
build on Linux, so I'm 99% sure I didn't introduce any syntax errors or
other problems with this. (fingers crossed)
This problem was introduced by f091a69 (PR #6675).
I've gone ahead and overhauled the placement positioning logic as well;
it was doing a lot of expensive calls before, I've significantly reduced
that.
Clipping partially off-screen images is now handled entirely by the
renderer, rather than while preparing the placement, and as such the
grid position passed to the image shader is now signed.
Fixes#7337
AppKit encodes functional keys as PUA codepoints. We don't want to send
that down as valid text encoding for a key event because KKP uses that
in particular to change the encoding with associated text.
I think there may be a more specific solution to this by only doing this
within the KKP encoding part of KeyEncoder but that was filled with edge
cases and I didn't want to risk breaking anything else.
This sort of command is treated as valid by Kitty so we should too. In
fact, it occurs with the example `send-png` script provided in the docs
for the protocol.
Load and display (`T`) was responding even with implicit IDs, because
the display was achieved with an early return in the transmit function
that bypassed the logic to silence implicit ID responses- by making it
not an early return we fix this.
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.
This commit increases the value buffer to 11 characters - this is
technically what it should be to allow for large negative integers
(i.e., 2.4 billion plus the sign character).
Additionally corrected the types for 'H' (horizontal offset) and 'V'
(vertical offset) - these are supposed to be i32 versus u32.
Added some extra tests to test all of this stuff as well.
I've also added a few more tests to help track these cases.
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
If the transmission medium is a local-only medium, ignore the "m"
key. The Kitty graphics protocol specification does not explicitly
call out this behavior (although the "m" key is only mentioned in
connection with remote clients) but that's how it's implemented in
Kitty and at least one client (mpv) relies on this behavior when
using the shared memory transmission medium.
https://sw.kovidgoyal.net/kitty/graphics-protocol/#the-transmission-mediumccc3bee9af/kitty/graphics.c (L547-L592)
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.
