Repaint PDF highlights by row, send rasters by shared memory, and animate messages

PDF highlights (hover preview, search, selection) are baked into page rasters,
and any change re-rendered the whole page with MuPDF; the TTY then re-sent it
as base64 (4.7 MB a page), the GUI as a new texture. Worse, a pointer motion
over a PDF invalidated the page even when no preview was shown, so every
motion paid that. Now:

- A raster whose baked highlight set equals the wanted one is left alone.
- A highlighted page keeps its clean rows (before highlights and tint); a
  change repaints only the rows of quads that differ, running MuPDF's
  highlight pass (pardes_pdf_paint_highlights) over those clean rows and
  tinting them: the operations a full render performs, so the pixels are
  identical. MuPDF band renders are NOT bit-identical to a whole page (edge
  rows, resampled images), so they are never used to patch; the comment
  claiming otherwise is corrected.
- ImagePlace.patch hands shells the changed rows; the GUI uploads just those
  rows into the texture it holds.
- The TTY probes kitty shared memory (t=s) with an id vaxis never reaches and
  sends rasters as a /dev/shm name when the terminal reads it; direct base64
  otherwise (ssh).
- Shells that take row patches (GUI, TTY with shm) repaint a selection while
  it is dragged instead of only on release.

Latency elsewhere:
- TTY: an animating frame no longer sleeps 16 ms blind; a tick thread posts
  into the input queue, so input inside the frame is handled at once.
- TTY and GUI: queued pointer motions coalesce to the last.
- GUI: a skipped swapchain image re-arms the frame (3 retries); animations
  still tick while nothing presents.
- Editing: the line index is carried across an edit instead of rebuilt from
  a scan of the whole file per keystroke.

Messages fall into their row (ease-in; the GUI slides the band out from under
the tagline, a terminal fades it), stay until the next input as before, linger
MessageLinger ms (default 800), and dissolve (ease-out). MessageAnimation
toggles it; both are settings, in Config and startup files. The snapshot
harness pins the old behaviour. The detached server now ticks animations.

A restored terminal comes back live: the old screen and scrollback (dumped
as clean VT by ghostty's formatter, replayed at the new size; older dumps
fall back to their rendered text), a dim
"restored history" marker, then a new shell in the directory it was in.

Right-click on a line number in a file pane looks at that line (a sticky
context header's number included).

Measured with an external pty driver (TTY), an in-process fence trace
(GUI, PARDES_TEST_LATENCY), and test/pdf_pointer_bench.zig (pixel identity
against the baseline and a whole-page oracle); balanced A/A/B rounds, paired
per-round statistics.

Messages stack: each event gets its own row and its own fall, linger and
dissolve; a line keeps its row until it leaves and a new one fills the first
free row. Announcements and statuses are replaced in place, not stacked.
MessageFall, MessageDissolve and DumpDir are settings Config reports.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

1 files changed, 44 insertions, 2 deletions

diff --git a/src/pdf_bridge.h b/src/pdf_bridge.h
index cda426aa..e3514437 100644
--- a/src/pdf_bridge.h
+++ b/src/pdf_bridge.h
@@ -222,8 +222,9 @@ int pardes_pdf_measure_render(
  * MuPDF wraps but never owns or frees samples. Every successful pixel is
  * opaque unless transparent_paper is nonzero. That mode preserves content
  * coverage and returns straight-alpha RGBA over an unpainted page.
- * The CTM does not depend on the band, so a band's rows are bit-identical to
- * the same rows of the whole page: it is a clip, not a different rendering.
+ * The CTM does not depend on the band, so a band is a clip of the same
+ * rendering -- but not a bit-exact one: its edge rows and resampled images can
+ * differ from the whole page's (see pardes_pdf_render_into).
  */
 int pardes_pdf_render_into(
     pardes_pdf_document *document,
@@ -244,6 +245,47 @@ int pardes_pdf_render_into(
     int transparent_paper
 );
 
+/*
+ * The highlight pass of `pardes_pdf_render_into` alone, over caller-supplied
+ * rows of that page's opaque raster: render_into(h) == paint(render_into({}), h)
+ * row for row, because a render draws its highlights over the finished page.
+ */
+int pardes_pdf_paint_highlights(
+    pardes_pdf_document *document,
+    int page,
+    int dpi,
+    int minimum_width,
+    int minimum_height,
+    int max_dimension,
+    const pardes_pdf_highlight *highlights,
+    size_t highlight_count,
+    unsigned char *samples,
+    size_t samples_len,
+    int width,
+    int height,
+    int stride,
+    int band_y,
+    int band_height
+);
+
+/*
+ * The raster rows [*row_start, *row_end) that painting `highlights` can touch
+ * under the same request, in the coordinates `pardes_pdf_render_into` bands
+ * use. An empty set (or only transparent ones) yields start == end == 0.
+ */
+int pardes_pdf_highlight_rows(
+    pardes_pdf_document *document,
+    int page,
+    int dpi,
+    int minimum_width,
+    int minimum_height,
+    int max_dimension,
+    const pardes_pdf_highlight *highlights,
+    size_t highlight_count,
+    int *row_start,
+    int *row_end
+);
+
 int pardes_pdf_page_text(
     pardes_pdf_document *document,
     int page,