- From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Date: Wed, 20 Mar 2013 07:21:01 +0200
- To: robert@ocallahan.org
- Cc: Srikumar Subramanian <srikumarks@gmail.com>, Peter van der Noord <peterdunord@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAJhzemWwnHAe6XE6CKbT2z3UAni08tJgfM6W-kyzdcpSbunikw@mail.gmail.com>
On Wed, Mar 20, 2013 at 5:28 AM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Wed, Mar 20, 2013 at 8:33 AM, Jussi Kalliokoski < > jussi.kalliokoski@gmail.com> wrote: > >> Actually this reminds me... Is this actually a bug by the spec? I don't >> think the current spec has any special rules for the ScriptProcessorNode >> GC, so following the AudioNode garbage collection information in the spec, >> it looks like ScriptProcessorNodes shouldn't be kept around if there aren't >> any references to them. > > > Is it time to discuss the GC rules in the spec? > > Now that we've implemented most of the relevant infrastructure, I'm more > convinced than ever that the spec shouldn't say anything about GC. UAs can > and should automatically prune out nodes that can't contribute to future > output. Nothing needs to be said in the spec about how and when this is > done. These optimizations should have no observable effects. > > Rob Shouldn't we say that ("UAs can and should automatically prune out nodes that can't contribute to future output"), at least? To make sure nodes that can contribute don't get dropped out? Now for example WebKit's "bug" doesn't really seem to be a bug by the spec, which has proven to be counter-intuitive for web developers that are used to creating locally scoped DOM elements (nodes) that are added (connected) to the tree (context), assigning listeners to them and assuming they stay where you put them, even though you don't have a direct reference to them. Of course, unlike DOM, we don't have introspection that would let you find the node you had earlier, but I don't think that's a very good thing either. Obviously, this lifetime issue is only relevant for the ScriptProcessorNode that is a source but doesn't have the start/stop(or run out of data) terminology, other nodes' lifetime seems fairly simple to understand and implement. Cheers, Jussi > > -- > Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur > Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl > bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat > lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir > — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb > tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28] >
Received on Wednesday, 20 March 2013 05:21:28 UTC