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>
Five desktop test scripts could not compile or link since T-515/T-517: EngineHost needs GDK and the
stall sampler (GoannaRenderPage), BrowserPageGoanna needs render/browserserver/Src (JihadFrameWindow.h)
and the daemon the Luna service module. embed-smoke and embed-load take the tls test's pattern,
find gets the include, headless-daemon, adapter-roundtrip and build-daemon compile and link
JihadLunaService; embed-smoke runs under Xvfb like the others. On RB_20261027 14 of 18 pass; the
four left are the desktop GTK path's known read-back limit (PICKUP 2026-10-14).
build-goanna-arm.sh: an optional second argument, the jobs count for mach build. Two engine builds
at once on this host had earlyoom kill cc1plus (the ZFS cache counts as used); one build, fewer jobs.
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>
The emulated finger (tools/device/finger: tap, dtap, hold, drag, drag2, flick, pinch, sleep, raw) drove the
scrolling and gesture items of docs/FINGER-TESTS.md in Enyo, Mochi and Mojo; every result is on its item and
the data in docs/rounds/finger-2026-10-24/zoom-grey.txt.
Found and fixed (the owner's "areas turn grey" of 2026-10-18):
- A double tap on desktop Wikipedia fitted a 104 px infobox cell (6.2x) and the engine's default maximum-scale
of 10 passed the adapter's cap: the smart zoom's block is at least a third of the card wide, and a viewport tag
without maximum-scale reports 4.0 (GoannaRenderPage).
- At rest the zoomed frame lost its right third from a zoom of 2.0 and everything from 2.98: once the pres shell
has a resolution, Gecko takes the root's displayport base in layout device px and divides base + margins by the
resolution, and nsGfxScrollFrame divided the root's display-list clip too; the scroll port handed over in CSS px
shrank to 479 px at 2.33, short of the card's view 531 px over (the engine has no sideways range on a page laid
out at the card's width). jihad_layout_set_displayport2 takes the card's shift and scales base and margins by
the resolution; the clip is the port on the GPU path (engine c79d16f8, patch 0059, UXP_PIN moved). The daemon
passes the shift and sets the displayport again when the shift leaves the re-anchor margin or the zoom changes,
and sets the resolution BEFORE the displayport (a pinch from 2.33 to 2.8 clipped again; the zoom-out painted the
whole page, 160 tiles).
- A tap or a second double tap on a zoomed page found nothing: the GPU path keeps the position in the engine's
scroll and the compositor's shift, not the render pan docToViewport read. docOffset/gpuAlignForHitTest scroll
the engine to the card's position before a discrete hit test; a zoomed-in page with no block under a double tap
answers the page's width, which the adapter clamps to the fit.
- Above a resolution of ~4096 / the layout viewport's larger side the frame still clips (3.49) and empties (4.0),
even with the resolution held (JIHAD_GPU_RES_MAX, kept for bisection): the page's maximum-scale is capped at
4000 / the declared viewport's larger side on the GPU path (2.91 for desktop Wikipedia, 4.0 for a device-width
page). The cause, the coast gap of a flick (the engine paints only at the coast's end: ~0.5 s of blank lower card
and no fixed header) and the first frame at a new zoom (1.6-2.9 s) are T-527's.
Verified on the bench after the fixes, all three variants (dev copies: libxul 4d753b8f, daemon 7c29035a, the
originals kept as .orig): the double tap to the infobox at 2.33 full at rest, a sideways drag at the zoom painted,
pinches to 2.99 full, the zoom-out at once, a tap on a zoomed link opening it, Mojo's pinch on mobile Wikipedia
never grey, the WebGL cube through a pinch, a drag and three reopenings, the settings and personas pages flicked
to both ends. T-514 (the owner's finger round) closes with it; R12's "finds it smooth" stays the owner's word.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The owner's 2026-10-24 directive: drive the finger-blocked criteria with an emulated finger, not by
assumption. Read from the device and its binaries: hidd sends each scan of the Cypress panel as one
datagram of 16-byte input_events to the AF_UNIX datagram socket LunaSysMgr binds at
/var/run/hidd/TouchpanelEventSocket (libhal's halTouchpanelMain.module parses it: EV_FINGERID opens a
finger, EV_ABS 0/1 x/y, EV_KEY BTN_TOUCH down/up, EV_GESTURE the flick velocity, one EV_SYN a scan; the
Qt QPA plugin libqpalm.so makes QTouchEvents). tools/device/finger/finger.c sends the same datagrams
in the panel's frame from portrait screenshot coordinates (raw x = y, raw y = 767 - x).
Proven on the bench: libhal logs "Unexpected code" for a malformed datagram; a tap opens the app
menu; a 500 px drag scrolls jihad-long-static.html from paragraph 1 to 8 through the card, the adapter
and the daemon; a 160 ms flick coasts to paragraph 33; a pinch out zooms in; a long press opens the
context menu; a double tap on Wikipedia makes the daemon log smartZoom; a tap on the address field
raises the keyboard with the address selected and a tap on the q key types q.
The kit cavekit-finger-emulation.md (R1 the path, R2 the gestures, R3 the round, R4 fit), Tier 89
(T-523 the finger, T-524..T-526 the round by area, T-527 the GPU floor under the owner's levers:
sensord off and the compositor thread), docs/FINGER-TESTS.md's head, PICKUP's evening note. Codex hit
its usage limit on the investigation; the path was read in-house with radare2.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The chain ran without a prompt once commit.gpgsign was false per repo in Jihad-Browser and
third_party/uxp (the owner, 2026-10-24: Gitea credentials serve git.trueog.net / git.true-og.net
only). Engine 7a872e8f, then 506c4114 (T-487), 3f4e1a27 (T-513/T-499 with the engine fold),
318869f2 (Tier 88). PICKUP, the build site and the loop log carry the hashes and the owner's push
commands; T-521 is complete in the registry.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Tier 88 (context/plans/build-site.md): the registry had no unblocked task left; what remained to an
agent were criteria no task covered any more.
T-518. Criteria met by earlier tasks ticked with their evidence: gpu R11's review (T-513 and Codex's
2026-10-24 pass), content-blocking R7 (the bundle's sha check against NOTICE and the lists' README, the
README paragraph with cardview.jpg, round 26's licence reading), modern-web R1 (T-484 and run 2c; the
README's Caveats link) and T-500's two. T-501's stays [~] for MSE (below). The template placeholders
never filled (T500_KIT, T501_KIT, T501_DEVICE_RESULT in docs/MODERN-WEB.md, DEVICE_STATE_EVENING and
TRACE_PICKUP in PICKUP) are filled; .cavekit/config is the owner's one line again; the README's
"Where it stands" regenerated.
T-519. On the build with the review fixes (engine 0058), the 10 s scripted pan on six pages under
JIHAD_GPU_VERIFY=1 (docs/rounds/t519-2026-10-24/): 0 rows structurally wrong on all; 0 rows differ at
all on the long page, jihad-fixed-both.html (new: an opaque header AND footer, nothing else), sticky-mix,
scroll-js and Hacker News; Wikipedia 3 of 70 frames with resampling-class rows. The one miss is the
verify mode's own: on jihad-anim-css.html the animated block's 160 rows differ (the reference samples the
animation at its own compose time), every other row equal — R2's first criterion [~] with the engine
fix named. The dumps looked at frame by frame; Hacker News at 0.955 shows its right side and bottom.
R4's four ticked on the compositor's lines: the fixed-both page reads two bands with both kept, the long
page one kept, Wikipedia's see-through panels as 2 columns in 3-5 chunks; sticky-mix takes the whole path
as in T-503's rounds (its sticky layer changes every step). R3's table: the GPU path against NOGPU=1 on
every page, in docs/RENDERING-OPTIONS.md — the GPU path ahead on every page (long static 30-33 against 11-12.5 fps, Wikipedia 18.5-26 against 2.7-2.9, Hacker News 37-48 against 6-10). The frame rates were measured again
without verify after a first sweep read 5-6 fps under it (a whole reference per job):
tools/device/t502/README.md says so; pan-run.sh takes ROUND_DIR.
T-520. The blocker's device criteria on the Enyo card through the inject channel, the listed hosts mapped to the
host PC in the device's /etc/hosts for the run (only the blocker can then stop a load): a listed host opens
top-level; EasyPrivacy's ||123count.com^$third-party loads first-party (the page on that host) and is refused
third-party; an @@||host^ exception (a list copy with one added, exceptions 6+1083 against 5+1079) loads the
host; the master switch and hiding flip live through setpref (the observer re-applies the sheet); the
settings line shows the versions and a counter that rose 10 -> 16 on a page with 6 refusals; "Update the lists
now" moved the lists three times and the line followed; shouldLoad on 200 refused images is within 10 % of
blocking off (6.5 against 6.0 s, the floor the engine's own per-image work); MSE reports H.264 and AAC
(T-501's criterion closed). R4's cost criterion was NOT met: hiding on cost the MDN page's copy 3.7-7.5 s
against 2.6-3.0 off, the real cached page 15 against 11, and a daemon's first load 8-12 s.
T-522. Four variants of the cached sheet on the device named the cost: the 268 @-moz-document regexp groups
(one per site-excepted generic selector, each carrying the 160 generic-hide hosts' 2.4 KB regexp again),
evaluated per document; the same 13,079 keyed selectors under url-prefix scopes or bare cost nothing. The
compiler (version 11) keeps those selectors apart (excSel) and the component adds them to the per-document
sheet for every host the selector is not excepted on, with the generic-hide sites (hosts and address
prefixes) honoured there too; the global sheet keeps its one regexp group. Measured: the MDN copy with hiding on 2868, 3104, 2876 ms against 2712, 2578, 2846 off
(+8.7 %, within R4's 15 %), a daemon's first load 3.7 s where it took 8-12; generic hiding still applies
under a host name, a site-excepted selector is hidden where not excepted, and a $generichide host
(jetzt.de mapped to the host PC) gets neither; the compile reports 268 excepted selectors per document and
154 generic-hide sites with 4 address prefixes.
New test pages: jihad-fixed-both.html (an opaque header and footer), jihad-tp-first/third.html,
jihad-exception.html, jihad-hiding.html, jihad-excsel.html, jihad-mse-probe.html, jihad-plain-ok.png.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
T-513. Two inspectors reviewed Tier 87 (Codex was out of credits) and found twelve problems, all fixed
(context/impl/impl-review-findings-gpu-2.md). The engine's are engine 0058 (the band scratch per
compositor, every closed card's pbuffers and GL objects freed, the frame surface current for a stacked
band frame, WebGL textures externally owned, given-up reads counted and never copied into a slot, the
regions cap, the sticky probe's reach); the daemon's: the buffer the card shows is never composed into,
the express jobs forgotten on a GPU fallback, a job of another frame size given up, the adapter's window
check, the inject threads joined. Twenty card cycles add 76 KB (R10, was +16 MB a card).
R2's new criterion passes: a fast flick (40 verified frames, shifts to 1210 rows) and two cards panned
in turn (22 frames) with 0 rows wrong. JIHAD_GPU_VERIFY's reference is now composed right behind its
job on the same layer tree: composed at the job's poll it met a tree the flick had moved on from and
called right frames wrong. New round tools: tools/device/t502/two-cards.sh, the inject channel's
"target focus|last", the Enyo hook's A step.
Codex then reviewed all of it and found nine more, all fixed: the opt-in read paths' late writes (engine),
the previously shown buffer's in-flight mark restarted on each publish, the verify buffers a pool never
resized or reused while pending, the document key the inner window's id, the adapter's window bound by
division, finished inject threads reaped, and the spike scripts' daemon waits and restore order.
T-499. The card's own size resent keeps a followed layout viewport; the layout viewport is the
document's (a new document starts at the card's size: a device-width page after a followed one was laid
out at 1000 and shown at 0.77); the rule waits until the document is parsed and never follows
about:blank (mid-parse the engine lays a page out at 980 as if it had no meta viewport). Probe page with
rotation and navigation, BBC, YouTube mobile, Wikipedia, DuckDuckGo: docs/rounds/t499-2026-10-19/.
The three interfaces pass their default checks on this build (GPU path, express lane, no fault or
fallback); the bench runs it with the rebuilt adapters. Engine 0058 is in the patch queue and the pins
moved to it (build/engine/engine-version.env, the OE recipe, the gitlink, ENGINE-SOURCE's row). The kits'
criteria this met (gpu R2's flick and two-card criterion, R10's twenty cycles, modern-web's T-499 line)
and PICKUP's night delta with the traps (the bench's Wi-Fi outage, prefs saved over by an exiting daemon)
land with the Tier 88 commit that follows, whose kit edits share hunks with these.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
On the Enyo card: a forced update (lastUpdate cleared) fetched EasyList 202610191826 and EasyPrivacy
202610191828 over HTTPS, logged the versions and the counts, and the next page's image from
beacon.cdnpure.com, a rule only in the new EasyPrivacy, was blocked (render/goanna/test/
jihad-blocking-update.html, docs/rounds/t487-update.png). With the network off (a dead proxy) the update
logged "no download" for both lists and changed nothing, with no dialog (t487-netoff.png). Across daemon
restarts no download within 4 days, nor within a day of a failed one.
Two bugs the runs found, fixed in components/jihadContentBlocker.js: EasyPrivacy was refused as
"truncated" on every update (its 57,139 lines held against both lists' rule count; each download is now
held against its own list's copy), and a due update skipped at the timer's one early look (a page had
started within 20 s) waited six hours (it now looks again 60-90 s later).
tools/device/set-prefs.sh waits for the daemon to exit before it edits prefs.js (an exiting daemon saved
its prefs over the edit).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
count-blocklist.py classified rules with the compiler's own regex family. tokenize() now reads each
rule a character at a time and shares no expression with it; --cross counts with both and lists every
rule they put in different categories, and --check runs the fixed vectors with both. On EasyList and
EasyPrivacy 202610151429 (the bundled snapshot, 139,838 rules) and 202610191813 (140,308) the two agree
on every rule. F-6 had been fixed with the recomposed card view; round 26 is closed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The kit's three criteria ticked with their evidence (the gate and the shipped daemons' three startup
lines, the 57 patches reproducing the pin, the docs' numbers); PICKUP's evening delta (T-505/T-511/T-517
blocked by the circuit breaker, the registry's cycle broken, detached builds); the README's progress
regenerated from the kits. Next: T-513, Tier 87's review.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rounds 349-358, recovered where the dead session left them (349-354) and run tonight (355-358):
the page's layer transactions hold the compositor thread for its tile uploads; deferring them,
topping up the texture pool, partial uploads as sub-images (gpu-bench.c section 18: cheap with the
GPU idle, but only 38 of a pan's 167 uploads qualify) and the express lane on its own slot each
measured without gain. A glFinish before the read shows the band frame GPU-bound (5.3 ms of compose
left after the 12 ms base copy). Desktop Wikipedia's 10 s pan 23.2-24.1 fps; the 480 px WebGL cube
19.5-20.9 on the card against the page's own 23.8-25.1. T-505, T-511 and T-517 are marked blocked
for the owner's finger round and the bench's outside sensord load; everything tried is in
context/impl/dead-ends.md and docs/rounds/t502-2026-10-17/floor-r314-320.txt.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The [jihad-gpu] lines of the engine and the daemon print only with JIHAD_GPU_LOG=1, or in a device
round's JIHAD_GPU_TIMELINE, JIHAD_GPU_VERIFY or JIHAD_GPU_DUMP_EVERY; failures and fallbacks print
anyway. One gate each: the engine's gfx/2d/JihadGpuLog.h (engine 0057, exported as
mozilla/gfx/JihadGpuLog.h) and the daemon's render/goanna/JihadGpuLog.h. A daemon on the GPU path now
logs three startup lines from the engine; a page's close logs its express-lane frame count, which
default-check.sh counts (all three interfaces pass on the bench, no fault or fallback). Hand-started
daemons (gpu-spike-start.sh) keep the lines (NOLOG=1 drops them).
Engine 0057 also puts the page's layer transactions on JIHAD_GPU_TIMELINE with their tile uploads
(T-517, rounds 349-357). Every JIHAD_GPU_* switch is in tools/device/t502/README.md; the README and
docs/RENDERING-OPTIONS.md carry the evening's numbers. The device scripts' per-run files are ignored.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Engine 0055: the bands and the sticky columns' chunks of a pan frame are regions of one composite (the
transaction, the diff and BeginFrame/EndFrame once; per region its world, Prepare and RenderLayer),
where each was a composite of its own at ~5 ms of CPU. Engine 0056: a tile whose transformed bounds
miss the clip is skipped before its texture is locked and bound. Chunked desktop Wikipedia frames
compose in 10.6 ms where they took 22.5, and its 10 s scripted pan runs at 23.4-23.9 fps (20.0-21.7
before). Verify mode, the default checks of all three interfaces and the measurements are in
docs/rounds/t502-2026-10-17/floor-r314-320.txt (rounds 342-348), with what was tried and dropped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
The owner asked for the progress of Jihad Browser's parts shown in the README, with the release as
the goal. A section after "What it is" shows, per area of the browser (the engine and page drawing,
the GPU, the modern web, the three interfaces, touch, settings, add-ons and Personas, privacy and
security, building, tabs), a bar of the acceptance criteria met, and what is left split into work
to do, checks only a person can make (a finger on the device, the owner's decision) and items that
wait on tabs; then the road to release as a Mermaid diagram: complete areas, areas built and
waiting on a person, areas with work left, the owner's finger round, the last review, the release,
and tabs held.
Nothing in it is typed by hand: tools/readme-progress.py counts the "- [x]" and "- [ ]" criteria in
context/kits/ and the checks in docs/FINGER-TESTS.md and rewrites the section between the README's
progress markers (--check says whether it is current, --print shows it).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
Rounds 334-341 (docs/rounds/t502-2026-10-17/dtap-r334-341.txt): scripted double taps on Wikipedia,
2 of 18 first frames over 250 ms, with the second core unplugged after an idle pause; the scripted
tap skips the touch path's governor ramp, so a finger's tap is for the owner's round. T-504 stays
PARTIAL: its token budget (the plugin's default) is spent and is the owner's to raise.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
An inspector review of the day's GPU-path work (context/impl/impl-review-findings-gpu.md), every
finding fixed:
- the express lane builds on its slot's own frame only with no main-lane job in flight (a composed,
unpolled job's change was in no slot's record), never takes a slot a main-lane job holds, and a slot
is invalid from a job's post (either lane) to its publish;
- an own-slot base after a scroll only when neither the latest composite nor the slot's frame had
fixed or stuck layers (the engine judges those against the previous composite);
- a failed main-lane job drops every slot's record; a recentring move invalidates the slot first;
- engine 0054: a window-moved shift saves every kept rect before writing any, and WebGL makes no EGL
contexts once the daemon has given the GPU path up (jihad_offscreen_gpu_given_up);
- the adapter reads the window trailer once.
T-504: a zoom's express frame gives up main-lane frames at the old zoom that were not composed yet.
The day's failed approaches are in context/impl/dead-ends.md. Rounds 339-340: the default checks of
all three interfaces pass; verify mode on a main-lane Wikipedia pan, 0 structurally wrong frames.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
The README no longer says Jihad draws in software or has no WebGL: pages are drawn on the GPU by
default (a pref goes back to software), frames keep coming while a page's script runs, WebGL 1 works;
the caveats give the measured frame rates and WebGL's missing extensions. docs/RENDERING-OPTIONS.md
gets the Tier 87 outcome: what the GPU path does, a table of what it measured against what it
replaced, and what it does not reach yet. tools/device/t502/README.md now names all 72 JIHAD_GPU_*
switches in the code (the eight older device-round ones were missing).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
Kept like an opaque layer once composed alike three frames running with the content sliding under
it one colour, it applied on Wikipedia to one 13-row sliver only (the contents panel's highlight
follows the reading position) while its per-frame save and compare slowed frames (median gap 71-72 ms
against 42). Not kept; the records say what is left (fewer passes).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
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
The daemon has attached the shared frame segments write-through (the Palm kernel's shmat flag) since
2026-10-17, so every store reaches memory; the cacheflush syscall over the frame's rows, added in the
same round, cleans only to the point of unification (it is meant for code) and cost up to 4 ms a
frame on the publishing thread (3.7 MB line by line after a shift). It now runs only when a segment
had to be mapped cached; JIHAD_GPU_CACHE_CLEAN=1 cleans anyway. Wikipedia pan, median frame gap
42-43 ms against 45 (rounds 323); what the card shows checked by eye on the cube and Wikipedia
(round 324).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J67ZH8aYy8uzhgZDZ6Nvx9
