The owner (2026-11-03, "choose based on performance"): the parts by part ON by default (desktop Wikipedia 11.4
against 10.8 fps by finger, the long page 19.4 against 19.2; JIHAD_GPU_PARTS_PER=0 or <state>/no-parts-per turns
it off), the express lane's second frame on the first in flight OFF (11.4 against 11.4, 18.1 against 19.4;
JIHAD_GPU_EXPRESS_SECOND_PARTS=1 turns it on), and item 4 next over the damaged-rows read. The daemon rebuilt
and pushed to the three variants (ba9bd159), default-check x3 passes; the desktop daemon tests pass.
PICKUP carries item 4's starting design: the tiles' CPU pixels reachable on the compositor side, the band
condition "tiled painted or colour layers only" rather than "scroll only", and the scale at Wikipedia's fit
zoom (0.69 with the tiles at resolution 1) as the owner's decision before the build.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The owner's "cheaper part pictures" (2026-11-03). Engine 0073: each rect of a frame's parts list carries a
signature of its own (its outermost fixed or sticky layer's subtree, every subtree layer's last paint as the
stamp of one up-only counter, the part's scale, quarter-pixel phase, place inside its rect and size);
compose_post3/start3 (overview_ok 4) take the signatures the daemon holds and the pass reads only the rects
not in the list; the poll's 54 ints carry each rect's signature and the rects read. The daemon keeps eight
part pictures by signature and, with JIHAD_GPU_PARTS_PER=1 (or <state>/parts-per), sends the list; without
it E2's rule. The express lane's second frame on the first in flight is back when both are without their
parts (JIHAD_GPU_EXPRESS_SECOND_PARTS=1 or <state>/express-second-parts): its dress puts back what lay
beneath the first's parts and beneath the first's base's parts from the slot records (serials, the rows
read, a slot's previous record kept aside), never on a first that is itself two deep. JIHAD_GPU_VERIFY=1
now verifies the express lane's frames (the reference composed before the job; verifyCompare shared with the
main lane) and JIHAD_GPU_TEST_DRESS_HOLD=<pre|mid>:<ms> holds a first frame's dress so the second's copy
catches it. Both switches off by default: the defaults are the owner's call.
By finger: desktop Wikipedia 10.8 -> 11.4 fps flowing (its contents panel, the part that changes, is 310 of
the 340 KB: the lever is bounded by the changing part's size), the long page 19.2 / 19.4 / 18.1. Verify after
the pan mark: 0 wrong rows in every run on both pages, 142 two-deep frames among them, 55-80 of those with
the first's dress held (docs/rounds/t505-2026-11-03/notes.txt).
The inspector's review (Codex out of credits): REVISE, seven findings, all fixed (impl-review-findings-t505-
cpuparts.md, review 3). The verify then exposed a latent main-lane fault from review 2's F4 (2026-11-02): a
second job whose in-flight base the parts rule refused built on the newest finished frame but told the engine
it was the previous composite, so the frame was recorded 316 rows off and the next own-slot frames copied
wrong rows; fixed (srcInFlight in gpuJobStart; 0 wrong in three runs after).
Also: build/desktop/build-goanna.sh takes a jobs argument like the ARM script (the host short of memory);
tools/device/t502/README.md documents the switches; the kit's R4 criterion, the build site's T-505 row and
PICKUP's top section carry the state; the three variants run this head (default-check x3 passes).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The top section for the update: the state (main 62af6e82, the fork's two branches to push), what
update-engine.sh did, what the desktop tests, the device checks and the certificate checks showed,
the device's packages, the open work in the owner's order, and the session's traps. The handoff
prompt for a fresh agent (.cavekit/handoff-2026-11-03) and push.sh, which pushes both engine branches
before main and reads all three back.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The owner's choice of 2026-11-02 after T-551's check found the tag: the update now, patch 0060 (the
roots, byte-identical upstream) dropped, special attention to the certificate and HTTPS changes.
- update-engine.sh RB_20261027 / --finish: the 72 patches on the tag (0060 fell away as already
applied), jihad/uxp-RB_20261027 at 52ad9ab66e in third_party/uxp, the queue rewritten and
renumbered from 0060, the pins (engine-version.env, the OE recipe, .gitmodules, the UA and the
three start pages: UXP/6b18be9), JIHAD_APP_BUILD_ID 20261103000000; patch-queue.sh --check,
check-engine-pins.sh and check-engine-api.py (baseline rewritten, unchanged) agree.
- docs/ENGINE-SOURCE.md: the base, the dropped 0060, the renumbering, and the range's 12 commits
each with its disposition — the two NSS certificate commits (emSign removed after the eMudhra
compromise; certdata to Sept 2026) were on the device since the roots of 2026-10-25 and are the
base's now; no PSM, TLS protocol, HSTS or certificate-UI change in the range; the memory-safety
fixes (the JS OOB array copy, the jar: flag, feTile, the layout frame table, the mutation
observer's strong ref, SQLite 3.54.1) taken with the base.
- audit-roots.py against the fetched release certdata and the CCADB report: identical set and
trust, none removed, RESULT OK (docs/rounds/certs-2026-11-03).
- Desktop: the full build clean; 14 of 18 tests pass, the four left are the desktop GTK path's
known read-back limit. ARM: libxul, the daemon, the bundle, the three packages; full pushes to
all three variants; default-check x3 faults 0; the daemon's start line 28 of 29 optional
exports as before. The areas the commits touch, on the device (tools/device/engine-checks.sh,
new): about:settings, about:personas and about:addons through jar: under the flag change,
cookies through the new SQLite, an SVG filter page with feTile and its overflow case
(render/goanna/test/jihad-svg-filter.html, new), a long press's selection; faults 0.
The certificate kit's checks (tools/device/cert-checks.sh): the TLS 1.0 refusal, the clean loads,
expired / wrong.host / self-signed / untrusted-root with the SSL confirm's right flags, OCSP
revocation enforced on grc.com, ssl.com and DigiCert's demos, revoked.badssl.com's CRL-only case
invisible as before: nothing changed with the base.
Records: docs/rounds/engine-rb27-2026-11-03/notes.txt.
- tools/device/cert-checks.sh and t502/enyo-restore-job.sh (new): the certificate kit's device
checks under a hand-started daemon, and the Enyo job put back after any spike round.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The top section for 2026-11-03: the state (main c29f396c, engine 1f54df3762, the push owed), the wrong
verify frame's cause and fix, the inspector's review, the device on engine 0073 in all three variants
(default-check passes), the traps learned, and the open work in order. RB_20261027 (12 commits): the
certificate commits are already on the device through the roots of 2026-10-25, the memory-safety
fixes are not; the owner's word of 2026-11-02: the update now, patch 0060 dropped, special attention
to the certificate/HTTPS changes (the engine-release kit's R1 gains that criterion; T-551 READY).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The one frame of 58 with 13 wrong rows (PICKUP 2026-10-26, item 2) reproduced on the device with the
verify dumps: the base frame's record of what lay beneath its header held the header itself. Its job
was the load's tree change (a 4 px strip), composed by the engine as a partial composite of those
columns but read whole rows: the other columns were the window target's last composite, the verify
reference with the parts. Engine 0073 composes a content-only frame's changed rows whole. Found the
same day by the inspector's review (Codex out of credits until Nov 4th), whose other findings are
fixed too: every part's beneath recorded before any is drawn and put back in reverse (F3), the main
lane's second job only on a base of its own kind (F4). cpuPartsDress and the main poll log the
restore (the base record, d, the rows put back, a pixel of the record), rate-limited.
Records: docs/rounds/t505-2026-11-02/notes.txt, context/impl/impl-review-findings-t505-cpuparts.md
(review 2). Verified: the long page's scripted pan under JIHAD_GPU_VERIFY=1 on the Enyo variant, 85 frames, 78
shifted, 0 wrong rows (2 wrong in each round before the fix); frames looked at. Kit: R4's CPU-parts
criterion met on the long page too, R2 gains the read-width criterion.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The owner stopped the session ("stop here and prepare the directory / cavekit 3.1 files for a
fresh agent"). PICKUP's top section: T-505's state (the parts on the CPU, exact with engine 0072),
the open items in order (the Codex review of 81f56bef/446b22790a the stop cancelled, the long
page's one wrong verify frame, cheaper part pictures, the CPU-composed bands, then the four kits of
Tier 91), the unpushed commits (GitHub main d9816d2f, the fork 078a0942), and the device: all three
variants on this head's engine and daemon, default-check passing in each. The review findings'
status filled in; tools/host/flow-fps.py (the rounds' fps-while-frames-flow counter) kept.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtfxSpM1w2uiVKeLKoV3g3
Two inspector reviews of the parts on the CPU (Codex was out of credits) returned REVISE, and the
owner's question on the stale-picture trade was answered by a third design, now built:
- the engine reads the parts' picture in the frame's own job when the parts' signature (their
layers' content, attributes, structure, sizes) is not the one the daemon holds; the daemon keeps
the last three pictures by signature and dresses each frame with its own, rect by rect: exact,
no separate picture job, no matching, no stale switch;
- a content layer above a part: the frame not shown, the engine's parts for 2 s (the document
after three); parts over 1 MB: the engine's; the card's hold set reported apart (T-544's meaning);
- review fixes: the express lane's second frame no longer copies a frame being dressed (C1); the
kind recorded with the slot (C7); the out-of-page rows white before dressing (C10); misses that
are not misses not counted (C8); parts buffers lent by token, returned at the poll, reclaimed
10 s after a forgotten job; CPU parts on unless JIHAD_GPU_CPU_PARTS=0 or <state>/no-cpu-parts.
Verify (main lane only, scripted Wikipedia pan): 0 wrong rows in 27 shifted frames; without the
parts the same run showed 2 frames with wrong rows. Scripted pan: Wikipedia 12.8 fps (9.4 without),
the long page 23.6 (18.8); by finger Wikipedia 12.3 (9.5), the long page 18.3 (15.7). Frames looked
at. The findings and their status: context/impl/impl-review-findings-t505-cpuparts.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtfxSpM1w2uiVKeLKoV3g3
The owner's CPU/GPU split, "both, parts first". With JIHAD_GPU_CPU_PARTS=1 every GPU frame is
composed without the page's fixed and sticky parts (engine 0070, flag 128) and the daemon draws
them over it from a picture of the parts alone (flags 64|128, remade when the parts' generation
moves); what lay beneath the parts is kept per slot so frames still build on each other. Both
lanes make frames of the same kind (the main lane's are dressed at its poll, under the frame lock).
Faults found and fixed on the way (docs/rounds/t505-2026-10-26/notes.txt):
- the picture never matched a frame (the engine's keep split; engine 0070 reports whole layer
rects); three misses in a row now turn the parts back to the engine's for the document;
- frames built on their slot's own frame had no scroll compensation in the diff (engine 0071):
every layer transaction during a pan was a whole read;
- T-511's own-slot rule took a slot stale whole after a one-off whole change (each drag's
settle): never a slot stale whole now (both lanes' default behaviour);
- the picture's geometry no longer has to match the frame's overscan row or height; it reads only
the rows around the last picture's parts.
JIHAD_GPU_CPU_PARTS_STALE=1 (the owner's trade, off): frames keep the previous picture while a
changed part's is made (at most 600 ms).
Scripted pan, the card moving: desktop Wikipedia 9.4 fps without, 11.2 with the parts on the
CPU, 14.2 with the stale switch too; the long page 18.8 -> 24.7 (parts + stale). By finger the
rounds spread 11-13 fps on Wikipedia against ~10 without. Frames looked at: parts once, in place.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtfxSpM1w2uiVKeLKoV3g3
The owner's four requests of 2026-10-26 (evening), researched and written as kits,
with Tier 91 (T-545..T-560) on the build site. The owner's choices the same day:
T-505 first, then these; the engine waits for UXP's next RB_ tag (the newest is
still our base RB_20261006); the SDK to Redux 0.4.1 and /opt/PalmSDK refreshed.
- cavekit-lowpower-uxp.md + docs/research/lowpower-uxp.md: the scan of the local
engine, Moonchild's projects and the listed forks; twelve levers ranked (JS
helper threads for two cores, -O2, jemalloc's retained pages, memory prefs,
reduced motion, lazy images, decoders, omni.ja); none measured yet
- cavekit-engine-release-2026-10.md: RC_20261026 is 12 small commits past our
base, only patch 0060 overlaps (its roots now upstream)
- cavekit-webos-sdk-update.md: HP's PDK is final; Redux 0.4 -> 0.4.1
- cavekit-atlas-references.md: the app moved to webOS-ports; the adapter and
server forks' parents are the 2013 code, so Atlas itself is the upstream
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtfxSpM1w2uiVKeLKoV3g3
The owner's sequence: a Codex adversarial review (context/impl/impl-review-findings-t505-codex.md), then
"prove the cause first": JIHAD_GPU_NO_PUBLISH=1 (a diagnostic: frames made and read, never handed to the
card) shows the same daemon work making desktop Wikipedia 32 fps and the long page 53 while LunaSysMgr draws
nothing, 8.6 / 13.6 while the card moves: the card's redraw on the shared GPU and memory makes every daemon
stage ~3x slower. Then the card's paint measured (the adapter's [paint-stat] lines under its paint log): a
~10 ms software blit (Piranha's PSoftContext2D) of the whole view ~20 times a second, mostly repaints; a
PGSurface kept per frame changed nothing (not kept). The frame is now wrapped without alpha (every path
writes alpha 255): the blit 9 -> 5 ms, LunaSysMgr's card instance -15 % CPU while panning, the picture the
same; <state>/alphawrap reverts. The pan rate is unchanged; the owner's plan is the CPU/GPU split next.
tools/host/express-jobs.py also reads scripted pans.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtfxSpM1w2uiVKeLKoV3g3
The owner's bounded overview. Right after a zoom in that raises the resolution, the express thread posts, all
at once and while the layer tree still holds the tiles at a resolution of 1, two or three windows (a frame's
rows each at half the zoom: the kept frame's scroll and a frame below and above, the scrolled content alone,
read with their alpha so rows no tile covered are left out) and the page's fixed and stuck parts alone at the
kept frame's scroll (with their alpha). At the zoom back, when the kept frame is off the card's view and the
picture covers it, the frame is the picture at twice its size with the parts drawn over it where they sit at
the new position. Desktop Wikipedia by finger: 40-56 ms where the paint's frame came at 294-614 ms; a pan past
the picture still waits. An inspector review's six findings fixed (the readback forced the alpha, the parts
carried the old background, the sticky probe, the scratch's lifetime and size, past-the-last-window placement,
one-to-one matching). Cost: the zoom in's sharp frame 682-779 ms against 519-545.
T-505 measured read only (the owner's "measure first"): tools/device/t502/finger-pan.sh and
tools/host/express-jobs.py; desktop Wikipedia 9.5 fps and the long page 16.6 under a finger, bound by the
readback path (docs/rounds/t505-2026-10-26/notes.txt).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XtfxSpM1w2uiVKeLKoV3g3
The owner, watching finger pans: "the center column is scrolling/panning smoothly but the sidebars
are not". Between frames the card moved the whole frame it holds, desktop Wikipedia's sticky sidebars
with it, and each new frame put them back. Engine 0068 returns each frame's fixed and stuck rects
with its poll; the daemon writes them and the view row into the 192 bytes before the segment
trailer (JihadStuckBlock, tagged with the frame's number; JIHAD_GPU_NO_HOLD=1 off); the adapter draws
them where the frame drew them and covers their moved copy in the page's colour beside them.
Four mid-drag screenshots each way: sidebars at +0 px in all four with it (the column moved up to
150 px), displaced 11-12 px in two of four without; no ghost; frame rate unchanged.
R3's pan criterion is re-opened against the corrected test (the owner's choice): with the card
moving desktop Wikipedia pans at ~7 fps. The card-redraw throttle prototype showed no gain and is not
kept. UXP_PIN and SRCREV at 078a0942.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KP7JxhNqPrvYp27QDy8hP8
The owner, watching a scripted pan: "the center column of the page doesnt move, just the sidebars".
The inject pan sent the card's scroll commands to the daemon and the card's view stood still; every
scripted pan figure so far left out the card's own redraw. It now tells the card to scroll each step and
the card reports its scroll, one source as under a finger (JIHAD_INJECT_PAN_NOCARD=1: the old test).
Measured with the card moving: desktop Wikipedia 86 frames in 11.9 s of real finger drags (jobs a median
95 ms: the card's redraw shares the GPU, the stuck sidebars re-read as ~700 whole rows a frame), the long
page 222 in 11.6 s. The express-thread copy prototype (T-505) showed no gain and is removed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KP7JxhNqPrvYp27QDy8hP8
The owner chose both levers after measuring each alone: the first frame at a new zoom reads the card's
view (engine 0067, compose flag 16; JIHAD_GPU_NO_ZOOM_VIEW_FIRST=1 off) and the daemon brings the second
core online on the card's zoom or pan (cpu1/online written 1 only where it reads 0, at most every 500 ms;
JIHAD_NO_CPU_UP=1 off; never the governor). UXP_PIN and SRCREV at 46894167.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
T-527's scope is done: the sensor bench (R3's 24 fps met on it), the engine work 0062-0066, R8, the
zoom's frames, two reviews' findings fixed. What is left needs a decision: T-504 a picture of the
whole page at the fit zoom, T-505 the adapter composing the new band over the frame it holds (no
copy a frame), T-516 a GPU clock floor after a pause.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Daemon: zoomBackKeep(newZoom) from either lane (only a resolution-1 frame not at the new zoom, once
per shown frame, reusing its buffer), no publish while a job's read may copy from a slot, the main
lane's old-zoom frames superseded, dropped at an input and once the tree is at 1 again; an adopted
frame at the held zoom releases the hold; the world offset cleared for a rooted document; the
adopted failure count; mLoadWasDone atomic. jihadPersonas.js: the search list's filter attributes
observed; a detail view's length kept only in the window made for it.
Device: double taps out 0-1 ms with the page's script busy (12 of 12 zooms within 250 ms), about:addons
sharp after a pinch, the search filter's length followed, pans and verify unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The search list joins the main list in the relabel (as its results arrive) and in JihadEngine.jsm's
surface table (check-engine-api.py: 0 FAIL). Enyo by finger: twelve local results for a search
pan to the last.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
preferences.js marks the font rows with their pref, the pref-less rows with their label and the
fonts reset with an id, for the finger walks. Mojo's card header above the page scrolls away
with it: the walk counts it once the page is scrolled.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A view with no list reports what overflows it at the card's height and keeps that length while
the same view is shown (its box stretches with the window); the window's resize measures again.
Enyo by finger: Palefill's preferences (1233 rows at the 980 layout width) pan to their last row,
one layout change, no loop.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the sensors running the same build gives 22.7-23.6 and 32.8-33.1. Criterion 1 ticked on
the owner's bench (choice (b) of 2026-10-24); the gaps' criterion [~]: what is left is the
compositor job's cost.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
FINGER-TESTS' about:addons item ticked; chrome-look R2 stays [~] for the search results and an
add-on's long details. Device: the three packages from 623dc1ac+ installed, default-check passes
in all three on the GPU path with 0 faults; Mochi's and Mojo's manual proxy from the 2026-10-25
proxy round (192.168.1.245:3129, nothing listening) put back to No proxy.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The changed region is its hull in all but one of desktop Wikipedia's tree changes over a pan.
The own-slot base with stuck layers verifies correct (0 rows wrong on three pages) but is no
faster: Wikipedia 21.9-22.9 fps with more gaps, the long page 37.5 fps with 25 gaps.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
At a zoom in that raises the resolution the daemon keeps the frame the card shows; when the card
comes back to exactly that zoom and the kept frame covers its view, the express lane publishes it
into a free slot at once. The old tiles at under half their size make no frame, so the double tap
out had nothing until the paint at its resolution (573-771 ms). Device: published 0 ms after the
zoom, the painted frame at 771 ms, the kept frame dumped and looked at.
JIHAD_GPU_NO_ZOOM_BACK=1 turns it off; JIHAD_GPU_ZOOM_BACK_DUMP=<path> writes it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From the inspector's read of the night's GPU-path changes (notes.txt lists all fifteen):
- a new document resets the layout viewport when its height differs too (about:addons' list
length laid the next page out 4000 px tall)
- the express lane's 'under half the painted resolution' rule holds only while a paint at the
zoom's own resolution would draw larger (under 0.5 every pan frame was refused)
- the rootless flag and world offset reset on navigation and follow the shown document
- the fling speed over 30 ms at least, the lead at most the overscan rows and not past the end
- an adopted main-lane frame: not after a lost composite, only with the load done, published with
the main lane's bookkeeping and failure count, its next key the second job's slot
- the critical phase's end leaves a newer held zoom alone; zoom release and critical end take
the frame lock; the dirty key includes the page height; the displayport is set again at a new
window size
- the inject channel: cardscroll, and rect reports the engine's and the card's scroll
Device (daemon 7e78ab50, libxul 707d9e76): pans 33.1 / 23.6 fps, verify 0 wrong, zooms as
before, default-check 0 faults, about:addons -> a page -> about:addons right.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
UXP_PIN and the recipe's SRCREV at the engine branch's f4fefca0; patch-queue --check reproduces it
with the 65 patches. Device: pans unchanged (the long page 33.1 fps, desktop Wikipedia 23.6), verify
0 rows wrong, default-check on the GPU path with 0 faults.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
prefs-finger-walk.sh walks PANES by tapping each control on the card's input path, picks a
picker's item by finger at the select's x, and checks each walked pref against the copy taken
before. preferences.js marks each row with its pref and gives the Browser pane's controls ids.
prefs-row-walk.sh evaluates the table with the page's functions stubbed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Found by finger with twelve sideloaded test extensions: the list did not move. The card was told the window's height
(a XUL root's min-height never reached the reported size), and on the GPU path a page with no root scroll frame cannot
be moved by the card's scroll (no engine scroll, no root metrics): every frame showed its top, the main lane's frames
labelled at the engine's scroll 0.
- jihadPersonas.js growToList puts the list's whole length on the root (jihad-content-height, from its items, so it
does not follow the window); the daemon makes a XUL document's window that tall, and back when a view says 0
(GoannaRenderPage::XulContentHeight/LayoutHeight, BrowserPageGoanna::emitGeometry).
- GoannaRenderPage::GpuRootless (a XUL document); gpuScrollTo, the express lane's view and the main lane's frame
position use the compositor's world offset for such a page.
- A page that got shorter (a list to an add-on's details) has the card's scroll clamped (msgScrolledTo with its own
position; the adapter only re-sizes its scroller).
By finger (Enyo): two drags reach Pad 12, a flick returns to the top, Pad 12's More opens its details from their top.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The card sends its position on every step of a kinetic coast; the express frames trailed a ~4000 px/s coast by one
or two frame times, and the card slid the older frame past its overscan (the lower 27-50 % of the card grey for
~0.4 s after a flick on the long page, the fixed header gone). The reader thread keeps the card's speed from its
positions; xStart composes at the position plus speed times 80 ms (no further than a card's height, not above the
page's top) and the header's renderedY places it. By finger: content to the bottom 0 and 250 ms after a flick; the
fixed header still slides for the first ~250 ms; slow drags unchanged.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The 480 px spinning cube, the sensors running: 25.3-28.0 fps on the card (was 16.6-22.0), 360 px 28.9-29.9,
240 px 29.4-30.0 (the page's own ~30); verify with a ticker beside the canvas and the cube stopped 0 rows wrong.
- The frame trailer's dirty words (render/browserserver/Src/JihadFrameWindow.h): before each msgPainted the
daemon writes the rect that differs from the frame published before it and both frames' numbers — the
union of every composite's change since, at that frame's geometry; a forgotten job, popups, a software
frame or an earlier-posted job not yet polled make it whole (BrowserPageGoanna pubDirtyAdd/pubDirtyTake,
publishWindow; JIHAD_GPU_NO_DIRTY=1 off). The adapter, showing that base frame at the same geometry, zoom
and scroll, invalidates only the rect (BrowserAdapter::msgPainted, BrowserOffscreen::dirtyRect). The YAP
messages and the header are unchanged; docs/IPC-CONTRACT.md now describes the trailer.
- Engine patch 0063 (bda31412): a change too tall for the 256-row band surface takes a 512-row band surface
(JIHAD_GPU_BAND_TALL) instead of the frame-sized target; frames are packed for the band surface first, so
desktop Wikipedia's pan frames stay where they were (its pan unchanged). Pins moved; 63 patches reproduce.
- The PDK adapter had not built since T-540: YapProxy.h's member initializer (m_sendFailed) is C++11 and the
PDK's gcc 4.3.3 refuses it; initialized in the constructor. The YAP contract check passes.
- The pan's 56 ms+ gaps traced: tools/host/gap-trace.py, and with JIHAD_GPU_TIMELINE=1 the express lane notes
why it made no frame and every trailer is logged. Desktop Wikipedia's 10 s pan: 24 gaps, all the compositor
job's (a whole read after a tree change, the copy from the base, a job behind the page's tile uploads).
- default-check.sh reads across the daemon log's 2 MB rotation; gpu-spike-collect.sh removes the frame dumps.
- Kit R8's 24 fps criterion ticked, R3's gap criterion annotated; T-511 DONE; notes, README knobs, ENGINE-SOURCE
0063, PICKUP.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Measured with the emulated finger on desktop Wikipedia, the sensors running: the first frame painted at a new
zoom's resolution 593 ms after a double tap in (was 2212), 669 after a double tap out (1890), 513 after a pinch
in (1660), 551 after a pinch out (746); the first frame at the new zoom stays 58-105 ms.
- The critical displayport (GoannaRenderPage::SetGpuDpCritical, BrowserPageGoanna::gpuCriticalEnd): a zoom that
changes the resolution paints what the card shows first, no margins; the margins once a frame of that paint
is out (2 s at most). JIHAD_GPU_NO_CRITICAL=1, JIHAD_GPU_CRIT_MARGIN=<CSS px>.
- The express lane publishes a main-lane frame composed while the main thread is away in the engine (40 ms,
JIHAD_GPU_EXPRESS_TAKEOVER_MS): it polls the job, publishes its slot and takes it off the main lane's list
(a double tap's repaint sat composed 845 ms behind a 1.1 s pump of the page's script). A main-lane post
kicks the express thread; it looks every 3 ms while a main-lane frame is in flight.
- The zoom hold ends when the express frame is posted, not published; a zoom out past half the painted
resolution makes no frame from the old tiles (471 ms of minified draws for a mostly blank frame).
- Engine patch 0062 (63c20e39): PaintFrame's DecideScrollableLayer replaced the root's displayport base with
the composition size at the origin on every paint, so 0059's base (what the card shows, at the shift, times
the resolution) never reached a paint; the GPU path now keeps it. Pins moved (62 patches reproduce the pin).
- JIHAD_GPU_ZOOM_DUMP_SEQ=1; tools/device/t502/finger-zoom.sh (+ finger-zoom-device.sh); zoom-seq.sh ROUND_DIR.
- Pans unchanged or better (long page 29.5-35.4 fps, desktop Wikipedia 22.3-28.5), verify 0 structurally
wrong; ENGINE-SOURCE rows for 0059-0062; docs/rounds/t527-2026-10-25/notes.txt; kit R6 annotated (still open:
the double tap out's first frame within 250 ms); PICKUP's delta.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
