- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Fri, 13 Sep 2013 23:52:00 +0300
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: Jer Noble <jer.noble@apple.com>, Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAJhzemV2wopUGOZ4L=Kghiynskyk-Drp5AoXt138v_rMNhb2Og@mail.gmail.com>
On Fri, Sep 13, 2013 at 11:32 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Fri, Sep 13, 2013 at 1:31 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> On Fri, Sep 13, 2013 at 1:26 PM, Jussi Kalliokoski < >> jussi.kalliokoski@gmail.com> wrote: >> >>> I don't really care about using disconnect as pause, it's not meant for >>> that and it's not a good solution for that. What I care about is what the >>> use case / justification for having this weirdness is? A nice-to-have (not >>> sure this is even a nice-to-have) doesn't really warrant introducing hard >>> to debug memory leaks. I believe a lot of developers will expect that if >>> they disconnect a ScriptProcessorNode and lose references to it, it gets >>> GCed and doesn't burn cycles and / or eat away the performance of the graph >>> anymore. This is similar to disconnecting a DOM node from the graph. If it >>> has no references, it gets garbage collected and no more events are fired. >>> >> >> That's not true for DOM nodes in general. For example, a completely >> disconnected HTML media element that's playing some media resource >> continues to fire events. >> > > I also think it would be bizarre for a developer to connect some audio > node subgraph to the input of a ScriptProcessorNode for analysis, but not > get events unless the output of that ScriptProcessorNode is connected to > the DestinationNode. > While I do acknowledge that it is tedious to have to connect analyzer nodes to the DestinationNode (IIRC I was one of the people pushing for AnalyzerNode to not have this requirement), I don't think alleviating that pain point (that can be solved by, well, connecting to the DestinationNode) is worth the cost. On the other end there's the tediousness of a ScriptProcessorNode your module got from another module and you don't know how to make sure it gets garbage collected. I see that as a much bigger pain point. Cheers, Jussi > 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 Friday, 13 September 2013 20:52:26 UTC