Re: Recent Sync XHR changes and impact on automatically translated JavaScript code

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