[whatwg] Counterproposal for canvas in workers

Glenn Maynard glenn at zewt.org
Thu Oct 17 15:01:10 PDT 2013

On Thu, Oct 17, 2013 at 4:50 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> It seemed like that proposal was harder. Synchronization with the main
drawing thread seemed and the continuous committing seemed difficult too.

Have implementors said that synchronizing the flip is (unreasonably) hard
to implement?  (I'm not an implementor, but this proposal feels
unimplementable to me, or at least catastrophically difficult for WebGL.
 Compositors are often already threaded, so synchronizing a buffer flip
with the compositor doesn't seem too far out there.)

> In addition, Ken wanted multiple workers access the same canvas which I
> didn't see addressed (unless I missed it).

I don't remember "multiple workers accessing the same canvas" and I'm not
quite sure what it means.  I do remember "a single (WebGL) context
rendering to multiple canvases".  Is that what you're thinking of?

On Thu, Oct 17, 2013 at 4:51 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> Thanks Glenn!
> With that info, will there ever be a way to use WebGL in different workers
> but going to the same webgl context?

Sorry, which use case is this for?  I'm not sure why you'd want to do that,
and it sounds like it would expose thread-safety issues to the platform.
 (I'm not sure if you mean the same thing here and above--they sound
similar, but you said "canvas" in one place and "WebGL context" in the

(Sorry if I'm forgetting things, the subject has been busy and a little bit

Glenn Maynard

More information about the whatwg mailing list