Re: [whatwg] Counterproposal for canvas in workers

On Wed, Oct 16, 2013 at 9:34 PM, Rik Cabanier <cabanier@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
> requested).
> 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 all
> 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@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. In
> theory, this should be compatible.
>

All of that happens inside the OpenGL driver, which browsers have no
control over.

-- 
Glenn Maynard

Received on Thursday, 17 October 2013 21:48:39 UTC