- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Tue, 20 Mar 2012 20:28:26 +0200
- To: Gordon Williams <gw@pur3.co.uk>
- CC: public-webapps@w3.org
I think we should try to get rid of sync XHR in window context. It takes time, and can be painful, but sync APIs in window context are just not acceptable. -Olli On 03/20/2012 08:03 PM, Gordon Williams 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. > > I totally understand about the need to deter people from using the UI > thread, however it seems that while synchronous XHR exists at all, > deliberately removing features in some cases just makes developers lives > more difficult - and may force them into the synchronous JSON option - > which can't be good for anybody. > > - Gordon > > On 20/03/12 17:07, Jarred Nicholls wrote: >> On Tue, Mar 20, 2012 at 12:09 PM, Gordon Williams <gw@pur3.co.uk >> <mailto:gw@pur3.co.uk>> wrote: >> >> Hi, >> >> I recently posted on >> https://bugs.webkit.org/show_bug.cgi?id=72154 >> https://bugzilla.mozilla.org/show_bug.cgi?id=716765 >> about the change to XHR which now appears to be working its way >> into Mainstream users' browsers. >> >> As requested, I'll pursue on this list - apologies for the earlier >> bug spam. >> >> My issue is that I have WebGL JavaScript that is machine-generated >> from a binary file - which is itself synchronous. It was working fine: >> >> http://www.morphyre.com/scenedesign/go >> >> It now fails on Firefox (and shortly on Chrome I imagine) because >> it can't get an ArrayBuffer from a synchronous request. It may be >> possible to split the execution and make it asynchronous, however >> this is a very large undertaking as you may get an idea of from >> looking at the source. >> >> My understanding is that JavaScript Workers won't be able to >> access WebGL, so I am unable to just run the code as a worker. >> >> What options do I have here? >> >> * Extensive rewrite to try and automatically translate the code to >> be asynchronous >> * Use normal Synchronous XHR and send the data I require in text >> form, then turn it back into an ArrayBuffer with JavaScript >> >> Are there any other options? >> >> Right now, #2 is looking like the only sensible option - which is >> a shame as it will drastically decrease the UX. >> >> - Gordon >> >> >> >> #1 is the best option long term. All web platform APIs in the window >> context - going forward - are asynchronous and this isn't going to be >> the last time someone runs into this issue. >> >> #2 is a reasonable stop gap; and assuming things like large textures >> are being downloaded, the text -> preallocated TypedArray copy will be >> shadowed by the wait for large I/O to complete from a remote source. >> >> I believe there is a #3, which is a hybrid of sync APIs, Workers, and >> message posting. You can use a worker to perform these sync >> operations and post data back to the main UI thread where an event >> loop/handler runs and has access to the WebGL context. Firefox 6+ and >> Chrome 13+ have support for the structured cloning...there's overhead >> involved but it works and might be an easier translation than creating >> async JS. Chrome 17+ has transferable objects, so data passing is >> wicked fast. >> >> Jarred >
Received on Tuesday, 20 March 2012 18:29:00 UTC