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 <[email protected]
<mailto:[email protected]>> 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
