可见页面优先：PDF 底图与框选性能对照¶
2026-10-29。该改动对应 PDF 性能分析中的任务调度方向；与旧批注中的重复原生链接是两个独立问题。
改动与取舍¶
Scroller 为滚动缓冲区挂载邻页。旧版 AgenteroRenderLayer 挂载后立即生成每张整页底图；引擎把 renderPage 排为 CRITICAL，而高清瓦片和用户框选的 renderPageRect 为 HIGH。在单 worker 上，屏外重页因此先于可见瓦片与框选运行。
现在通过已有页面壳的 IntersectionObserver 可见性控制底图请求。页面进入视口才请求底图，离开时中止尚未完成的请求；已有 pinned 底图仍可显示，缓存、分辨率、旋转与上游瓦片生命周期保持原策略。不支持 IntersectionObserver 时仍按旧行为渲染。
这取消了屏外整页底图预取，首次滚到未缓存页面时才生成该底图；高清瓦片仍由上游按视口请求。正在 worker 内执行的同步光栅不能被强制抢占；该改动减少提前入队的任务，没有替换上游队列。参考 PDF.js 的 visible pages / detail views 优先策略，复用浏览器可见性能力实现此处局部控制。
实测条件与结果¶
Chrome 154 / macOS、DPR=2，真实 PdfViewer，固定 740×900 阅读区，缩放约 85.3%。AgentCompass 2607.13705 使用真实 PDF 与原 19,808 条 sidecar 的内存副本，两个条件均已启用批注判重与 512px 瓦片。浏览器的内存 sidecar 读取先于原生批注加载，所以上游延后执行导入时两个条件实际都创建 206 条；它与完整桌面文件读取较慢、能提前比较原生链接而只创建 8 条的时序不同。保存侧始终压成 206 条，避免继续增长。每次重载页面并打开新 engine，等待全部已发起任务结束；先运行可见性条件三次，再恢复旧代码运行三次。未把同一结果重复计数为更多轮次。
计时从 openDocumentBuffer 发起开始。瓦片完成指 BMP Task 返回；图片 load 单列记录，不等同于 GPU 实际呈现时刻。数值是本机样本对照，不是跨平台性能保证。
| 指标（ms） | 缓冲页全部生成底图 | 仅可见页生成底图 |
|---|---|---|
| 首张图片 load，三次 | 268 / 249 / 231 | 267 / 248 / 242 |
| 第 1 页最后瓦片 Task 返回，三次 | 1872 / 1762 / 1772 | 291 / 280 / 274 |
| 第 1 页最后高清图片 load，三次 | 1875 / 1764 / 1773 | 293 / 284 / 292 |
| 初始底图请求页（从 0 开始） | 0、1、2、3 | 0、1 |
首张图片耗时没有显著改善；首屏高清瓦片 Task 完成的中位数从 1772ms 降到 280ms，约减少 84%。图片 load 中位数从 1773ms 降到 292ms。
另做一次交互对照：重载后等待首张图片，立即用实际鼠标事件点「视觉批注」，在第 1 页相同位置拖框，等待备注编辑器出现。旧版 PNG 裁剪 Task 为 1384ms，改动后为 18ms。这个值包含排队、渲染与编码，不包含用户拖动；它是打开期间的单次排队对照，不代表所有区域的固定裁剪耗时。第 3 页重图在闲置后的原生 WebKit 裁剪为 176ms，测量条件不同，不与此处 18ms 混算。
原生 WebKit 对照¶
同日解锁后补齐 macOS 26.6.2 / WebKit 的完整桌面对照。使用 Tauri 开发应用、原 Vault 的完整副本与 NOTES 分屏，DPR=2、缩放约 89.2%，第 1 页顶端约 113 CSS px。每轮退出应用后重新启动；固定从第 1 页打开，保留相同的原 19,808 条批注 sidecar、系统 CJK 字体 fallback、512px 瓦片与批注判重。两个条件每轮都只创建 8 条用户高亮，先测可见性条件三次，再恢复旧底图调度测三次。未清除操作系统文件缓存。
| 指标（ms） | 缓冲页全部生成底图 | 仅可见页生成底图 |
|---|---|---|
| 首张图片 load，三次 | 610 / 532 / 687 | 546 / 566 / 577 |
| 第 1 页最后瓦片 Task 返回，三次 | 2695 / 2400 / 2833 | 588 / 598 / 620 |
| 第 1 页最后高清图片 load，三次 | 2699 / 2410 / 2835 | 608 / 601 / 627 |
| 首屏底图请求的不同页（从 0 开始） | 0、1、2、3 | 0、1 |
首屏高清瓦片 Task 返回的中位数从 2695ms 降到 598ms，约减少 78%；高清图片 load 中位数从 2699ms 降到 608ms。首张图片仍约半秒，不能把后续高清完成收益说成首次出图也提速 78%。一轮误恢复到第 3 页的记录已排除，没有与第 1 页样本混算。
原生鼠标框选第 3 页同一插图，PNG 裁剪 Task 为 185ms；输入中文备注后，Host 实际写入 visual v2 JSON 和 marks/assets/ 下的 PNG，裁剪图已检查。编辑现有高亮备注并提交后，annotations.json 保存为 206 条。退出并重开应用，修改过的高亮备注、新视觉批注和裁剪图均恢复；8 条高亮 id、几何、custom、颜色均与原件一致，另 7 条备注保持原文。又完成跨页返回、原生滚轮滚动、滑块缩放重绘、原生引用链接从第 1 页跳到第 10 页。这里的 185ms 是闲置后的重图裁剪，不与 Chromium 的打开期间框选速度比混算。
所有写入均在隔离副本内，原 PDF 与原批注文件 SHA-256 保持不变。临时引擎采集和保持测试窗口打开的代码已移除，不进入提交。
验收与边界¶
- 三份 PDF（AgentCompass、中文 Harbor 报告、TRACE）首屏与第 3 页完成出图，截图检查未见缺块、白缝或文字清晰度下降。截图不提交到仓库。
- AgentCompass 连续跳页再返回、框选后打开备注编辑器通过；旧批注中的 8 条高亮保留。备注保存与重开、链接导航和缩放分别按实际阅读器流程验收。
- 全套改动的类型检查、相关批注 / 瓦片生命周期 / 旋转回归通过。临时性能采集与测试界面不进入产品代码。
- macOS 原生 WebKit 的完整 Vault 对照、框选、文件保存与重开验收已补齐，结果与 Chromium 分别记录。Windows / Linux 尚未验收。
已检查开发目录，无独立 Roadmap / TODO。剩余项在 PDF 能力文档维护：Windows / Linux 的对照验收；合法的大量不同批注、复杂重页的同步光栅及跨平台滚动仍需按各自样本评估。文字几何 / text runs 在本次原生追踪中单项主要约 20–30ms，未取得支持进一步改写的显著收益证据，保留现有延迟与缓存策略。