The scripted pan moves the card, as a finger does; with it, desktop Wikipedia under a finger is measured at ~7 frames a second

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

docs/rounds/t527-2026-10-25/notes.txt

@@ -358,3 +358,26 @@ daemon bringing the second core online on the card's zoom or pan (the YAP reader
 - Pans with the sensors running (pan-s3-*): desktop Wikipedia 243 frames in 10.15 s = 24.0 fps, 18 gaps of 56 ms+
   (it was 22.7-23.6 fps, 24-34 gaps: the second core is up for a pan too); the long page 33.4 fps, 4 gaps;
   verify 0 rows wrong in 60 checks; default-check on the GPU path, 0 faults.
+
+## The scripted pan did not move the card; under a finger desktop Wikipedia gets ~7 frames a second (2026-10-26)
+The owner, watching a scripted pan on the TouchPad: "the center column of the page doesnt move, just the sidebars".
+pan-run.sh's inject pan sent the card's scroll commands (setScrollPosition) to the daemon itself; the card's own
+view never moved, so the frames for each position were drawn into a still view (the column still, the sticky
+sidebars redrawn). Every scripted pan measurement before this (T-502..T-527: R3's 24 fps, the gap counts) was
+made without the card scrolling. Now (JihadBrowserServer, BrowserPageGoanna::debugCardFollow) the inject pan tells
+the CARD to scroll each step (msgScrolledTo); the card's scroller moves its view and sends the daemon the
+setScrollPosition a finger's drag sends — one source of the scroll, as under a finger
+(JIHAD_INJECT_PAN_NOCARD=1 is the old test). A first version sent both and the card's late reports made the
+daemon see the page go back and forth (40 frames in 10.6 s; withdrawn).
+Measured with the card moving (sensors running):
+- the corrected scripted pan, desktop Wikipedia (pan-follow2-wiki): 91 frames in 10.3 s, the card holding all
+  three buffers 56 times (its redraw of each step returns them late); the screenshot shows the page moved whole.
+- eight real finger drags (480,900 -> 480,250 in 1 s each): desktop Wikipedia 86 frames in 11.9 s, express jobs a
+  median 95 ms (p90 174) where the old scripted pan had 30-38 (fingerpan1); the long page 222 in 11.6 s, jobs a
+  median 29 ms (fingerpan-long).
+- Why Wikipedia: under the finger LunaSysMgr redraws the card on the same Adreno at the touch rate, and the
+  daemon's composite and readback wait behind it (a 41-row read 72.6 ms, a compose 65.9 ms); and each Wikipedia
+  frame re-reads its stuck sidebars as whole rows (63..744, ~700 rows: 53-92 ms) — its tree changes nearly every
+  frame (the anchor's moves at a finger's speed, the sticky positions).
+- The express-thread copy (JIHAD_GPU_XCOPY, T-505's daemon-side prototype), measured with the old pan:
+  23.6/22.6/24.3 fps against 24.0/23.5/22.1 without — no difference; not the bound under a finger either.

render/browserserver/JihadBrowserServer.cpp

@@ -430,7 +430,11 @@ void JihadBrowserServer::processInjectFile() {
               jihad::FrameLockGuard frameLock;
               auto it = mPages.find(panProxy);
               if (it == mPages.end() || it->second.page != panPage) break;
-              panProxy->injectAsync(buf.data(), len);
+              // the card scrolls and reports, as under a finger (JIHAD_INJECT_PAN_NOCARD=1: the daemon is sent
+              // the card's scroll commands directly, the card's view still, as before 2026-10-26)
+              static const bool sNoCard = getenv("JIHAD_INJECT_PAN_NOCARD") != nullptr;
+              if (sNoCard) panProxy->injectAsync(buf.data(), len);
+              else panPage->debugCardFollow(py);
             }
             if (el >= ms) break;
             usleep(16000);

render/goanna/BrowserPageGoanna.cpp

@@ -1466,6 +1466,18 @@ bool BrowserPageGoanna::zoomBackPublish(int64_t now, double Z, const XWant& want
   return true;
 }
 
+// The inject pan (JihadBrowserServer) used to send the card's scroll commands to the daemon itself; the card's
+// own view did not move, so a person watching saw the frames for each position drawn into a still view (the
+// page's column still, only the sticky sidebars changing: the owner, 2026-10-26). Now it tells the CARD to scroll
+// each step: the card's scroller moves its view and sends the daemon the same setScrollPosition a finger's drag
+// sends (BrowserAdapter::scrollTo), so the card drives the pan as under a finger, and redraws as then. (Sending
+// both made two sources of the scroll: the card's report of a step arrived after the next step, and the daemon
+// saw the page go back and forth.) Not an echo: the daemon's echo marks are left alone.
+void BrowserPageGoanna::debugCardFollow(int zoomedY) {
+  const double z = (mZoom >= 0.05 && mZoom <= 20.0) ? mZoom : 1.0;
+  mSink.msgScrolledTo((int)(mAdapterScrollX / z + 0.5), (int)(zoomedY / z + 0.5));
+}
+
 void BrowserPageGoanna::debugCardScrollTo(int x, int y) {
   fprintf(stderr, "[jihad-bs] scrolledTo -> card: %d,%d (the inject channel)\n", x, y);
   mSink.msgScrolledTo(x, y);

render/goanna/BrowserPageGoanna.h

@@ -229,6 +229,7 @@ public:
   // T-527 device rounds (the inject channel): the card told to scroll to (x, y) CSS px (a
   // scrolled-to: its own view moves, as for a page's own scroll), and where the card is (CSS px)
   void debugCardScrollTo(int x, int y);
+  void debugCardFollow(int zoomedY);   // the inject pan: the card's own view to the scroll it was sent (quiet)
   void debugCardScroll(int* x, int* y) const;
   void gpuScrollTo(int x, int y, double z);   // T-502: the engine scroll plus the residual view offset
   // YAP: pluginSpotlightStart/End (0x1501/0x1502). The card's confirmation that it has

tools/device/t502/README.md

@@ -236,7 +236,11 @@ pending paint, no view-manager flush owed) is skipped after the first; `JIHAD_GP
 A zoom in that raises the resolution keeps the frame the card showed, and a zoom back to exactly that zoom publishes
 it at once while it covers the card's view (the double tap out: the old tiles at under half their size make no
 frame); `JIHAD_GPU_NO_ZOOM_BACK=1` turns it off, `JIHAD_GPU_ZOOM_BACK_DUMP=<path>` writes the frame as published
-(3.7 MB: delete it at once). The inject channel's `cardscroll <x> <y>` tells the card to scroll there (msgScrolledTo, as a page's own scroll does)
+(3.7 MB: delete it at once). **The inject pan moves the card now (2026-10-26):** `pan` tells the card to scroll each step and the card sends
+the daemon its scroll, as under a finger; before, it sent the card's scroll commands to the daemon itself and the
+card's view stood still (what the owner saw: the column still, the sticky sidebars redrawn), and every pan figure
+measured that way left out the card's own redraw. `JIHAD_INJECT_PAN_NOCARD=1` is the old test, for comparisons.
+The inject channel's `cardscroll <x> <y>` tells the card to scroll there (msgScrolledTo, as a page's own scroll does)
 and `rect` prints the engine's and the card's scroll with the rect (`scroll=`, `card=`): the finger walks use them
 (`tools/device/finger/prefs-finger-walk.sh`).