[whatwg] Counterproposal for canvas in workers
cabanier at gmail.com
Thu Oct 17 14:51:52 PDT 2013
With that info, will there ever be a way to use WebGL in different workers
but going to the same webgl context?
On Thu, Oct 17, 2013 at 2:48 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Wed, Oct 16, 2013 at 9:34 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>> When drawing to canvas, Chrome stores the drawing commands in a buffer and
> executes them when the main function returns (or access to pixel data is
>> It occurred to me that this could be re-purposed for canvas workers. A
>> worker could create a list of drawing commands and if the worker is done,
>> this list is executed either on the main thread or the worker or a
>> compositor thread depending on what your architecture supports.
>> The worker would not be allowed to read pixels or resize the canvas but
>> other operations would be allowed.
> This sounds like it serializes setting up the queue, and actually drawing
> the queue. OpenGL doesn't do that: it starts sending drawing commands to
> the GPU as soon as you make them, so the CPU can be setting up rendering of
> the same scene while the GPU is rendering earlier commands. It only needs
> to buffer if you send commands faster than the GPU can process them (the
> specific details of this are internal driver magic, but that's the gist).
> Waiting until all rendering commands have been called before starting to
> render would be catastrophic for performance, since it would prevent
> parallelism between the CPU and GPU.
> On Thu, Oct 17, 2013 at 3:35 PM, Rik Cabanier <cabanier at gmail.com> wrote:
> I'm unsure how this would work for WebGL since I'm not all that familiar
> with its architecture. However, it seems that the end result of a webgl
>> application, is a series of commands that are sent to the graphics chip.
>> theory, this should be compatible.
> All of that happens inside the OpenGL driver, which browsers have no
> control over.
> Glenn Maynard
More information about the whatwg