我不明白网络工作人员是如何工作的...网络工作人员是并行的还是只是抢占的？
网络 worker 渲染到 webgl 上下文是否安全？
如果我只有一个渲染到 webgl 上下文的 web-worker，并且我的主“线程”也没有调用该worker，那么 web-worker 渲染到 webgl 上下文是否安全？
最佳答案
创建 Web Worker 时，您为其提供一个指向 JavaScript 文件的 URI。它在新的操作系统级线程中加载该 JavaScript 文件。您无法控制与特定核心或线程优先级的关联性(截至撰写本文时)，但创建的底层线程是真实且不受约束的。默认情况下，在 Web Worker 线程中运行的 JavaScript 无法访问 DOM:您无权访问窗口对象或任何与 DOM 相关的类。
Web Worker 线程的语义使其几乎完全脱离默认 DOM 线程。首先有趣的是，Web Worker 可以在 100% CPU 使用率的无限循环中运行，而不用担心卡住 UI。这意味着可怕的“警告:无响应脚本”消息框无法由 Web Worker 触发!
脱离的代价是您在 DOM 和工作线程之间同步和通信的能力受到限制。 Worker 和 DOM 之间的显式管道是用于发送数据的 postMessage() API 和用于接收事件的 onmessage 事件。您可以使用字符串和对象发布消息，其中数据从源线程的堆克隆到目标线程的堆中。 onmessage 事件仅由您的 Web Worker 在空闲时接收。这意味着，为了将 onmessage 事件从 DOM 及时传递到您的 Web Worker，worker 必须频繁产生；这可能会给您编写代码的方式带来麻烦。
重要的是要理解，在现代 JavaScript 实现中有一类特殊的“可转移对象”，您发送到 postMessage() 的对象不会被克隆，而是对象的所有权从一个线程转移到另一个线程。这些是您希望尽可能发送到 postMessage() 的数据类型；任何时候调用 postMessage() 时克隆数据，都会产生大量需要 GC 的垃圾，并且系统性能将会受到影响。
可传输对象类型的集合一直在稳步增长，Mozilla 开发网络、WhatWG 和 W3C 是观看该领域规范研究的好地方。我什至无法告诉你现在可以在浏览器中跨线程传输的所有内容，但如果我给你一个全面的列表，它可能会在一年或更短的时间内过时。
关于您最初的问题，在 Firefox 44+ 上，您现在可以通过 HTMLCanvasElement#transferControlToOffscreen 函数将 Canvas 部分传输到 WebWorker。 TransferControlToOffscreen 创建一个 Transferable OffscreenCanvas 对象，您可以将消息传递给 Web Worker。在 Web Worker 上，您可以获取 webgl CanvasContext 并从工作线程向 Canvas 发出绘图命令，而无需直接访问仍然与 DOM 线程一起存在的实际 Canvas 标记的 DOM。
https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/transferControlToOffscreen
https://hacks.mozilla.org/2016/01/webgl-off-the-main-thread/
关于javascript - Web Worker 可以在 WebGL-Canvas 上渲染吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9116896/