On Sep 12, 2013, at 11:27 AM, K. Gadd <kg@luminance.org> wrote: > So essentially I think I'm asking for the Web Audio version of a given API to be as expressive and symmetric as the C version would be, where reasonable. This seems like a good opportunity, since it's speccing a new API that basically just exposes two special variants of memcpy. > > (That's also why I'm okay with a version that is just one buffer and an offset, since everything else can be expressed via a view, if you ignore the performance consequences) FWIW, JSC has been doing a lot of work lately to ensure that the performance implications of creating a new TypedArrayView are as minimal as possible. See: https://lists.webkit.org/pipermail/webkit-dev/2013-August/025267.html https://bugs.webkit.org/show_bug.cgi?id=119064 So in this case, I’d argue that matching the semantics of TypedArrayViews (which devs will have to be familiar with just to use this API) is more important than baking subtle performance improvements into the spec. (And in my ideal world, we would use TypedArrayView semantics literally. I.e., float32View.set(audioBuffer.channel[0]). But that’s for another day. ;-) ) -Jer
Received on Thursday, 12 September 2013 18:49:49 UTC