- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Fri, 13 Sep 2013 23:26:15 +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: <CAJhzemWaWJS-kWthnXPqx3rZU6QNeKWffMN6tgs8vtKSET1cTQ@mail.gmail.com>
On Fri, Sep 13, 2013 at 10:47 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Fri, Sep 13, 2013 at 8:39 AM, Jer Noble <jer.noble@apple.com> wrote: > >> I’m going to have to take up the mantle of Chris and disagree with you >> strongly here. Disconnected nodes are disassociated from the graph >> entirely. They do not participate in rendering to the destination node, >> and they no longer are connected to the destination node’s timeline. >> > > OK, but that's not what the spec currently says and adding that behavior > to the spec is a large change. So this discussion should really be framed > as a proposal to make this change to the spec. As such, it would be helpful > to see the proposed change written down in more detail. > > Philosophically speaking, disconnected nodes are collected by GC because >> they are no longer active. But if disconnected nodes continue to "play", we >> would either be GCing active objects, or not GCing disconnected objects, >> effectively leaking nodes with no end time. Neither of which are good >> options. >> > > In most cases, the ongoing playback of disconnected nodes is not > observable, and therefore they can be safely destroyed even though they're > active. > > >> Practically speaking, disconnecting a sub-graph is the only way deleopers >> can "pause" playback. If we force disconnected nodes to continue playing, >> the only way to pause playback would be to entirely tear down and re-create >> a subgraph. >> > > I agree with Chris Wilson; if we're going to support pausing, let's > support it properly with a pause/resume API. > 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. Cheers, Jussi > Pausing a MediaStream/ElementAudioSourceNode is not a problem. You just > drop data from the input stream while paused. > > 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:26:42 UTC