如何低CPU高效将原始RGB图像帧实时传输渲染到HTML页面

基础场景说明 #

• 数据源：Python端持有1000×1000分辨率、单像素3字节的原始RGB图像数据，要求20fps帧率实时推送到HTML页面展示，原始无压缩数据带宽需求为57MB/s。
• 已踩坑方案：此前测试multipart/x-mixed-replace推流方案，搭配BMP、PNG、JPG编码时服务端CPU占用过高，目前已实现通过二进制XHR请求在JS端直接获取原始图像二进制数据。
• 核心问题：如何以极低CPU开销，将XHR返回的二进制RGB数据解码渲染到<video>、<img>或<canvas>元素上。

当前已实现的XHR请求代码如下：

oReq = new XMLHttpRequest();
oReq.open("GET", "/imagedata", true);
oReq.responseType = "arraybuffer";
oReq.onload = function (oEvent) {
  var arrayBuffer = oReq.response;
  if (arrayBuffer) {
    var byteArray = new Uint8Array(arrayBuffer);
    // 在此处编写图像更新逻辑
  }
};
oReq.send(null);

已测试方案的现存问题 #

已验证如下基础渲染逻辑可正常出图：

var byteArray = new Uint8ClampedArray(arrayBuffer); 
var imgData = new ImageData(byteArray, 1000, 1000); 
var ctx = myCanvas.getContext('2d'); 
ctx.putImageData(imgData, 0, 0);

该方案的实际表现：

• 优势：服务端发送数据CPU占用仅5%-6%，远低于此前BMP/PNG/JPG编码方案8%-20%的CPU占用
• 缺陷：
  1. Chromium会启动两个并行进程处理渲染任务，单进程CPU占用约15%，整体性能提升有限
  2. 原生ImageData接口不支持直接传入n×n×3字节的三通道RGB数组，必须传入1000×1000×4字节的RGBA四通道数据，额外传输Alpha通道会带来33%的带宽冗余，没有官方参数可以跳过Alpha通道要求，强行传入3通道数据会出现像素行错位、颜色错乱问题
• 深层瓶颈：同设备业务进程与Chrome进程之间的XHR HTTP请求最高需承载100MB/s传输量，HTTP回环的协议栈开销、多次内存拷贝是当前最主要的性能卡点，需要更轻量的进程间通信机制。

可落地的低开销优化方案 #

渲染层优化（可直接降低浏览器侧CPU占用） #

• 避免重复创建渲染对象：初始化阶段提前创建固定尺寸的ImageData实例、对应的Uint8ClampedArray内存视图、Canvas上下文，每帧只更新数组内的像素值后调用putImageData，不要每帧重新实例化对象，可减少GC开销30%以上。
• 低开销RGB转RGBA：不要在传输层携带Alpha通道数据，在JS侧用Uint32Array映射预分配的RGBA数组，批量写入固定Alpha值0xFF000000，逐行拷贝RGB数据，效率比逐字节循环填充高4-5倍，可省掉33%的传输带宽。
• 用WebGL替代2D Canvas渲染：将拿到的RGB数据直接上传为WebGL 2D纹理，上传时指定纹理格式为RGB，不需要手动补Alpha通道，通过GPU完成最终绘制，CPU占用比2D Canvas的putImageData低40%以上，完全规避Chromium多进程CPU占用过高的问题。

传输层优化（解决进程间通信带宽瓶颈） #

• 替换XHR为流式传输：用Fetch API的ReadableStream接口建立长连接持续接收帧数据，替代逐帧请求-响应的XHR模式，省去每帧HTTP请求头、连接建立的开销，延迟可降低50%。
• 本地IPC替代HTTP回环：
  • 本地场景优先用Chrome Native Messaging机制，直接和本地Python/C++进程通信，跳过HTTP协议栈处理，减少2次以上内存拷贝
  • 配置COOP/COEP响应头启用SharedArrayBuffer能力后，可通过共享内存方式传递帧数据，实现接近直接内存访问的传输效率，完全省去进程间数据拷贝开销
  • 次选本地回环WebRTC DataChannel传输二进制数据，比HTTP回环延迟低60%，支持批量帧传输。

编码层折中优化（端到端开销最低） #

如果可以接受极小编码开销，优先用SIMD优化的JPEG编码（如OpenCV编译时开启SIMD支持）实现MJPEG流推送，1000×1000分辨率20fps下服务端编码CPU占用不超过3%，浏览器侧JPEG解码走硬件加速，CPU占用比处理原始RGB数据低70%，整体带宽占用仅为原始RGB的15%-20%，端到端总开销远低于传输原始RGB数据的方案。

内容的提问来源于stack exchange，提问作者Basj