W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Tue, 20 Mar 2012 20:28:26 +0200
Message-ID: <4F68CC4A.9020009@helsinki.fi>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT