- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 20 Mar 2012 14:59:39 -0700
- To: Gordon Williams <gw@pur3.co.uk>
- Cc: public-webapps@w3.org
On Tue, Mar 20, 2012 at 11:03 AM, Gordon Williams <gw@pur3.co.uk> wrote: > Thanks for the suggestions... > > Just so I'm certain: The #3 option is to run in a Worker, and then to put > all WebGL calls in an array, and then use the UI thread to check that array > and execute calls based on its contents? > > There is a small amount of state querying of WebGL going on, so that's > probably going to stall quite badly in my case, but it's definitely a > solution. I suppose if this is going to be the accepted way forwards, > somebody could write a library that transparently passed WebGL calls from a > worker into the UI thread, and the transition might be relatively painless. Long term we've talked about exposing WebGL to workers. That way you could query the data that you need directly, and avoid having to send messages to the main thread in order to render things with WebGL. But it'll likely take a while before we get there. / Jonas
Received on Tuesday, 20 March 2012 22:00:45 UTC