[whatwg] Counterproposal for canvas in workers

[Glenn Maynard]

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
other.)

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

-- 
Glenn Maynard