HyperFrames
HyperFrames 源码导读：同时间定位、强制重绘与 GPU 等待
在固定提交阅读 GSAP 适配器及共享派发器，对照测试，理解重复时间为什么有时必须再次渲染。
你将学会
- GSAP 在精确定位前接受一次抑制事件的小幅调整。
- 派发器比较最后时间值，而不是一个经过时间的窗口。
- 注册必须同步，完成可以异步。
开始前需要
- 具备基础 HTML、CSS 与 JavaScript 知识
- 本地练习需要 Node.js 22+ 和 FFmpeg
解释本章对应边界，使用清单评估可重复的视频工作流。
先看结论
- GSAP 在精确定位前接受一次抑制事件的小幅调整。
- 派发器比较最后时间值，而不是一个经过时间的窗口。
- 注册必须同步，完成可以异步。
固定一条小而明确的阅读路线
本文使用提交 0d5d3f3eb3aecd9fd64954d2767d3d64e97e58fc，阅读运行时适配器 gsap.ts、seek-dispatch.ts 及对应测试。先提出具体问题：渲染器连续两次请求同一时间，会发生什么？这比只描述大型目录树更能帮助理解行为。
没有时间线时，createGsapAdapter 的定位操作直接返回；否则先暂停，并优先使用 totalTime。它先定位到目标加 0.001 且抑制事件，再按请求的事件策略定位到精确目标。注释说明，小幅调整用于让 GSAP 在时间未变时也重新处理渲染状态。
对照普通派发与强制派发
dispatchSeekEvent 保存最后派发时间，并跳过连续相同值。forceDispatchSeekEvent 也更新该值，但无论是否相同都会派发。测试覆盖普通去重、强制重复，以及强制事件之后普通调用的去重，直接展示了两个函数的区别。
模块注释以同一调用栈内的重复请求解释动机，但实现没有在微任务或定时器边界重置所存时间。实际判断是与最后一个值严格相等。不能仅凭注释推导更广的调度保证；如果扩展依赖两次调用之间经过了时间，应为该行为写测试。
不仅数事件，还要跟踪完成和失败
hf-seek 监听器必须在派发仍接受注册时，同步调用 detail.waitUntil；注册的 Promise 可以稍后完成。派发器组织这些工作、保留拒绝原因，并通过 waitForSeekCompletion 等待各批工作。先 await 再注册，就已离开允许的注册窗口。
上游测试包含重叠批次、捕获等待启动后新增工作，以及并发等待者观察同一拒绝。应结合等待循环和保留失败的变量阅读这些用例。本文核对了测试源码，但没有运行上游测试集；下方序列是阅读练习，不是浏览器捕获实测。
实施步骤
- 1
对照固定版本的 gsap.ts 和 gsap.test.ts。
- 2
比较普通与强制派发函数。
- 3
从同步 waitUntil 跟踪到待完成任务集合。
- 4
设计扩展前阅读拒绝和并发等待测试。
可复制示例
dispatchSeekEvent(4) -> 一个事件
dispatchSeekEvent(4) -> 无新增事件
forceDispatchSeekEvent(4) -> 再次派发
dispatchSeekEvent(4) -> 无新增事件
事件内：用 detail.waitUntil(promise) 注册。
派发后：waitForSeekCompletion() 观察完成或失败。常见问题
普通去重会在下一轮事件循环自动过期吗？
所检查的实现没有这种重置，它把请求时间与保存的最后时间比较。
监听器可以先 await 再调用 waitUntil 吗？
必须在派发过程中同步注册，但被注册的 Promise 可以异步完成。
资料来源
- 固定版本 README来源核查 2026-09-07
- GSAP 适配器来源核查 2026-09-07
- 定位事件派发器来源核查 2026-09-07
- Three.js 适配器来源核查 2026-09-07
- GSAP 测试来源核查 2026-09-07
- 派发器测试来源核查 2026-09-07