Closed
Bug 1191648
Opened 10 years ago
Closed 10 years ago
don't keep ScriptProcessorNodes alive when they have no audioprocess listeners
Categories
(Core :: Web Audio, defect)
Tracking
()
RESOLVED
FIXED
mozilla43
People
(Reporter: karlt, Assigned: karlt)
Details
Attachments
(3 files)
|
3.78 KB,
patch
|
padenot
:
review+
|
Details | Diff | Splinter Review |
|
275 bytes,
text/html
|
Details | |
|
5.37 KB,
patch
|
padenot
:
review+
|
Details | Diff | Splinter Review |
There is no need to keep unreferenced ScriptProcessorNodes to dispatch audioprocess events if there are no listeners.
| Assignee | ||
Comment 1•10 years ago
|
||
Attachment #8644194 -
Flags: review?(padenot)
| Assignee | ||
Comment 2•10 years ago
|
||
With this testcase, the initial patch is not sufficient.
| Assignee | ||
Comment 3•10 years ago
|
||
Creating the event added a reference to the ScriptProcessorNode, which isn't
released until the AudioProcessingEvent is destroyed in
nsCycleCollector::FreeSnowWhite().
If another event is dispatched before cycle collection considers the
ScriptProcessorNode, then the node will not be collected.
Also, the reference count of the ScriptProcessorNode is no longer toggled
because this seemed to interfere with the cycle collection process.
Without the reference count change, ScriptProcessorNodes from attachment
8645547 were eventually collected in opt builds but not debug builds, so I
suspect timing was involved. In a debug build, forcing a complete CC from
about:memory would collect the nodes, but this would not happen during regular
CC. I'm guessing perhaps related to the multi-stage nature of the CC process
needing to restart each time the refcount is toggled.
Attachment #8645548 -
Flags: review?(padenot)
Updated•10 years ago
|
Attachment #8644194 -
Flags: review?(padenot) → review+
Updated•10 years ago
|
Attachment #8645548 -
Flags: review?(padenot) → review+
Comment 5•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/131c6f3f88d1
https://hg.mozilla.org/mozilla-central/rev/da775fa17639
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox43:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
| Assignee | ||
Updated•10 years ago
|
Flags: in-testsuite+
Comment 7•10 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•