From 9695cb098c784792af79c22d46a17f7bc7247d33 Mon Sep 17 00:00:00 2001 From: Gabriel Schneider Date: Tue, 22 Sep 2026 17:43:57 -0300 Subject: 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) --- src/pdf_bridge.h | 46 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 44 insertions(+), 2 deletions(-) (limited to 'src/pdf_bridge.h') 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, -- cgit v1.3