W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: New proposal for fixing race conditions

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Tue, 30 Jul 2013 19:05:24 +0300
Message-ID: <CAJhzemU+1mi+84jXB-WvzgYja10Uw9-iM7kV8fS1GScA2ohOeQ@mail.gmail.com>
To: Jer Noble <jer.noble@apple.com>
Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, "Robert O'Callahan" <robert@ocallahan.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, WG <public-audio@w3.org>
On Tue, Jul 30, 2013 at 6:52 PM, Jer Noble <jer.noble@apple.com> wrote:

> On Jul 30, 2013, at 8:47 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
> Does this impose a performance cost on Float32Array access, BTW? I tried
> figuring it out on my own but I've been following leads in the WebKit
> source for a while and haven't found the code that does this.
> We re-used the high-order bit in ArrayBufferView's offset to track
> non-neuterableness.  So yes, in that offset calculations now need to mask
> off that bit, but the cost is negligable.
> See:
> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/ArrayBufferView.h#L134
> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/ArrayBuffer.cpp#L36

Thanks! So, correct me if I'm wrong, but we're discussing imposing a
performance cost (arguably negligible) to Typed Arrays use to avoid
imposing a performance cost (arguably negligible) on the Web Audio API. To
be honest, (probably unsurprisingly) I'd rather we take risks like this in
our own API instead of on an API that's the foundation of high performance
JS. We can add more surface to our API to make it faster if need be, but if
we impose performance costs to the basic use of Typed Arrays, that's
irreversible and damages the whole platform.


> -Jer
Received on Tuesday, 30 July 2013 16:05:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC