OpenScreen 渲染性能基准预览流畅度与导出速度的实测数据与设计取舍【免费下载链接】openscreenRecord your screen, ship a demo. Free and open-source, GPU-accelerated, no watermarks, no subscriptions. Windows, macOS, Linux. Actively maintained.项目地址: https://gitcode.com/gh_mirrors/opens/openscreenOpenScreen 是一款免费开源的 GPU 加速屏幕录制与视频编辑器Windows / macOS / Linux无水印、无订阅。本文用项目内置的基准测试记录实测它的两大核心指标——预览流畅度与导出速度在一台刻意挑选的最弱集成显卡笔记本上1080p60 全特效预览可达~126 fps各效果层的价格表、CPU 回退后端的取舍以及一套很难造假的测量纪律。测试环境为什么挑一台最弱的笔记本所有数字都来自同一台参考机AMD Ryzen 5 7520U 笔记本 核显 Radeon GPU Windows 11——团队刻意选择最差的场景作为唯一完整测量机器这样最弱机都能跑动的结论才最有说服力。完整记录见 technical-documentation/engineering/rendering-performance.md。⚠️ 一个例外macOS 导出路径在 Mac mini M1 上单独测量Metal VideoToolbox 管线两组数字互不可比可迁移的只有测量方法本身。预览流畅度实测1080p60 全特效约 126 fps当前产品采用的渲染路径是 crates/compositor/ 中的D3D11 原生合成器整条管线只有一个ID3D11Device阶段之间零 CPU 回读demux → D3D11VA 解码×2GPU 纹理→ HLSL 合成 → RGB→NV12 → h264_amf 编码GPU→GPU→ MP4 封装这个帧率数字包住整个流程——解码、合成、编码、封装全在内测得是 1080p60、全部效果开启动态布局、缩放、圆角蒙版、SDF 投影、Kawase 背景模糊、速度运动模糊、自定义光标带点击弹跳的持续运行帧率渲染路径fps 1080p60 全特效状态D3D11 原生合成器~126中位数 125.9✅ 已发布WebCodecsChromium 内79已移除从未发布Rust wgpu / Vulkan48–68被 AMD 驱动挡住否决也就是说在核显上预览渲染速度是 60 fps 实时线的两倍以上——拖动时间轴、加特效时画面跟手不卡顿。效果价格表三层收费其余免费基准工具 crates/x.bat 提供 C0–C8 九个累加式配置每档多开一层效果相邻两行差值即该层的单价定义见 crates/compositor/src/config.rs。一次完整通过门禁的运行结果配置新增效果fps每帧耗时该层代价C0解码 编码无合成236.54.23 ms—C1 背景、布局、双源142.57.02 ms2.79 msC2 圆角141.47.07 ms0.05 msC3 投影134.57.43 ms0.36 msC4 背景模糊121.98.21 ms0.77 msC5 动态缩放123.28.12 ms持平C6 布局动画125.47.97 ms持平C7 自定义光标127.37.86 ms持平C8 运动模糊8 采样104.09.62 ms1.76 ms结论很干净真正花钱的只有三层——开始做合成C0→C1、背景模糊、运动模糊圆角和投影几乎免费因为它们画在已经存在的渲染通道里。缩放、布局动画、光标落在一条噪声平台带上基本不花帧率。瓶颈在哪编码封顶 ~210 fpsWindows 的 GPU 引擎计数器给出了约束画像轻量配置受编码限制视频编码引擎 ~71% 占用重型配置受合成限制3D 引擎 ~84%解码从不构成瓶颈~2 ms突发式AMD VCN 硬编码器是 ~210 fps 的硬天花板重型配置下唯一可优化的面就是合成器GPU 自己已经跨帧并行了管线3D 与编码引擎同时忙84% 61% 100%CPU 侧再叠一条流水线毫无收益导出速度实测数据是怎么花的macOS 侧的记录更能说明导出到底慢在哪。用OPENSCREEN_EXPORT_PROFILE1给 60 秒 1080p60 全特效导出做分阶段剖析改一处解码策略前后阶段改动前改动后屏幕解码decode.screen13.130 s46.9%1.024 s编码提交enc.send_frame0.283 s1.0%7.717 s41.3%端到端相对 ffmpeg 底线1.819×1.296×输出逐字节一致关键发现VideoToolbox 硬解码在 M1 上反而是慢路径——同素材下软解 2586 fps vs 硬解 212 fps12.2× 差距且 4K 更惨71 fps低于 4K60 实时线。因此导出改走软件解码代价CPU 占用 8.4 → 29.8 CPU 秒对等用户等批导出的场景是正确取舍。改完之后导出被编码器封顶单独编码 15.8 s整条导出管线在这个硬件上不可能快过它——这不是优化没做够是物理上限。管线细节见 technical-documentation/architecture/export-pipeline.md。没有独立显卡怎么办CPU 后端的取舍渲染与解码是两根独立轴。对没有可用 D3D11 GPU 的机器项目提供Backend::Cpu同一套管线跑在 WARP 软渲染 软解码上crates/compositor/src/cpu_frames_windows.rs配置GPU fpsWARP fps差距C165.330.72.1×C363.128.52.2×C4背景模糊49.19.15.4×C8运动模糊48.06.27.7×规律清晰WARP 不是均匀地慢它只在逐像素采样循环上崩——背景模糊在 WARP 上多花 75 ms/帧GPU 上只多 4.5 ms。C1–C3 约 30 fps 是可用的剪辑预览C4 以后就不能看了。而渲染结果与 GPU 路径几乎逐位一致93–95% 通道比特相同最大偏差 3/255所以换后端不会换画面——这正是值得做双后端的原因。这些数字凭什么可信防作弊的测量纪律这份记录最有价值的部分可能是它记录的测量事故详见文档中 Measurement hazards 一节异步 GPU API 是最大的坑调用画帧函数时 GPU 还没画计时器会测到 ~0 ms成本转移到别的阶段——同一堵墙曾先后伪装成编码等 90%、回读 32 秒、下行 38.9 ms/帧三种假象首次导出要付着色器编译、JIT 的学费9.3 s vs 后续 5.6 s每个分支先跑一轮热身再丢弃波动才收敛到 2–4%同臂波动超过 10% 的运行直接宣布作废——曾有一轮在 ~40 个浏览器进程在线下波动 42.5%且C3 比 C2 还快 15.8 fps累加配置不可能越加越快是噪声淹没信号的经典样本跨机器只迁移比值不迁移绝对值同一台笔记本同一项目跨会话测出过 44.0 / 36.8 / 32.3 / 31.8 / 22.2 / 11.9 fps 六个数稳定的测量不等于真实的测量硬件编码器输出不逐字节可复现比较改用剥离 SEI 后的码流哈希与解码像素哈希复测入口就在 crates/x.bat例如x.bat run --release -- --cfg C0..C8 --fixture fixture --repeat 3基准实现见 crates/poc-d3d/src/bench.rs 与 crates/poc-d3d/src/bench.rs 同目录的 POC。GIF 导出则由手写纯 Rust 的 GIF89a 写器承担crates/compositor/src/gif_export.rs无新依赖、无 GPL 引入。对普通用户意味着什么预览跟手最弱参考机上全特效 1080p60 预览 ~126 fps是实时线的 2 倍多预览与导出走同一个原生合成器见 technical-documentation/architecture/preview.md所见即所得是一个渲染器的属性不是两个引擎对齐的纪律导出远超实时瓶颈明确——轻配置顶到编码器天花板重配置顶到合成器而不是含糊的综合原因无独显也能用CPU 后端保住基础效果下的可用预览画质与 GPU 路径一致数字可复核基准、门禁、作废记录全部开源在仓库里任何人可在自己机器上重跑一句话总结这份取舍先花大代价确认墙在合成器而不在编码器再把整条管线搬进 GPU 并让帧率数字包住全流程——于是 1080p60 的流畅预览和接近实时的导出在最差的硬件上也成了默认体验。【免费下载链接】openscreenRecord your screen, ship a demo. Free and open-source, GPU-accelerated, no watermarks, no subscriptions. Windows, macOS, Linux. Actively maintained.项目地址: https://gitcode.com/gh_mirrors/opens/openscreen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenScreen 渲染性能基准：预览流畅度与导出速度的实测数据与设计取舍
OpenScreen 渲染性能基准预览流畅度与导出速度的实测数据与设计取舍【免费下载链接】openscreenRecord your screen, ship a demo. Free and open-source, GPU-accelerated, no watermarks, no subscriptions. Windows, macOS, Linux. Actively maintained.项目地址: https://gitcode.com/gh_mirrors/opens/openscreenOpenScreen 是一款免费开源的 GPU 加速屏幕录制与视频编辑器Windows / macOS / Linux无水印、无订阅。本文用项目内置的基准测试记录实测它的两大核心指标——预览流畅度与导出速度在一台刻意挑选的最弱集成显卡笔记本上1080p60 全特效预览可达~126 fps各效果层的价格表、CPU 回退后端的取舍以及一套很难造假的测量纪律。测试环境为什么挑一台最弱的笔记本所有数字都来自同一台参考机AMD Ryzen 5 7520U 笔记本 核显 Radeon GPU Windows 11——团队刻意选择最差的场景作为唯一完整测量机器这样最弱机都能跑动的结论才最有说服力。完整记录见 technical-documentation/engineering/rendering-performance.md。⚠️ 一个例外macOS 导出路径在 Mac mini M1 上单独测量Metal VideoToolbox 管线两组数字互不可比可迁移的只有测量方法本身。预览流畅度实测1080p60 全特效约 126 fps当前产品采用的渲染路径是 crates/compositor/ 中的D3D11 原生合成器整条管线只有一个ID3D11Device阶段之间零 CPU 回读demux → D3D11VA 解码×2GPU 纹理→ HLSL 合成 → RGB→NV12 → h264_amf 编码GPU→GPU→ MP4 封装这个帧率数字包住整个流程——解码、合成、编码、封装全在内测得是 1080p60、全部效果开启动态布局、缩放、圆角蒙版、SDF 投影、Kawase 背景模糊、速度运动模糊、自定义光标带点击弹跳的持续运行帧率渲染路径fps 1080p60 全特效状态D3D11 原生合成器~126中位数 125.9✅ 已发布WebCodecsChromium 内79已移除从未发布Rust wgpu / Vulkan48–68被 AMD 驱动挡住否决也就是说在核显上预览渲染速度是 60 fps 实时线的两倍以上——拖动时间轴、加特效时画面跟手不卡顿。效果价格表三层收费其余免费基准工具 crates/x.bat 提供 C0–C8 九个累加式配置每档多开一层效果相邻两行差值即该层的单价定义见 crates/compositor/src/config.rs。一次完整通过门禁的运行结果配置新增效果fps每帧耗时该层代价C0解码 编码无合成236.54.23 ms—C1 背景、布局、双源142.57.02 ms2.79 msC2 圆角141.47.07 ms0.05 msC3 投影134.57.43 ms0.36 msC4 背景模糊121.98.21 ms0.77 msC5 动态缩放123.28.12 ms持平C6 布局动画125.47.97 ms持平C7 自定义光标127.37.86 ms持平C8 运动模糊8 采样104.09.62 ms1.76 ms结论很干净真正花钱的只有三层——开始做合成C0→C1、背景模糊、运动模糊圆角和投影几乎免费因为它们画在已经存在的渲染通道里。缩放、布局动画、光标落在一条噪声平台带上基本不花帧率。瓶颈在哪编码封顶 ~210 fpsWindows 的 GPU 引擎计数器给出了约束画像轻量配置受编码限制视频编码引擎 ~71% 占用重型配置受合成限制3D 引擎 ~84%解码从不构成瓶颈~2 ms突发式AMD VCN 硬编码器是 ~210 fps 的硬天花板重型配置下唯一可优化的面就是合成器GPU 自己已经跨帧并行了管线3D 与编码引擎同时忙84% 61% 100%CPU 侧再叠一条流水线毫无收益导出速度实测数据是怎么花的macOS 侧的记录更能说明导出到底慢在哪。用OPENSCREEN_EXPORT_PROFILE1给 60 秒 1080p60 全特效导出做分阶段剖析改一处解码策略前后阶段改动前改动后屏幕解码decode.screen13.130 s46.9%1.024 s编码提交enc.send_frame0.283 s1.0%7.717 s41.3%端到端相对 ffmpeg 底线1.819×1.296×输出逐字节一致关键发现VideoToolbox 硬解码在 M1 上反而是慢路径——同素材下软解 2586 fps vs 硬解 212 fps12.2× 差距且 4K 更惨71 fps低于 4K60 实时线。因此导出改走软件解码代价CPU 占用 8.4 → 29.8 CPU 秒对等用户等批导出的场景是正确取舍。改完之后导出被编码器封顶单独编码 15.8 s整条导出管线在这个硬件上不可能快过它——这不是优化没做够是物理上限。管线细节见 technical-documentation/architecture/export-pipeline.md。没有独立显卡怎么办CPU 后端的取舍渲染与解码是两根独立轴。对没有可用 D3D11 GPU 的机器项目提供Backend::Cpu同一套管线跑在 WARP 软渲染 软解码上crates/compositor/src/cpu_frames_windows.rs配置GPU fpsWARP fps差距C165.330.72.1×C363.128.52.2×C4背景模糊49.19.15.4×C8运动模糊48.06.27.7×规律清晰WARP 不是均匀地慢它只在逐像素采样循环上崩——背景模糊在 WARP 上多花 75 ms/帧GPU 上只多 4.5 ms。C1–C3 约 30 fps 是可用的剪辑预览C4 以后就不能看了。而渲染结果与 GPU 路径几乎逐位一致93–95% 通道比特相同最大偏差 3/255所以换后端不会换画面——这正是值得做双后端的原因。这些数字凭什么可信防作弊的测量纪律这份记录最有价值的部分可能是它记录的测量事故详见文档中 Measurement hazards 一节异步 GPU API 是最大的坑调用画帧函数时 GPU 还没画计时器会测到 ~0 ms成本转移到别的阶段——同一堵墙曾先后伪装成编码等 90%、回读 32 秒、下行 38.9 ms/帧三种假象首次导出要付着色器编译、JIT 的学费9.3 s vs 后续 5.6 s每个分支先跑一轮热身再丢弃波动才收敛到 2–4%同臂波动超过 10% 的运行直接宣布作废——曾有一轮在 ~40 个浏览器进程在线下波动 42.5%且C3 比 C2 还快 15.8 fps累加配置不可能越加越快是噪声淹没信号的经典样本跨机器只迁移比值不迁移绝对值同一台笔记本同一项目跨会话测出过 44.0 / 36.8 / 32.3 / 31.8 / 22.2 / 11.9 fps 六个数稳定的测量不等于真实的测量硬件编码器输出不逐字节可复现比较改用剥离 SEI 后的码流哈希与解码像素哈希复测入口就在 crates/x.bat例如x.bat run --release -- --cfg C0..C8 --fixture fixture --repeat 3基准实现见 crates/poc-d3d/src/bench.rs 与 crates/poc-d3d/src/bench.rs 同目录的 POC。GIF 导出则由手写纯 Rust 的 GIF89a 写器承担crates/compositor/src/gif_export.rs无新依赖、无 GPL 引入。对普通用户意味着什么预览跟手最弱参考机上全特效 1080p60 预览 ~126 fps是实时线的 2 倍多预览与导出走同一个原生合成器见 technical-documentation/architecture/preview.md所见即所得是一个渲染器的属性不是两个引擎对齐的纪律导出远超实时瓶颈明确——轻配置顶到编码器天花板重配置顶到合成器而不是含糊的综合原因无独显也能用CPU 后端保住基础效果下的可用预览画质与 GPU 路径一致数字可复核基准、门禁、作废记录全部开源在仓库里任何人可在自己机器上重跑一句话总结这份取舍先花大代价确认墙在合成器而不在编码器再把整条管线搬进 GPU 并让帧率数字包住全流程——于是 1080p60 的流畅预览和接近实时的导出在最差的硬件上也成了默认体验。【免费下载链接】openscreenRecord your screen, ship a demo. Free and open-source, GPU-accelerated, no watermarks, no subscriptions. Windows, macOS, Linux. Actively maintained.项目地址: https://gitcode.com/gh_mirrors/opens/openscreen创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考