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

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.


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 <
>> <>> wrote:
>>     Hi,
>>     I recently posted on
>>     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:
>>     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