频谱监测 WebGL2 原型性能结果

第一轮可运行基线 · 2026-08-04

📋 测试环境

本轮测试用于验证实现正确性、指标链路和不同负载之间的相对变化，不代表真实显卡最终性能。

项目	环境
操作系统	macOS
浏览器	Playwright Chromium Headless
WebGL 后端	ANGLE SwiftShader 软件渲染
桌面视口	1440 × 900
移动视口	390 × 844
数据源	Dedicated Worker 模拟 Uint8 强度帧
渲染器	单 WebGL2 Context + R8 texture2DArray

⚠️ 环境限制： Playwright 默认无头 Chromium 未提供 WebGL2。测试通过 --use-angle=swiftshader 启用软件 WebGL2，因此 GPU 时间和 FPS 只能作为保守基线。真实硬件 GPU 需要在本地 Chrome、Edge 或 Safari 中重新记录。

🔬 模拟负载模型

模拟器定位为“接收端已经解码、校准后的频谱强度帧”，而不是原始 IQ 采样或浏览器内 FFT。这样能独立测量数据传递、纹理上传、曲线和瀑布渲染能力，不会把 DSP 计算混入前端展示指标。

已模拟内容

特征	实现
噪声统计	近似 FFT 单频点功率分布，不使用均匀随机抖动
接收通带	边缘衰减、固定纹波、频段校准偏差
时间特征	噪声逐帧变化、噪声底慢漂移、信号慢衰落
窄带信号	固定载波和近似高斯频谱裙边
宽带信号	平顶占用带宽、滚降边沿和带内功率纹理
动态信号	突发、跳频和线性扫频
可重复性	固定随机种子，时间由帧序号和刷新率确定
场景配置	安静频段、混合业务、密集信号、突发/跳频

信号数量按总频宽（GHz）和场景密度计算，信号占用带宽、跳频步进与扫频范围先以 MHz 定义，再映射到 FFT bin。因而把同一总频宽切成 1、32 或 64 个显示窗口不会改变物理信号集合；窗口数与每窗口 FFT 点数只改变总数据点数和渲染负载。

噪声底参数表示完成 RBW、窗函数、接收机噪声系数和校准后的“每 FFT bin dBm”，不是 -174 dBm/Hz 热噪声密度。正式接入时应直接采用设备上报值。

未模拟内容

原始 IQ 采样率、ADC 量化和 IQ 不平衡
FFT 窗函数旁瓣的精确数学响应
RBW/VBW、检波器模式和平均算法
AGC、前端压缩、互调、镜像和杂散
WebSocket/TCP 协议开销及服务端排队

因此，当前“强度流”指标是 窗口数 × FFT 点数 × 更新频率 × 8 bit，代表 Worker 输出到渲染器的数据量。若真实协议使用 Int16 或 Float32，网络带宽分别约为该值的 2 倍或 4 倍，但在 Worker 归一化为 Uint8 后，GPU 上传负载仍与当前测试一致。

📊 测试结果

场景	FPS	接收	吞吐	CPU 上传	CPU 提交	GPU	延迟	纹理
移动轻载：4 × 1024 × 30 Hz，96 行	60	29.5 Hz	0.97 Mb/s	0.00 ms	0.10 ms	1.80 ms	2 ms	0.4 MiB
桌面基准：32 × 1024 × 30 Hz，96 行	25	31.0 Hz	8.12 Mb/s	0.10 ms	0.10 ms	13.77 ms	17 ms	3.0 MiB
桌面高载：64 × 4096 × 20 Hz，128 行	5	20.3 Hz	42.62 Mb/s	0.30 ms	0.30 ms	59.82 ms	19 ms	32.3 MiB

改进信号模型后补充复测：

场景	FPS	接收	强度流	CPU 上传	CPU 提交	GPU	延迟	纹理
混合业务：32 × 1024 × 30 Hz，96 行	24	31.0 Hz	8.13 Mb/s	0.00 ms	0.20 ms	7.78 ms	11 ms	3.0 MiB
密集信号：64 × 4096 × 20 Hz，128 行	10	19.4 Hz	40.59 Mb/s	0.20 ms	0.20 ms	39.53 ms	49 ms	32.3 MiB

丢弃帧统计为应用负载以来的累计值，包含页面启动和配置切换阶段，不能直接比较不同测试时长。它的主要用途是判断最新帧策略是否正在主动控制延迟。

💡 结果分析

数据通路达到目标频率

三个场景的数据接收率均接近配置值。64 路场景约 42.6 Mb/s，与 64 × 4096 × 20 × 8 bit 的理论强度数据量一致，说明 Worker、可转移 ArrayBuffer 和主线程接收链路可以承载该测试规模。

GPU 填充成为高负载瓶颈

CPU 上传和绘制命令提交均低于 0.5 ms，但软件 GPU 时间从轻载的 1.8 ms 增长到高载的约 59.8 ms。瓶颈主要来自 64 个窗口、2936 像素画布高度和瀑布区域填充，而不是 JavaScript 绘制循环。

响应式布局通过基础验证

390 像素移动视口下页面水平溢出为 0，控制项自动换行，四个窗口使用单列布局。桌面 32 路使用四列布局，曲线、阈值、瀑布、标签和框选区域未出现重叠。

✅ 已验证功能

Worker 按窗口数、FFT 点数和刷新率生成数据
ArrayBuffer 回收池与最新帧覆盖策略
运行时重建 R8 texture2DArray
单 Canvas 绘制 1 至 64 个频率窗口
当前曲线、GPU 环形瀑布和阈值超限着色
矩形框选与频率/dBm 结果换算
FPS、接收率、吞吐、CPU、GPU、延迟、内存和丢帧指标
配置切换版本隔离，旧尺寸帧不会进入新纹理
WebGL2 不可用时显示明确错误状态

🔍 下一轮建议

在目标部署设备的硬件 Chrome/Edge 上记录同一测试矩阵
增加固定画布高度模式，区分“同时绘制所有窗口”和“只绘制可见窗口”
为 4096/8192 点曲线增加屏幕空间 min/max LOD 对照测试
连续运行 30 分钟记录 JS Heap、GPU 纹理和丢帧变化
若硬件 GPU 在 32 路基准下仍无法稳定 60 FPS，再评估按脏帧绘制、降低 DPR 或可见区域裁剪

最后更新：2026-08-04

5.9 KiB Raw Blame History Unescape Escape