- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 17 Oct 2013 14:51:52 -0700
- 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