能，但必须切断所有主线程依赖，且 WebGL 上下文初始化、资源加载、像素读取都得在 Worker 内闭环完成；否则一碰 getImageData 或 document 就退化回主线程卡死。
能，但必须切断所有主线程依赖，且 WebGL 上下文初始化、资源加载、像素读取都得在 Worker 内闭环完成；否则一碰 getImageData 或 document 就退化回主线程卡死。
OffscreenCanvas 创建后立刻绑定 WebGL 上下文
不能等 Worker 收到消息再创建上下文——那会多一次跨线程调用延迟，且部分浏览器（如 Safari 17+）对 Worker 中首次 getContext('webgl2') 有额外校验开销。直接在 Worker 入口同步初始化：
self.onmessage = (e) => {
if (e.data.type === 'init') {
const canvas = e.data.canvas;
// ✅ 必须立刻获取，不能延迟
const gl = canvas.getContext('webgl2', {
antialias: false,
stencil: false,
depth: true
});
if (!gl) throw new Error('WebGL2 not supported in Worker');
// 后续所有着色器编译、缓冲区分配、纹理上传都在此处进行
}
};
-
antialias: false能省掉多重采样解析（resolve）阶段，在高频渲染中减少 GPU 管线压力 - 避免传
alpha: true—— 若不需要透明混合，禁用 alpha 可跳过合成阶段的 premultiplied alpha 处理 - Safari 对
preserveDrawingBuffer: true在 Worker 中支持不稳定，一律设为false，用gl.readPixels+transferToImageBitmap替代截图
Worker 内加载纹理和着色器必须用 fetch + ArrayBuffer
Worker 没有 document，不能用 new Image() 或 XMLHttpRequest 同步加载；所有资源必须走 fetch 并手动解码：
async function loadTexture(gl, url) {
const res = await fetch(url);
const arrayBuffer = await res.arrayBuffer();
const blob = new Blob([arrayBuffer], { type: 'image/png' });
const bitmap = await createImageBitmap(blob); // ✅ Web Worker 支持
const texture = gl.createTexture();
gl.bindTexture(gl.TEXTURE_2D, texture);
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, bitmap);
gl.generateMipmap(gl.TEXTURE_2D);
return texture;
}
- 禁止在 Worker 中调用
URL.createObjectURL()或操作DOM节点，否则触发主线程同步回退 -
createImageBitmap是唯一安全的图像解码方式，HTMLImageElement在 Worker 中不可用 - 着色器 GLSL 源码建议内联或预编译为字符串，避免额外
fetch请求拖慢首帧
每帧提交前必须调用 gl.flush()，且禁用 requestAnimationFrame
Worker 中没有 requestAnimationFrame（它只存在于 window 全局），强行调用会报 ReferenceError；必须用 setTimeout 或 postMessage 主动节流，并确保 GPU 命令真正发出：
function renderLoop() {
// ... 绘制逻辑：bindBuffer、uniform、drawArrays ...
gl.drawArrays(gl.TRIANGLES, 0, vertexCount);
// ✅ 关键：强制 flush，否则命令可能滞留在驱动队列中
gl.flush();
// ✅ 用 setTimeout 控制帧率，例如稳定 60fps
setTimeout(renderLoop, 16.6);
}
- 不调用
gl.flush()时，Chrome/Edge 可能将多帧命令攒批提交，导致延迟突增；Firefox 则更激进，默认 flush，但行为不一致 - 不要依赖
gl.finish()—— 它会阻塞 Worker 线程等待 GPU 完成，彻底失去并发意义 - 若需精确帧同步（如对接 MediaStream），改用主线程通过
postMessage({type: 'tick'})推送时间戳，Worker 被动响应
主线程仅做 display 和事件代理，严禁任何 Canvas 操作
一旦调用 transferControlToOffscreen()，原始 <canvas> 元素就变成“空壳”：它的 getContext 返回 null，所有绘图 API 抛错，连 toDataURL() 都不可用。
const canvas = document.getElementById('viz');
const offscreen = canvas.transferControlToOffscreen(); // ⚠️ 执行后 canvas 废了
const worker = new Worker('render.js');
worker.postMessage({ type: 'init', canvas: offscreen }, [offscreen]);
- 后续所有 UI 交互（缩放、拖拽、选中）必须由主线程捕获，计算好参数后
postMessage给 Worker，不能在主线程里尝试读取 canvas 尺寸或样式 - 若需导出当前帧，Worker 必须用
gl.readPixels→new ImageBitmap()→postMessage(bitmap, [bitmap])，主线程用createObjectURL()显示或下载 - resize 处理必须双端协同：主线程监听
resize，发新尺寸给 Worker；Worker 改offscreen.width/height并重置 viewport，否则出现拉伸或裁剪错位
最常被忽略的一点：OffscreenCanvas 的 width 和 height 属性是可写的，但修改后不会自动清空帧缓冲区——你得手动调用 gl.clear()，否则上一帧残影会叠加在新尺寸画布上。这个细节在快速缩放或窗口自适应场景中几乎必现，却极少被文档强调。
