Conversation
6e55a5f to
49d4d96
Compare
|
Merge of f62baa2 to Screenshots from all terminal emulators:alacritty
Image diff vs master: blackbox
Image diff vs master: contour
Image diff vs master: foot
Image diff vs master: ghostty
Image diff vs master: kitty
Image diff vs master: konsole
Image diff vs master: mlterm
Image diff vs master: rio
Image diff vs master: wezterm
Image diff vs master: xfce4-terminal
Image diff vs master: xterm
Image diff vs master: xterm-vt340
Image diff vs master: |
b9f1539 to
9232ae8
Compare
|
Nice, this is the transmit lanthorn has wanted for local play. One thing worth adding before it sees much use: The protocol has the answer built in: an Happy to send the PR if you're open to it. |
|
Good point, we should always probe if possible. |
Should be much faster than base64(PNG) sequence.
Probe whether a terminal can actually read a POSIX shared memory object before ever relying on one for a real transmission — a blind opt-in silently draws nothing on a remote session, since the terminal can never open an object that lives on another machine's filesystem. Address of review on PR #200: - One option. `QueryStdioOptions::kitty_shared_memory_object` now means both things at once: probe for shared memory during the stdio query, and use it for real transmissions if the terminal answered. The separate probe flag and the `ShmProbe`/`resolve_kitty_shm` machinery are gone; `Picker` folds the answer in with `if caps.contains(&Capability::KittySharedMemory) { kitty_shm } else { None }` on every path, including the ones where nothing answered at all. - The probe goes out through the same write path a real transmission uses (`kitty::shm_name` + `kitty::shm_write`), not a separate deterministic-name scheme. `Parser::query` now returns the probe object's name alongside the query string, and `Picker` unlinks it once the query's replies are read — kitty/Ghostty unlink it themselves on success, so a gone object at that point is the success case, not an error. - A shared memory transmission still names a fresh object every time, never the kitty image id, but the per-transmit suffix is now drawn from `rand::random` — the same way `Picker` already draws kitty image ids — rather than a second `AtomicU32`. A repeated base64 transmit under one id is harmless because the wire is ordered; a repeated shm name is not, because the terminal reads the object asynchronously and a second transmit recreating it can race a reader still working through the first. - `transmit_or_shm` now decides shm vs. inline over raw `(bytes, w, h)` rather than a `DynamicImage`, with `to_rgba8()` hoisted to `KittyProtoState::new`, the one caller that actually holds one. `transmit_virtual` is renamed `transmit_base64` to match. This is what lets the probe call the exact same write primitives a real transmit does, down to a shared four-byte constant pixel. - The write-vs-map split moves from `target_os = "macos"`-shaped reasoning to "Linux writes, every other Unix maps": `mmap` is the one operation POSIX actually promises on a shared memory object, `write` is a per-kernel courtesy (macOS refuses it with ENXIO, FreeBSD happens to allow it but is untested here), and the crate draws no line between non-Linux Unixes anywhere else. - Documented, without a code change: a transmit the caller never consumes with a render leaves its shm object behind for the caller to clean up by hand, the same way an untransmitted base64 image is left marked transmitted but never shown. Quest: none
09bf9d6 to
022f202
Compare
2 participants
Should be much faster than base64(PNG) sequence.