A shared frame segment holds four screens of pixels and a GPU frame is about one. A frame may now
start further into it: the daemon writes where (its window, in rows) into a 64-byte trailer at the
segment's end before every publish (render/browserserver/Src/JihadFrameWindow.h), and the adapter's
BrowserOffscreen::rasterBuffer() reads the frame from there. The adapter marks the segments it makes;
the daemon moves windows only in those (an adapter from before keeps every frame at the start). The
YAP messages and the BrowserOffscreenInfo header are unchanged.
A slot's frame built on its own older frame after a scroll is now that frame with its window moved by
the scroll (engine 0053: the shift is then only the kept rects), where 3.7 MB of rows were moved on
the compositor thread every pan frame; near an end of the segment the frame goes back to the middle
with one copy. Both lanes keep every slot's stale rows (the express lane used to drop the other slots'
records on each publish; a frame composed and dropped adds its change too, and a forgotten composite
drops them all), so the express lane can build on its slot's own frame; it takes that or the copy from
the newest slot by measured frame time (the other tried every 16th frame). A windowed GPU frame is
never the software path's repaint base.
Rounds 325-332: verify mode on main-lane pans 0 structurally wrong frames after the pan began;
dumped express frames coherent; the long test page pans at 30.5-36.4 fps (median frame gap 26 ms, was
29); Wikipedia unchanged at 19-21 (its sticky panels' passes); the default checks of all three
interfaces pass with the window-aware adapters, frames right by eye. JIHAD_GPU_NO_WINDOWS=1 and
JIHAD_GPU_EXPRESS_NO_OWN=1 for A/B.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
NotAlexNoyleandClaude Opus 5.5
4b8a595b5a