[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Asynchronous calls

On Thu, May 3, 2012 at 12:11 PM, Gregg Tavares (勤) <gman@google.com> wrote:
So if you want this to be async following your model you need that function to be called on another thread from another context. The model above gives the browser no clue that it needs to be called from another thread in another context until it's too late.

Like I said at the start,

> This is probably fairly complex to implement.  It may require running the underlying OpenGL/GLES context in its own thread (maybe they already do this; it seems like a good idea on its own).  I'm not sure about D3D. 

This would still serialize compilations; D3D-based implementations might not have that problem.

On Thu, May 3, 2012 at 12:49 PM, Gregg Tavares (勤) <gman@google.com> wrote:
Adding the ability to use WebGL from WebWorkers would arguably remove the need for many async calls because you can call the blocking calls from a worker and asynchronously notify the main page's JS the work is done.

I'm not saying that negates the need for some async APIs. But, I am saying it would be best to first get WebGL available in WebWorkers which would provide a generic solution to all these sync/async issues. Then later, decide which ones should have a specific API 

I agree that WebGL in workers is important, of course.  It would only actually help here if it's possible to render to a visible canvas, though; with the model of most Worker APIs, you'd only be able to render to an offscreen canvas.  Maybe disabling readback functions (toBlob and toDataURL) on HTMLCanvasElements being rendered in a different thread would be enough to fix the main problem (exposing asynchronous behavior to scripts).

I think everyone wants WebGL in workers, but nobody's really sure how to proceed, since it's hard to get HTMLImageElement in workers...

Glenn Maynard