Gods Eye View 性能基线解读3D 实况地球在 Apple M5 上的启动、图层激活与渲染预算实测【免费下载链接】gods-eye-viewA spy satellite simulator in your browser, except the data is real. Live open source spatial intelligence on a photorealistic 3D globe.项目地址: https://gitcode.com/GitHub_Trending/go/gods-eye-viewdocs/PERFORMANCE.md记录的是 Gods Eye View一个在浏览器中运行、以真实数据驱动的摄影级 3D 实况地球应用在Apple M5 硬件渲染 Chrome 150这一固定环境下的一次完整性能基线捕获。本文以该文档为主体逐表解读启动、冷图层激活、探测/Cockpit、视觉样式与关键实时数据源的压力测试结果并结合仓库中的 渲染调度器实现、回归门禁脚本 与 探测渲染需求策略 等源码说明这份基线背后用什么机制控制渲染成本、如何防止性能回退让读者既能读懂这份基线也能在自己的机器上复现同样的测量流程。这份文档是什么、不是什么文档开篇就划定了自己的边界这一点必须原样理解它只记录一次捕获2026 年 8 月 22 日在 Chrome 150、1440 × 900 视口下对 Apple M5经硬件 ANGLE 路径调用 Metal采集的一组硬件渲染对比数据。它不是最低硬件规格也不能用来预测未测试系统的性能——换一个 GPU、换一种渲染器、换一个视口数字都会不同。原始捕获工件没有包含在仓库中所以这份页面记录的是结果baseline reference而不是一个可重复运行的基准程序。因此正确的使用方式是把它当作某一已知硬件与浏览器配置下的回归基线regression baseline而非兼容性保证。文档末尾的 Controls for a future capture 正是为未来在同条件下再捕获一次、与本次对比而写的操作清单。测试环境与捕获条件基线捕获时的受控条件如下SettingValueRendererApple M5 Metal through the hardware ANGLE pathBrowserChrome 150 in a fresh isolated profileViewport1440 x 900 at device pixel ratio 1FocusPage foregrounded for controlled scenesScene sample5 seconds of scripted motion, then 5 seconds at restStartupBrowser cache disabled; three samples捕获共覆盖3 次启动采样、16 个冷图层场景含 14 项测量、23 个受控选项与压力场景以及 5 个硬件渲染的叠加层场景。值得注意的细节是Page foregrounded页面处于前台聚焦与fresh isolated profile全新隔离浏览器配置——这两条与后面Keyed live sources一节形成对比后者所在的 pass 页面可见但未聚焦帧率因此不能与前台场景直接对比。设计上场景采样统一为脚本化运动 5 秒 静止 5 秒运动/静止帧率成对给出。启动性能基线三次采样与中位数启动环节在禁用浏览器缓存的前提下采样三次SampleApp readyInitial settleLoad eventMotion / restUsed JS heap1784.980 ms2,035.082 ms439.5 ms60 / 60 FPS102.9 MiB2604.849 ms1,855.836 ms442.4 ms60 / 60 FPS111.6 MiB3558.527 ms1,809.592 ms438.8 ms60 / 60 FPS105.1 MiBMedian604.849 ms1,855.836 ms439.5 ms60 / 60 FPS105.1 MiB文档给出的判读要点是Initial settle初始沉降是更有用的启动参考值因为它包含首次可见画面与数据沉降的完整窗口而 Load event439.5 ms只代表 DOM/资源加载事件不代表场景已可用。三次采样在运动与静止两个阶段都触达了 60 FPS 的显示上限中位数堆内存约 105 MiB。从源码看启动链路确实存在沉降后揭幕的设计应用启动编排位于 src/app/startupChrome.js它通过Promise.all([styleManager.initialRestorePromise, minimumDelay])同时等待样式/状态恢复完成与至少 1000 ms 的最短延迟再隐藏 loading 画面、等待过渡结束后才揭示首次运行引导——即欢迎界面不会早于首次可视画面和数据沉降窗口出现。此外 src/standalone/startupChrome.js 是独立入口下的对应实现两者契约一致。冷图层激活把激活耗时与堆内存作为主要区分维度冷激活cold layer activation与暖选项切换分开测量。由于各图层数据源的实时数量差异很大文档特意在表中记录了当前源数量Source count以便未来对比时先确认源种群规模一致再判断差异是否来自客户端LayerActivationSource countMotion / restUsed JS heapCCTV city19,608.240 ms4860 / 60 FPS192.7 MiBSpace Missions (report label: Rocket missions)3,581.066 ms2660 / 60 FPS131.3 MiBRadio3,458.709 ms75060 / 60 FPS124.8 MiBBikeshare2,069.498 ms63360 / 60 FPS157.4 MiBDatacenters817.693 ms4,36259.6 / 60 FPS328.2 MiBFlights667.671 ms24760 / 60 FPS118.4 MiBSubmarine cables614.727 ms2,62960 / 60 FPS412.0 MiBMilitary Flights557.113 ms6860 / 60 FPS118.4 MiB文档明确指出两个结论CCTV city 拥有本次捕获中最大的冷激活成本约 19.6 秒。这与 CCTV 图层的实现形态一致——src/data/cctv.js 及其子模块cctvGizmo.js、cctvViewshed.js、cctvFootprint.js 等需要为每路摄像头做地面放置、投影与视域计算且真实摄像机源分散在多个 pack 配置见 config/cctv_sources.austin.json 等文件中。Submarine cables 堆内存最大412.0 MiBDatacenters 次之328.2 MiB。这是因为它们属于本地 GeoJSON 全量数据集基础设施图层由 src/data/infrastructure.js 通过createLocalGeoJsonLayer加载 datacenters 与 dams 的 geojsonl 文件对应 src/data/local_data/ 下的数据而海底电缆数据源位于 src/layers/submarineCables/bundledSource.js。数千个实体物化后占据的堆内存自然显著高于点状实时源。另一个判读重点是完成的单图层采样普遍达到 60 FPS因此激活耗时与堆内存比稳态帧率更能区分各图层——帧率已经封顶无法再分出高下。航空、探测与 Cockpit探测密度是唯一压垮帧率的结构性因素这一组场景全部在前台受控条件下测量SceneMotion / restIdle globe60 / 60 FPSFlights, 2D60 / 60 FPSFlights, 3D proximity60 / 60 FPSFlights, all 3D models60 / 60 FPSMilitary Flights, all 3D models60 / 60 FPSDetection at 25%39.3 / 41.1 FPSDetection at 50%37.4 / 39.8 FPSDetection at 100%34.4 / 35.5 FPSCockpit49.6 / 49.2 FPS关键数据干净的探测场景处理了8,169 至 8,170 个观测对象选中标签数量随密度从 25% 的 14 个、50% 的 28 个上升到 100% 的 56 个帧率则从 39.3 一路滑到 34.4 FPS。这是全部受控场景中唯一无法维持 60 FPS 的持续负载Cockpit 的 49.6 FPS 属于视口叠加渲染成本。文档还注明航空相关行来自较早一次已加载、前台受控的 pass因为干净的复跑没有收到实时航班行。探测的渲染成本正是项目性能工作的重点治理对象。从 src/data/detectionRenderDemand.js 的源码注释可以看到探测叠加层不再持有持续渲染的 hold旧实现holdContinuousRender(detection)会在探测开启时永久锁定 60 FPS 渲染循环改为变化时重绘、跨帧工作只再请求一帧的按需模式并且把是否还需要下一帧收敛为纯函数detectionNeedsFollowUpFrame激活淡入窗口、标签淡入淡出、欠执行的标签求解三类有界工作——其设计原则是任何输入都必须能到达一个停止请求的状态防止任何谓词把旧的持续 hold 换个名字带回来。视觉样式与组合压力哪几种场景是优化工作的对照点SceneMotion / restNormal60 / 60 FPSCRT (report label: Retro)60 / 60 FPSNVG (report label: Surveillance)60 / 60 FPSFLIR (report label: Thermal)49 / 60 FPSAnime60 / 59.8 FPSNoir47 / 56.6 FPSSnow42.3 / 45.8 FPSCombined static57.6 / 60 FPSCombined operational39.9 / 43.1 FPS文档给出的组合场景细节很有价值Combined static渲染11,575 个对象JS 堆872.2 MiB运动阶段发出48,665 次文本绘制、静止阶段54,106 次。Combined operational包含3,909 个观测对象与 2 个选中标签但该样本的实时航班与交通行为空因此只能算受限的压力场景不能据此断言组合运行成本。结论Snow、Noir、高密度探测、文本密集的组合图层是后续优化工作最清晰的受控对比点。这些视觉样式的实现位于 src/styles/snow.js、noir.js、thermal.js、surveillance.js、anime.js、retro.js其中 Snow 与 Noir 属于持续的后处理/覆盖层成本ThermalFLIR在静止时也能回到 60 FPS说明其成本主要在运动阶段的粒子或采样上。Keyed live sources三种实时大数据的点时刻快照NASA FIRMS、AISStream 与 TomTom 在另一轮独立的硬件渲染 pass中捕获。关键限定是页面可见但并非聚焦窗口因此下面的帧率绝不能与上面的前台受控场景直接比较SourcePoint-in-time populationActivation or coverageMotion / restNASA FIRMS100,430 detections in 3,557 cells30.0 s activation32.1 / 55.2 FPSAISStream12,000 vessels6.4 s activation22.1 / 29.8 FPSTomTom Traffic4,222 road dots70% coverage, 2 decoded tiles45.0 / 51.7 FPS这些数据源的种群数量持续变化FIRMS 的火灾热点、AIS 的船舶、TomTom 的路况点都在不断更新因此文档明确要求未来的对比必须重新记录实时数量并匹配聚焦条件。对应实现分别位于 server/providers/firms.jsNASA FIRMS 代理前端解析在 src/data/firmsCsv.js、server/providers/vessels/AISStream 的 websocket/watchdog浏览器侧入口 src/data/aisLiveVessels.js与 server/providers/traffic.jsTomTom 流量瓦片前端在 src/data/tomtomTiles.js。30 秒的 FIRMS 激活耗时对应 10 万级探测点的抓取、解析与 3,557 个网格单元的物化——这是实时大数据源与本地数据集的本质区别。复现未来捕获的控制项原样清单在把任何性能差异归因于应用之前必须使用与本次相同的控制项记录确切的 GPU 渲染器字符串拒绝软件渲染或不可用的 GPU 字符串使用1440 × 900 视口、device pixel ratio 1并保持页面聚焦禁用缓存的启动与冷图层激活、暖选项切换分开测量启动重复三次比较中位数每个选项脚本化运动采样 5 秒 静止采样 5 秒先记录实时对象数量再把差异归因于客户端把实时源中断视为覆盖缺失而不是客户端渲染成本低的证据。这 7 条与文档Test context表的字段一一对应未来捕获时直接照此执行即可获得可对比的同类数据。尚未确立的内容不要越界解读文档明确列出了当前基线不能支撑的结论引用时务必保留这些限制不确立 Windows 平台的性能未记录机器内存容量因此不能支撑最低内存建议未覆盖其他 GPU 渲染器或视口配置Military Installations因需要近距离相机上下文不在此次对比内Keyed pass 没有可用于与选项场景对比的受控复跑。换言之这份页面只能回答Apple M5 Chrome 150 1440×900 前台受控这一种组合下的表现任何超出范围的推广都缺少证据。源码侧的性能护栏渲染调度器与回归门禁基线数字之外仓库里还有一套防止性能回退的机制理解它有助于读懂为什么基线里的 idle 场景能稳定在 60 FPS 上限、而旧版本做不到。render governor按需渲染而非永远 60 FPSsrc/renderGovernor.js 的头部注释解释了问题的根源Cesium 默认的渲染循环每个 vsync 都会重绘在零图层开启、相机停靠的情况下应用曾消耗约60% GPU 与 54% 单核。修复方案是把场景切入 Cesium 的requestRenderMode按需渲染连续模式requestRenderMode false只要存在任何一个 hold如航班插值、交通模拟、卫星运动、跟踪实体跟随、样式交叉淡化、CCTV 投影等逐帧动画器在场景监听器或动画的整个生命周期内注册 hold就保持空闲模式requestRenderMode true零 hold 时进入Cesium 只在相机输入与瓦片加载时自动渲染其余离散场景变更必须显式调用governorRequestRender()请求一帧。实现上有两个值得注意的工程决策hold 用身份键控的 Setowner id 集合而非计数器模块重复 hold/release 也不会破坏模式owner 是flights、traffic、style-anim这类短稳定字符串诊断输出可读性好getRenderGovernorDiagnostics()返回当前模式与 hold 列表。governor 本身是O(1) 被动的自身从不做任何逐帧工作因此不会成为新的性能负担。探测不再持有渲染循环正如探测与 Cockpit一节所述src/data/detectionRenderDemand.js 移除了探测的持续 hold。原因是探测默认开启2026-08-22后旧的实现会把每个空闲首次运行标签页钉在 60 FPS——这会直接击穿 render governor 的全部意义。现在探测重绘按变更、跨帧工作只再请求一帧且所有请求路径都必须能收敛到停止请求的状态。qa-perf用相对帧数断言锁住协议scripts/qa-perf.mjs 是 render governor 的回归门禁它刻意不用墙钟 GPU 数字而是用相对帧数断言SwiftShader 安全空闲 零图层 停靠相机 → 场景停止渲染沉降窗口内近零postRender空闲期间的离散变更经governorRequestRender的样式滑块写入→ 至少渲染一帧然后再次沉降空闲期间的相机移动 → 有渲染Cesium 原生路径启用 Flights → 连续模式postRender节奏 ≈ rAF 节奏且 ≥ 空闲计数的 5 倍关闭 Flights → 回到空闲近零触发每一步 governor 诊断与模式一致。脚本还专门处理了一个隐蔽的污染源HUD 语义摘要以 15 秒周期刷新HUD_SUMMARY_INTERVAL_MS禁用图层后会把摘要标记为脏下一次 tick 用打字机动画重排.hud-corner这个遮挡体从而产生若干帧——因此空闲判定要求连续空窗口长于一个完整刷新周期settleUntilQuiet避免把真的一直在渲染的失败场景误判为安静。跑法node scripts/qa-perf.mjs [--url http://localhost:4173]需要先启动开发服务器对应 package.json 中的npm run dev。相关性能主题的持续演进项目状态文档 docs/CURRENT-STATE.md 的performance waves 12条目进一步补充了整体性能治理的约定应用通过 render governor 实现空闲任何新的逐帧视觉动画必须注册 hold任何新的离散场景变更必须请求一帧并由qa-perf.mjs把关隐藏标签页会停止渲染循环scope 遮罩是显式 canvassrc/scopeMask.js其外部终点按海拔自适应重绘按 0.005 alpha 量化步进门控因此从 20 Mm 到地面的完整下降只产生 12 次 canvas 重绘、停靠相机则零成本。如何把这份基线用于日常回归结合上述所有内容把docs/PERFORMANCE.md用起来的标准流程是对照场景先确认目标机器的 GPU 渲染器字符串为硬件路径拒绝软件渲染视口设为 1440 × 900、DPR 1并保持页面前台聚焦分三类测量禁用缓存的启动3 次取中位数、冷图层激活、暖选项切换三者不要混在一起逐场景对比优先对比 Snow / Noir / 高密度探测 / 文本密集组合图层这几个文档点名的敏感场景记录源种群实时源FIRMS、AISStream、TomTom必须先记录当时的对象数量再谈客户端差异源中断按覆盖缺失处理配合自动化门禁本地改动后运行npm run test单元套件与node scripts/qa-perf.mjs --url app渲染治理门禁前者锁纯函数契约后者锁空闲必须真正空闲、动画必须真的连续的渲染协议。最后再次强调文档的自我定位这是特定硬件与浏览器配置下的回归基线不是兼容性保证。任何一篇引用这份数据的文章或报告都应同时引用其测试上下文与尚未确立清单才能避免把单一机器的数字误读为产品级性能声明。【免费下载链接】gods-eye-viewA spy satellite simulator in your browser, except the data is real. Live open source spatial intelligence on a photorealistic 3D globe.项目地址: https://gitcode.com/GitHub_Trending/go/gods-eye-view创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
God‘s Eye View 性能基线解读：3D 实况地球在 Apple M5 上的启动、图层激活与渲染预算实测
Gods Eye View 性能基线解读3D 实况地球在 Apple M5 上的启动、图层激活与渲染预算实测【免费下载链接】gods-eye-viewA spy satellite simulator in your browser, except the data is real. Live open source spatial intelligence on a photorealistic 3D globe.项目地址: https://gitcode.com/GitHub_Trending/go/gods-eye-viewdocs/PERFORMANCE.md记录的是 Gods Eye View一个在浏览器中运行、以真实数据驱动的摄影级 3D 实况地球应用在Apple M5 硬件渲染 Chrome 150这一固定环境下的一次完整性能基线捕获。本文以该文档为主体逐表解读启动、冷图层激活、探测/Cockpit、视觉样式与关键实时数据源的压力测试结果并结合仓库中的 渲染调度器实现、回归门禁脚本 与 探测渲染需求策略 等源码说明这份基线背后用什么机制控制渲染成本、如何防止性能回退让读者既能读懂这份基线也能在自己的机器上复现同样的测量流程。这份文档是什么、不是什么文档开篇就划定了自己的边界这一点必须原样理解它只记录一次捕获2026 年 8 月 22 日在 Chrome 150、1440 × 900 视口下对 Apple M5经硬件 ANGLE 路径调用 Metal采集的一组硬件渲染对比数据。它不是最低硬件规格也不能用来预测未测试系统的性能——换一个 GPU、换一种渲染器、换一个视口数字都会不同。原始捕获工件没有包含在仓库中所以这份页面记录的是结果baseline reference而不是一个可重复运行的基准程序。因此正确的使用方式是把它当作某一已知硬件与浏览器配置下的回归基线regression baseline而非兼容性保证。文档末尾的 Controls for a future capture 正是为未来在同条件下再捕获一次、与本次对比而写的操作清单。测试环境与捕获条件基线捕获时的受控条件如下SettingValueRendererApple M5 Metal through the hardware ANGLE pathBrowserChrome 150 in a fresh isolated profileViewport1440 x 900 at device pixel ratio 1FocusPage foregrounded for controlled scenesScene sample5 seconds of scripted motion, then 5 seconds at restStartupBrowser cache disabled; three samples捕获共覆盖3 次启动采样、16 个冷图层场景含 14 项测量、23 个受控选项与压力场景以及 5 个硬件渲染的叠加层场景。值得注意的细节是Page foregrounded页面处于前台聚焦与fresh isolated profile全新隔离浏览器配置——这两条与后面Keyed live sources一节形成对比后者所在的 pass 页面可见但未聚焦帧率因此不能与前台场景直接对比。设计上场景采样统一为脚本化运动 5 秒 静止 5 秒运动/静止帧率成对给出。启动性能基线三次采样与中位数启动环节在禁用浏览器缓存的前提下采样三次SampleApp readyInitial settleLoad eventMotion / restUsed JS heap1784.980 ms2,035.082 ms439.5 ms60 / 60 FPS102.9 MiB2604.849 ms1,855.836 ms442.4 ms60 / 60 FPS111.6 MiB3558.527 ms1,809.592 ms438.8 ms60 / 60 FPS105.1 MiBMedian604.849 ms1,855.836 ms439.5 ms60 / 60 FPS105.1 MiB文档给出的判读要点是Initial settle初始沉降是更有用的启动参考值因为它包含首次可见画面与数据沉降的完整窗口而 Load event439.5 ms只代表 DOM/资源加载事件不代表场景已可用。三次采样在运动与静止两个阶段都触达了 60 FPS 的显示上限中位数堆内存约 105 MiB。从源码看启动链路确实存在沉降后揭幕的设计应用启动编排位于 src/app/startupChrome.js它通过Promise.all([styleManager.initialRestorePromise, minimumDelay])同时等待样式/状态恢复完成与至少 1000 ms 的最短延迟再隐藏 loading 画面、等待过渡结束后才揭示首次运行引导——即欢迎界面不会早于首次可视画面和数据沉降窗口出现。此外 src/standalone/startupChrome.js 是独立入口下的对应实现两者契约一致。冷图层激活把激活耗时与堆内存作为主要区分维度冷激活cold layer activation与暖选项切换分开测量。由于各图层数据源的实时数量差异很大文档特意在表中记录了当前源数量Source count以便未来对比时先确认源种群规模一致再判断差异是否来自客户端LayerActivationSource countMotion / restUsed JS heapCCTV city19,608.240 ms4860 / 60 FPS192.7 MiBSpace Missions (report label: Rocket missions)3,581.066 ms2660 / 60 FPS131.3 MiBRadio3,458.709 ms75060 / 60 FPS124.8 MiBBikeshare2,069.498 ms63360 / 60 FPS157.4 MiBDatacenters817.693 ms4,36259.6 / 60 FPS328.2 MiBFlights667.671 ms24760 / 60 FPS118.4 MiBSubmarine cables614.727 ms2,62960 / 60 FPS412.0 MiBMilitary Flights557.113 ms6860 / 60 FPS118.4 MiB文档明确指出两个结论CCTV city 拥有本次捕获中最大的冷激活成本约 19.6 秒。这与 CCTV 图层的实现形态一致——src/data/cctv.js 及其子模块cctvGizmo.js、cctvViewshed.js、cctvFootprint.js 等需要为每路摄像头做地面放置、投影与视域计算且真实摄像机源分散在多个 pack 配置见 config/cctv_sources.austin.json 等文件中。Submarine cables 堆内存最大412.0 MiBDatacenters 次之328.2 MiB。这是因为它们属于本地 GeoJSON 全量数据集基础设施图层由 src/data/infrastructure.js 通过createLocalGeoJsonLayer加载 datacenters 与 dams 的 geojsonl 文件对应 src/data/local_data/ 下的数据而海底电缆数据源位于 src/layers/submarineCables/bundledSource.js。数千个实体物化后占据的堆内存自然显著高于点状实时源。另一个判读重点是完成的单图层采样普遍达到 60 FPS因此激活耗时与堆内存比稳态帧率更能区分各图层——帧率已经封顶无法再分出高下。航空、探测与 Cockpit探测密度是唯一压垮帧率的结构性因素这一组场景全部在前台受控条件下测量SceneMotion / restIdle globe60 / 60 FPSFlights, 2D60 / 60 FPSFlights, 3D proximity60 / 60 FPSFlights, all 3D models60 / 60 FPSMilitary Flights, all 3D models60 / 60 FPSDetection at 25%39.3 / 41.1 FPSDetection at 50%37.4 / 39.8 FPSDetection at 100%34.4 / 35.5 FPSCockpit49.6 / 49.2 FPS关键数据干净的探测场景处理了8,169 至 8,170 个观测对象选中标签数量随密度从 25% 的 14 个、50% 的 28 个上升到 100% 的 56 个帧率则从 39.3 一路滑到 34.4 FPS。这是全部受控场景中唯一无法维持 60 FPS 的持续负载Cockpit 的 49.6 FPS 属于视口叠加渲染成本。文档还注明航空相关行来自较早一次已加载、前台受控的 pass因为干净的复跑没有收到实时航班行。探测的渲染成本正是项目性能工作的重点治理对象。从 src/data/detectionRenderDemand.js 的源码注释可以看到探测叠加层不再持有持续渲染的 hold旧实现holdContinuousRender(detection)会在探测开启时永久锁定 60 FPS 渲染循环改为变化时重绘、跨帧工作只再请求一帧的按需模式并且把是否还需要下一帧收敛为纯函数detectionNeedsFollowUpFrame激活淡入窗口、标签淡入淡出、欠执行的标签求解三类有界工作——其设计原则是任何输入都必须能到达一个停止请求的状态防止任何谓词把旧的持续 hold 换个名字带回来。视觉样式与组合压力哪几种场景是优化工作的对照点SceneMotion / restNormal60 / 60 FPSCRT (report label: Retro)60 / 60 FPSNVG (report label: Surveillance)60 / 60 FPSFLIR (report label: Thermal)49 / 60 FPSAnime60 / 59.8 FPSNoir47 / 56.6 FPSSnow42.3 / 45.8 FPSCombined static57.6 / 60 FPSCombined operational39.9 / 43.1 FPS文档给出的组合场景细节很有价值Combined static渲染11,575 个对象JS 堆872.2 MiB运动阶段发出48,665 次文本绘制、静止阶段54,106 次。Combined operational包含3,909 个观测对象与 2 个选中标签但该样本的实时航班与交通行为空因此只能算受限的压力场景不能据此断言组合运行成本。结论Snow、Noir、高密度探测、文本密集的组合图层是后续优化工作最清晰的受控对比点。这些视觉样式的实现位于 src/styles/snow.js、noir.js、thermal.js、surveillance.js、anime.js、retro.js其中 Snow 与 Noir 属于持续的后处理/覆盖层成本ThermalFLIR在静止时也能回到 60 FPS说明其成本主要在运动阶段的粒子或采样上。Keyed live sources三种实时大数据的点时刻快照NASA FIRMS、AISStream 与 TomTom 在另一轮独立的硬件渲染 pass中捕获。关键限定是页面可见但并非聚焦窗口因此下面的帧率绝不能与上面的前台受控场景直接比较SourcePoint-in-time populationActivation or coverageMotion / restNASA FIRMS100,430 detections in 3,557 cells30.0 s activation32.1 / 55.2 FPSAISStream12,000 vessels6.4 s activation22.1 / 29.8 FPSTomTom Traffic4,222 road dots70% coverage, 2 decoded tiles45.0 / 51.7 FPS这些数据源的种群数量持续变化FIRMS 的火灾热点、AIS 的船舶、TomTom 的路况点都在不断更新因此文档明确要求未来的对比必须重新记录实时数量并匹配聚焦条件。对应实现分别位于 server/providers/firms.jsNASA FIRMS 代理前端解析在 src/data/firmsCsv.js、server/providers/vessels/AISStream 的 websocket/watchdog浏览器侧入口 src/data/aisLiveVessels.js与 server/providers/traffic.jsTomTom 流量瓦片前端在 src/data/tomtomTiles.js。30 秒的 FIRMS 激活耗时对应 10 万级探测点的抓取、解析与 3,557 个网格单元的物化——这是实时大数据源与本地数据集的本质区别。复现未来捕获的控制项原样清单在把任何性能差异归因于应用之前必须使用与本次相同的控制项记录确切的 GPU 渲染器字符串拒绝软件渲染或不可用的 GPU 字符串使用1440 × 900 视口、device pixel ratio 1并保持页面聚焦禁用缓存的启动与冷图层激活、暖选项切换分开测量启动重复三次比较中位数每个选项脚本化运动采样 5 秒 静止采样 5 秒先记录实时对象数量再把差异归因于客户端把实时源中断视为覆盖缺失而不是客户端渲染成本低的证据。这 7 条与文档Test context表的字段一一对应未来捕获时直接照此执行即可获得可对比的同类数据。尚未确立的内容不要越界解读文档明确列出了当前基线不能支撑的结论引用时务必保留这些限制不确立 Windows 平台的性能未记录机器内存容量因此不能支撑最低内存建议未覆盖其他 GPU 渲染器或视口配置Military Installations因需要近距离相机上下文不在此次对比内Keyed pass 没有可用于与选项场景对比的受控复跑。换言之这份页面只能回答Apple M5 Chrome 150 1440×900 前台受控这一种组合下的表现任何超出范围的推广都缺少证据。源码侧的性能护栏渲染调度器与回归门禁基线数字之外仓库里还有一套防止性能回退的机制理解它有助于读懂为什么基线里的 idle 场景能稳定在 60 FPS 上限、而旧版本做不到。render governor按需渲染而非永远 60 FPSsrc/renderGovernor.js 的头部注释解释了问题的根源Cesium 默认的渲染循环每个 vsync 都会重绘在零图层开启、相机停靠的情况下应用曾消耗约60% GPU 与 54% 单核。修复方案是把场景切入 Cesium 的requestRenderMode按需渲染连续模式requestRenderMode false只要存在任何一个 hold如航班插值、交通模拟、卫星运动、跟踪实体跟随、样式交叉淡化、CCTV 投影等逐帧动画器在场景监听器或动画的整个生命周期内注册 hold就保持空闲模式requestRenderMode true零 hold 时进入Cesium 只在相机输入与瓦片加载时自动渲染其余离散场景变更必须显式调用governorRequestRender()请求一帧。实现上有两个值得注意的工程决策hold 用身份键控的 Setowner id 集合而非计数器模块重复 hold/release 也不会破坏模式owner 是flights、traffic、style-anim这类短稳定字符串诊断输出可读性好getRenderGovernorDiagnostics()返回当前模式与 hold 列表。governor 本身是O(1) 被动的自身从不做任何逐帧工作因此不会成为新的性能负担。探测不再持有渲染循环正如探测与 Cockpit一节所述src/data/detectionRenderDemand.js 移除了探测的持续 hold。原因是探测默认开启2026-08-22后旧的实现会把每个空闲首次运行标签页钉在 60 FPS——这会直接击穿 render governor 的全部意义。现在探测重绘按变更、跨帧工作只再请求一帧且所有请求路径都必须能收敛到停止请求的状态。qa-perf用相对帧数断言锁住协议scripts/qa-perf.mjs 是 render governor 的回归门禁它刻意不用墙钟 GPU 数字而是用相对帧数断言SwiftShader 安全空闲 零图层 停靠相机 → 场景停止渲染沉降窗口内近零postRender空闲期间的离散变更经governorRequestRender的样式滑块写入→ 至少渲染一帧然后再次沉降空闲期间的相机移动 → 有渲染Cesium 原生路径启用 Flights → 连续模式postRender节奏 ≈ rAF 节奏且 ≥ 空闲计数的 5 倍关闭 Flights → 回到空闲近零触发每一步 governor 诊断与模式一致。脚本还专门处理了一个隐蔽的污染源HUD 语义摘要以 15 秒周期刷新HUD_SUMMARY_INTERVAL_MS禁用图层后会把摘要标记为脏下一次 tick 用打字机动画重排.hud-corner这个遮挡体从而产生若干帧——因此空闲判定要求连续空窗口长于一个完整刷新周期settleUntilQuiet避免把真的一直在渲染的失败场景误判为安静。跑法node scripts/qa-perf.mjs [--url http://localhost:4173]需要先启动开发服务器对应 package.json 中的npm run dev。相关性能主题的持续演进项目状态文档 docs/CURRENT-STATE.md 的performance waves 12条目进一步补充了整体性能治理的约定应用通过 render governor 实现空闲任何新的逐帧视觉动画必须注册 hold任何新的离散场景变更必须请求一帧并由qa-perf.mjs把关隐藏标签页会停止渲染循环scope 遮罩是显式 canvassrc/scopeMask.js其外部终点按海拔自适应重绘按 0.005 alpha 量化步进门控因此从 20 Mm 到地面的完整下降只产生 12 次 canvas 重绘、停靠相机则零成本。如何把这份基线用于日常回归结合上述所有内容把docs/PERFORMANCE.md用起来的标准流程是对照场景先确认目标机器的 GPU 渲染器字符串为硬件路径拒绝软件渲染视口设为 1440 × 900、DPR 1并保持页面前台聚焦分三类测量禁用缓存的启动3 次取中位数、冷图层激活、暖选项切换三者不要混在一起逐场景对比优先对比 Snow / Noir / 高密度探测 / 文本密集组合图层这几个文档点名的敏感场景记录源种群实时源FIRMS、AISStream、TomTom必须先记录当时的对象数量再谈客户端差异源中断按覆盖缺失处理配合自动化门禁本地改动后运行npm run test单元套件与node scripts/qa-perf.mjs --url app渲染治理门禁前者锁纯函数契约后者锁空闲必须真正空闲、动画必须真的连续的渲染协议。最后再次强调文档的自我定位这是特定硬件与浏览器配置下的回归基线不是兼容性保证。任何一篇引用这份数据的文章或报告都应同时引用其测试上下文与尚未确立清单才能避免把单一机器的数字误读为产品级性能声明。【免费下载链接】gods-eye-viewA spy satellite simulator in your browser, except the data is real. Live open source spatial intelligence on a photorealistic 3D globe.项目地址: https://gitcode.com/GitHub_Trending/go/gods-eye-view创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考