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: Jarred Nicholls <jarred@webkit.org>
Date: Tue, 20 Mar 2012 13:07:50 -0400
Message-ID: <CANufG2N9=Eb5jG0Nz6W0T86G_p-mjbCT_Md0oPZTkpX=cVLRVg@mail.gmail.com>
To: public-webapps@w3.org
On Tue, Mar 20, 2012 at 12:09 PM, Gordon Williams <gw@pur3.co.uk> wrote:

> Hi,
> I recently posted on
> https://bugs.webkit.org/show_**bug.cgi?id=72154<https://bugs.webkit.org/show_bug.cgi?id=72154>
> https://bugzilla.mozilla.org/**show_bug.cgi?id=716765<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<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.

Received on Tuesday, 20 March 2012 17:08:42 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:39 UTC