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

Re: Behavior of source nodes on connect/disconnect

From: Jer Noble <jer.noble@apple.com>
Date: Fri, 13 Sep 2013 13:50:53 -0700
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, "public-audio@w3.org" <public-audio@w3.org>
Message-id: <8B6E9A12-D027-4A68-B313-C36AE57BACC8@apple.com>
To: Robert O'Callahan <robert@ocallahan.org>

On 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.

Of course, HTMLMediaElements must pause when they are removed from the DOM.  So in the general case, disconnecting a playing media element and throwing away all references to it will allow it to be GCd.


Received on Friday, 13 September 2013 20:51:21 UTC

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