slosh.git/tests/test_graphics.py, branch master

graphics: no cell arithmetic at the far edge of an uncut image

2026-09-07T14:21:56Z

A smooth bounce shimmered: anything placed with sub-cell X=/Y= offsets had its source rectangle shaved by a different sliver every frame, so the picture's edges breathed as it moved. dvd.py made it obvious -- the logo's crop wobbled between w=124 and w=130 around a true 142. The pixels-per-cell a placement reports are its own pixels over its own grid, floored, and the grid includes the cell the sub-cell offset spills into, so the figure runs a shade small -- 142px over 19 cells says 7 when the terminal's cell is 8. That was harmless while the number was only used proportionally at real cut edges. The pieces rewrite ran it over every placement: axis_crop() clamped even an uncut image's source to cols * cell_px - offset, and as the offset moved the clamp moved with it. The far edge of a piece that reaches the placement's last cell is where the source runs out; only an interior cut needs the cell arithmetic. With that, an uncut placement's source rect passes through untouched, which is what the old emitter always sent. Two companions in the same sum. A scaled piece so narrow its share of the source rounds to nothing now keeps the pixel it is inside, because w=0 on the wire means "the whole image", which is worse than wrong. And a cut piece whose source is genuinely empty is cells the image never reaches, so it is not placed at all -- the uncut placement stays exempt, since the pane-edge crop has always used 0 for "the rest of it". The headless check places with X=5: the whole source rect must survive the offset, where the clamped code sent w=0.

app: cut the modals, toasts and splash out of the images under them

2026-09-06T18:34:26Z

Overlays are painted over the panes and the compositor needs no more than that: painted later is on top. A placement is not painted, though -- the client's terminal draws the image over the cells, in whatever order they arrived -- so an overlay that is only drawn is an overlay an image sits on top of. The cheatsheet came up under a picture and was unreadable through it, in the terminal and in the mirror both. So a frame now records where its overlays landed, and the graphics pass takes them out of a placement exactly as it takes out a float: the modal's box (the cheatsheet and the picker wear the same frame), each toast, and the splash. The list is rebuilt every compose, so a rect that is not registered again is one that is no longer on screen. Only the opaque things are registered. The scrim behind a modal tints what is behind it rather than hiding it, and an image cannot be tinted by us at all -- so a picture beside the cheatsheet stays bright while the text around it is pushed back, which is wrong-looking but a great deal better than the image disappearing while a modal is up. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01CRz3zwZJvBvzsR9k4cj6dd

graphics: place what a float leaves of an image, not nothing

2026-09-06T17:59:13Z

Occlusion for placements is clipping: the cell compositor gets it free from paint order, but images are sent after the diff and drawn over it, so what a float covers has to be taken out of the placement itself. A clean edge came out as a smaller rectangle; anything else -- a float across the middle, a float on a corner, a float wholly inside -- was refused, on the grounds that the remainder is an L and a placement is a rectangle. The image vanished, all of it, the moment a floating pane crossed it, on the terminal and in the mirror alike, and came back when the float moved off. The remainder is not one rectangle, but it is always a few: the strips above and below what is covered, and what is left beside it between them. So rect_subtract() cuts the visible remainder into rectangles and each is placed in its own right, with the source rectangle the same arithmetic the pane edge already used -- generalised to a cut on any side, and to a first piece that keeps the sub-cell offset while the others start on a cell boundary. Eight pieces is the ceiling (two floats' worth); past it the old refusal stands. The pieces of one placement need an id each, and the program's own placement id is one number that cannot be several, so the model now hands out the placement ids the client is told and keeps the program's as the identity it was. `graphics` reports the piece alongside it. Checked against a float parked over an image: the picture is cut around the float, the strips tile exactly the image minus what the float covers, and their source rectangles land where their cells do (a float inside a 40x10-cell natural-size image gives 320x32 above, 320x32 below, 56x96 left and 72x96 right). Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01CRz3zwZJvBvzsR9k4cj6dd

graphics: state z=0 on a placement, so a mirror paints it over the text

2026-09-06T17:41:56Z

kitty's default z is 0, which draws an image above the text, and that is the value slosh has always relied on -- it places after the cell diff precisely so the picture ends up on top. Saying nothing works because the terminal supplies the default. Anything mirroring the stream has no such default to fall back on. It cannot tell "the emitter wants this over the text" from "the emitter said nothing", and shellglass's viewer paints an unstated image under the cells. That is fine until a cell over the picture carries an explicit background -- and dim_unfocused gives one to every cell of a pane at once, so the moment focus moved elsewhere the whole image disappeared from the mirrored copy while the terminal, which took the default, still showed it. So the placement states z=0. Nothing changes on a terminal, since that is the value it was already assuming; the mirror now paints the picture over the cells and the dim pass runs underneath it, where it belongs. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01CRz3zwZJvBvzsR9k4cj6dd

graphics: a frame the client never got must be said again

2026-08-29T19:31:41Z

A pane image is re-emitted to the client as decoded RGBA, which for one screenshot is ~4MB of base64 in a single indivisible message -- and conn_send silently dropped anything that would overflow the 4MB outbox, while push_graphics ignored the refusal and the model advanced anyway. Everything stateful in that dropped frame was lost for good: the image was marked sent (so its placements drew nothing, forever), and the deletions rode out with it (so a placement the client had was never revoked). Reported as screenshots in a recovered pi transcript parked at a fixed spot on the screen, immune to scrolling and pane swaps -- those were placements whose deletion left with a dropped frame. The 1000x800 one could never be delivered at all: its transmission alone was bigger than the cap. So the frame is now transactional. Deletions queue and are repeated every flush until gfx_commit() confirms the client heard them; transmissions recorded in a frame are unwound by an undelivered commit so they are sent again. A flush nobody commits counts as undelivered at the next gfx_begin(), which is what the `graphics` control command is: bytes rendered for a CLI, not the client. The server reports the verdict and keeps the paint pending until it lands. The outbox cap now bounds the backlog rather than backlog-plus-message, so one big transmission on a drained queue always fits -- and that surfaced a second way to lose: a queued image legitimately holds the backlog over the cap until the client swallows it, and push_frame read that as a dead client and closed the connection. The session auto-detached every time a screenshot crossed the wire. A full outbox is a client that is *behind*, not gone: push_frame now marks the screen for a full repaint (the dropped diff means the client's cells are unknown) and retries as POLLOUT drains the queue; a client that truly left still shows up as a write error there. The headless suite pins the owed-until-committed contract; the new tests/live_graphics.py drives the real socket with a bigger-than-the-cap image and a reader that stalls, and would have caught both bugs: the flood must not detach, the transmission must arrive whole, and a placement scrolled away must be deleted -- then come back on scroll without a second copy of the pixels.

slosh: M10c, the memory -- floats survive being written down

2026-08-20T21:53:43Z

A dumped session quietly re-tiled its floats, which was the one data-loss gap left in D22. dump-layout now records `floating=true x= y= w= h=` -- the *wanted* rect, because intent is what survives a session and the next screen's layout clamps it like any frame -- layout files declare the same (linted: floating is a bool, x/y/w/h mean nothing without it), and a file whose every pane floats self-heals through ensure_tiled: the top float lands, the same rule closing the last tiled pane follows, no lint required. save-workspace inherits all of it from the shared dumper. `float` over the API takes x/y/w/h and then *places* rather than toggles -- a placement is a statement about where, not about whether -- floating the pane first when it is tiled, re-placing when it already floats, with omitted fields meaning "keep". The intent is stored exactly as asked: the write-back rule is for hands, whose drags need the clamp to agree with the eye; a script means what it typed. And kitty graphics respect the stack. The cell compositor gets occlusion free from paint order, but placements are sent after the diff and would paint an image straight over a float covering it. Each pane's placements are now clipped by the float rects above it -- every float for a tiled pane, the higher-raised for a float -- cropping what one clean edge can express (the pane-edge source-rectangle arithmetic aimed at another clipper, including from the top and left, where the source origin moves and the sub-cell offset is consumed) and suppressing what it cannot: a strip across the middle or a corner overlap leaves a shape one placement cannot say, and the image returns whole when the float moves. No z= needed -- clipping is the z-order, since nothing is ever allowed to overlap. D22's "still owed" paragraph is paid and rewritten; M10 is fully checked.

sl0ppty: ruff format the Python

2026-08-17T12:36:59Z

The bumpy one, again. Every `.py` outside `vendor/` plus the three `contrib/` scripts that are Python with no extension: 60 files, 6,714 lines rewritten, no behaviour changed. Nothing here is worth reading -- the next commit adds it to `.git-blame-ignore-revs` so `git blame` walks past it. It is a bigger reformat than the C was, 60% of the lines against 17%, and for a reason worth writing down rather than tuning away: ruff and black break a call that does not fit onto one argument per line, where this code aligned the continuation under the opening paren. The test suite is thousands of `check("some prose", cond, detail)` calls, so nearly every one of them changed shape and the suite grew 3,308 lines. Line length was the one lever that moved it -- 120 columns would have been a 40% reformat and no growth at all -- and it was left at 88, because picking an unusual width to dodge a one-time diff is paying forever to avoid paying once. Import sorting came with it. Two files had `import os, pty, uuid, select, struct, sys, termios, time, fcntl, signal` on one line and now have ten. Verified after, not before, because a formatter that alters behaviour would be worse than none: - `make retest`, 1801 checks green -- and this reformats the suite that does the checking, including `harness.py`, which every one of those files imports. - `make test-live`, the tty tests the fast suite skips. They matter here more than usual: `live_input.py` and `live_m0.py` are two of the files whose comma-imports were split, and nothing in the fast suite would have noticed if that broke them. - All 60 files still compile, `make fmt` twice in a row changes nothing the second time, and `ruff check --select I` has nothing left to say.

sl0ppty: answer the terminal when it is asked how big it is

2026-08-15T17:38:38Z

XTWINOPS (CSI 14/16/18 t) went unanswered. A program that draws images needs the cell size to keep an aspect ratio; the pty's pixel fields are the first way to get it (D17) and this query is the second, which is what a program reaches for when those come back zeroed -- as they do on the far side of an ssh hop. Unanswered, the query times out and the program falls back to a guess: ida-tui guesses 10x20, and against a real 9x22 cell that is every image stretched by a fifth, which looks like a bug in the program rather than in us. Found alongside the png bug and from the same program, which asks `CSI 16 t` in the same round trip as its graphics query -- so once the png decoded, the picture would have appeared at the wrong shape. lib-vt encodes and writes the reply once the callback says what the numbers are; they come from the pane's own geometry, so a program is told about the pane it is in rather than the window. Mode 2048 (the in-band report on resize) already worked, because that one is answered from the size passed to ghostty_terminal_resize. Also notes in graphics.c what re-emission actually costs: we send decoded pixels because that is the only form lib-vt keeps, so an 819KB png reaches the client as 3.3MB of base64, once per image and again after a reattach clears `sent`. Fine for a splash, and written down so the next person to wonder does not have to measure it again.

sl0ppty: decode the PNGs programs actually send

2026-08-15T17:14:59Z

Kitty graphics were green in the suite and a real program still drew nothing. libghostty-vt ships no image codec: built as a library it sets its `sys.decode_png` hook to null, and a null hook rejects every `f=100` transmission outright -- no image stored, so no placement exists, so the re-emission layer this project is mostly *about* is never reached. The program gets no error and no picture. Raw RGB worked throughout, which is why it looked done: every test here sent raw pixels, because that is what is easy to write in a test. It is the same lesson the last kitty graphics bug taught -- write the test the way a program actually behaves -- and a program with a picture on disk has a PNG. Found because ida-tui's startup logo never appeared, and its detection probe answers `OK` first, so it fails silently rather than falling back to its block art. PNG is the whole of the gap and cannot grow: the protocol has exactly three formats (`f=24`, `f=32`, `f=100`), the first two are raw pixels lib-vt already handles, and `decode_png` is the only codec hook it has. Decoding only, never encoding. The decoder is the stb_image lib-vt already vendors and we already commit -- upstream compiles that same header with the same `STBI_ONLY_PNG` for this same purpose, it is just not in the `-Demit-lib-vt` build. So nothing new is pulled in; a file we already ship is finally compiled. src/png.c is the hook, a header pre-check and a copy: dimensions are read before decoding because the buffer we return is allocated through lib-vt's limited allocator but stb's own working allocation is plain malloc and answers to nothing. Tests cover a PNG placed at the size it asked for (RGB and RGBA sources, both normalised to RGBA), the client being handed `f=32` rather than the png it was given, and a malformed png placing nothing without taking the pane with it. They fail on the previous binary.

sl0ppty: the graphics stream gives the cursor back

2026-08-14T21:32:44Z

Reported as "the cursor is not rendered in zsh" in a newly spawned pane. It was not about zsh, or about that pane: it was about the pane next to it, which was animating an image. Placing an image means parking the cursor on its target cell first, and the graphics bytes go out *after* the cell diff -- deliberately, so a repainted cell cannot land on top of a placement. That is also after the frame has put the real cursor where the focused pane wants it. So with any image on screen, the last instruction the terminal received every frame was "go to wherever that image is", and the cursor sat there: in another pane, moving about with the picture. With a bouncing DVD logo next door it is quite a sight. gfx_begin() now opens the stream with DECSC and gfx_flush() closes it with DECRC, so the whole thing is cursor-neutral no matter what it contains. The save has to be written at the start of the frame rather than at flush time, because transmissions are emitted as images are recorded and are already in the buffer by then. A frame with nothing to say drops both and still emits not one byte, which the test asserts, because a save/restore pair on every idle frame is exactly the sort of cost that creeps in unnoticed. Two tests: that the stream is bracketed (and that it really does move the cursor, or the assertion proves nothing), and that an idle frame is empty. One C trap worth the comment it now has: "\x1b7" is a *single* hex escape, 0x1b7, not ESC followed by 7. The compiler catches that one because it is out of range -- and would not catch "\x1b1", which compiles quietly into one wrong byte. Escape then digit is always two strings.