On Wed, Jul 17, 2013 at 1:43 PM, K. Gadd <kg@luminance.org> wrote: > It should be quite easy to test the performance benefits of the racy > version of the API, as based on my understanding the Firefox implementation > currently makes copies. > Because we implement what I proposed in the message which started this thread --- http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0644.html --- my guess is that we avoid almost all copying related to AudioBuffers, in practice. From feedback on the list, it sounds like the copies related to AudioParam.setValueCurveAtTime and WaveShaperNode.curve are most likely to be a problem in our implementation --- if there is a problem. And yes, it's extremely important to keep in mind that we're only talking about the performance of legacy content here. Introducing a notion of immutable audio buffer should make it easy to write new content with no copying overhead and no potential races. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Received on Wednesday, 17 July 2013 02:09:24 UTC