[whatwg] Counterproposal for canvas in workers

Rik Cabanier cabanier at gmail.com
Thu Oct 17 14:51:52 PDT 2013


Thanks Glenn!
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
>> 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 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.
>> In
>> 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 mailing list