W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Counterproposal for canvas in workers

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 17 Oct 2013 14:51:52 -0700
Message-ID: <CAGN7qDCE9iEcFWTjTusP=g6aOQ2CcYnWRPP=cdFfrBGt8rWxPQ@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
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@zewt.org> wrote:

> 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:52:18 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC