The distinction between moz_malloc/moz_free and malloc/free is not
interesting. We are inconsistent in our use of one or the other, and
I wouldn't be surprised if we are mixing them anyways.
- Relevant spec text:
- http://webaudio.github.io/web-audio-api/#widl-AudioContext-suspend-Promise
- http://webaudio.github.io/web-audio-api/#widl-AudioContext-resume-Promise
- http://webaudio.github.io/web-audio-api/#widl-AudioContext-close-Promise
- http://webaudio.github.io/web-audio-api/#widl-AudioContext-state
- http://webaudio.github.io/web-audio-api/#widl-AudioContext-onstatechange
- In a couple words, the behavior we want:
- Closed context cannot have new nodes created, but can do decodeAudioData,
and create buffers, and such.
- OfflineAudioContexts don't support those methods, transitions happen at
startRendering and at the end of processing. onstatechange is used to make
this observable.
- (regular) AudioContexts support those methods. The promises and
onstatechange should be resolved/called when the operation has actually
completed on the rendering thread. Once a context has been closed, it
cannot transition back to "running". An AudioContext switches to "running"
when the audio callback start running, this allow authors to know how long
the audio stack takes to start running.
- MediaStreams that feed in/go out of a suspended graph should respectively
not buffer at the graph input, and output silence
- suspended context should not be doing much on the CPU, and we should try
to pause audio streams if we can (this behaviour is the main reason we need
this in the first place, for saving battery on mobile, and CPU on all
platforms)
- Now, the implementation:
- AudioNodeStreams are now tagged with a context id, to be able to operate
on all the streams of a given AudioContext on the Graph thread without
having to go and lock everytime to touch the AudioContext. This happens in
the AudioNodeStream ctor. IDs are of course constant for the lifetime of the
node.
- When an AudioContext goes into suspended mode, streams for this
AudioContext are moved out of the mStreams array to a second array,
mSuspendedStreams. Streams in mSuspendedStream are not ordered, and are not
processed.
- The MSG will automatically switch to a SystemClockDriver when it finds
that there are no more AudioNodeStream/Stream with an audio track. This is
how pausing the audio subsystem and saving battery works. Subsequently, when
the MSG finds that there are only streams in mSuspendedStreams, it will go
to sleep (block on a monitor), so we save CPU, but it does not shut itself
down. This is mostly not a new behaviour (this is what the MSG does since
the refactoring), but is important to note.
- Promises are gripped (addref-ed) on the main thread, and then shepherd
down other threads and to the GraphDriver, if needed (sometimes we can
resolve them right away). They move between threads as void* to prevent
calling methods on them, as they are not thread safe. Then, the driver
executes the operation, and when it's done (initializing and closing audio
streams can take some time), we send the promise back to the main thread,
and resolve it, casting back to Promise* after asserting we're back on the
main thread. This way, we can send them back on the main thread once an
operation has complete (suspending an audio stream, starting it again on
resume(), etc.), without having to do bookkeeping between suspend calls and
their result. Promises are not thread safe, so we can't move them around
AddRef-ed.
- The stream destruction logic now takes into account that a stream can be
destroyed while not being in mStreams.
- A graph can now switch GraphDriver twice or more per iteration, for
example if an author goes suspend()/resume()/suspend() in the same script.
- Some operation have to be done on suspended stream, so we now use double
for-loop around mSuspendedStreams and mStreams in some places in
MediaStreamGraph.cpp.
- A tricky part was making sure everything worked at AudioContext
boundaries. TrackUnionStream that have one of their input stream suspended
append null ticks instead.
- The graph ordering algorithm had to be altered to not include suspended
streams.
- There are some edge cases (adding a stream on a suspended graph, calling
suspend/resume when a graph has just been close()d).
Currently when sending a beacon, HttpBaseChannel::ShouldIntercept tries
to get access to the nsINetworkInterceptController interface through the
channel's notification callbacks, but in this case the notification
callback is the nsCORSListenerProxy object (thanks to
nsCORSListenerProxy::Init).
nsCORSListenerProxy already knows how to forward calls to
nsIInterfaceRequestor::GetInterface to mOuterNotificationCallbacks, and
ShouldIntercept calls GetInterfce. But mOuterNotificationCallbacks is
set by default to the callbacks of the channel at the time
nsCORSListenerProxy is called, and the callbacks on this channel is
intentionally null, so ShouldIntercept bails out and the beacon never
gets intercepted.
This patch extends nsCORSListenerProxy to make it aware of
nsINetworkInterceptController, and have it route the request for
nsINetworkInterceptController correctly to the docshell without the need
to mess with the notification callbacks.
This will be tested in bug 1147699.
These methods will soon be used to start animations that are waiting to start
and also to finish pausing animations that are waiting to pause. As a result
we rename them to TriggerXXX since that's a bit more generic.
There are still references to StartXXX within PendingPlayerTracker. These will
be updated in a subsequent patch once we have the appropriate methods available
on AnimationPlayer to call.
Wes Kocher
Boris Zbarsky
Eddy Bruël
Carsten "Tomcat" Book
John Schoenick
Mike Hommey
Tom Schuster
Monica Chew
Jonathan Watt
Andrea Marchesini
Andrew McCreight
Chris Pearce
Bill McCloskey
Paul Adenot
Nicolas Silva
Ehsan Akhgari
Phil Ringnalda
Ryan VanderMeulen
Brian Birtles
Steven Michaud
Dave Townsend
Tom Tromey