Adds ImageUsageType to ImageClient and ImageContainer to identify user of Image at WebRenderImageHost.
Some ImageContainers are used only for allocating Image. Only following types calls ImageContainer::SetCurrentImages().
- ImageUsageType::Canvas
- ImageUsageType::OffscreenCanvas
- ImageUsageType::VideoFrameContainer
Differential Revision: https://phabricator.services.mozilla.com/D211147
This doesn't change behavior on its own, but it's likely we want to make
the tab focusability more complicated in bug 1895184, and this will make
changes to this area less painful.
Differential Revision: https://phabricator.services.mozilla.com/D209525
All present uses of the call-site arguments to MozPromise's methods
supply static strings. However, this is nowhere enforced. Do so.
Additionally, since this is the third or fourth time the present author
alone has personally implemented such an enforcement mechanism, create a
helper class to simplify doing so.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D207462
The `ToMediaControlKeyStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`MediaControlKey` generated by the dom binding in
`EnumStrings<MediaControlKey>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205006
The `ToMediaControlKeyStr` can be replaced by `GetEnumString` since
`GetEnumString` is able to access the enum mapping strings of the
`MediaControlKey` generated by the dom binding in
`EnumStrings<MediaControlKey>::Values`
Differential Revision: https://phabricator.services.mozilla.com/D205006
In bug 1883435 comment 2 chutten mentions that including
nsGlobalWindowInner.h from GleanMetrics.h causes a stylo build failure.
This is because nsGlobalWindowInner.h itself brings a bunch of DOM
bindings template soup that bindgen isn't great at dealing with.
That can be fixed in various ways. However, there is a simpler fix,
which is not including GleanMetrics at all.
It's trivial to do, and given it's a massive autogenerated file, and
Document.h is a very common header, it's worth doing this if only for
build times.
Fix a bunch of unused includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D203625
Much like BindToTree.
This will be useful because I need to pass more information through
UnbindFromTree() to speed up dir=auto for bug 1874040.
Differential Revision: https://phabricator.services.mozilla.com/D202215
The graph of the MediaElementAudioSourceNode will be used for tracks for
decoded media resource output.
Similarly for mozCaptureStreamUntilEnded().
The MediaTrackGraph of default sample rate is now constructed only if required
and when a track on the graph will be created, to address a MediaTrackGraph
leak, and so allows landing a crashtest.
Tab audio capture still expects the default graph.
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1633436
Differential Revision: https://phabricator.services.mozilla.com/D198771
The aTrack parameter is no longer required because, as of
https://phabricator.services.mozilla.com/D198231, MediaStreamRenderer no
longer needs the promise to be rejected when the track is destroyed.
Instead the wait for the device to start is terminated when no outputs to the
specified device remain.
NotifyWhenDeviceStarted() is removed from some gtests that don't have any
track outputs. They use WaitFor(cubeb->StreamInitEvent()) to wait for a
device anyway and don't need to know precisely when the graph switches from
the fallback driver to the callback. If a test does need this precise timing
it can use NotifyWhenDeviceStarted() if MediaTrack::AddAudioOutput() is used.
Differential Revision: https://phabricator.services.mozilla.com/D198232
The primary motivation for MediaStreamRenderer keeping track of and settling
incomplete promises is that, after changes in subsequent patches,
AudioStreamTrack outputs will share CrossGraphReceivers and so dedicated
CrossGraphReceivers will no longer be available to reject incomplete promises
when CrossGraphRecievers are Destroy()ed when an output is removed.
This also reliably keeps promise resolution in order wrt the synchronous
resolution from a setSinkId() call while playback is paused.
When a promise is settled because a subsequent pause or setSinkId() makes
the device change unnecessary, the promise is now resolved instead of
rejected. The new behavior is consistent with the resolution of a
promise created while playback is paused and with AudioSinkWrapper. Promise
resolution may be less likely to surprise content script than promise
rejection.
The situation with multiple tracks is somewhat arbitrary. Settling of the
promise depends on which tracks were present when setSinkId() was called.
GenericPromise::All() in MediaStreamRenderer::SetAudioOutputDevice() would
reject when the first track that existed at setSinkId() was removed or ended.
This patch switches to AllSettled() and resolves when all tracks that existed
at setSinkId() have ended. When AudioStreamTrack outputs no longer have
dedicated CrossGraphRecievers, removal of tracks will no longer cause the
promise to be settled until no tracks require the device.
Differential Revision: https://phabricator.services.mozilla.com/D198231
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
When the audio sink shutdown, we should also reset the audible state for
the listeners. Otherwise, MediaDecoderStateMachine would possibly rely
on the incorrect audible state that is produced by previous sink, which
would cause showing the sound indicator even if no sound is being playing.
Eg. Considering following case without the reset of the audible state
1. Sink A is audible -> MDSM set mIsAudioDataAudible=true
2. Stop sink
3. Recreate sink B and it's playing silence -> MDSM's mIsAudioDataAudible=true is still true, this is wrong!
Differential Revision: https://phabricator.services.mozilla.com/D113550
This allows video playback to continue uninterrupted.
The AudioSinkWrapper now maintains the correct playback position in the media
data. Previously the replacement AudioSinkWrapper started its clock at the
"current playback position" from the MediaDecoderStateMachine, which did not
include additional time from looping, so silence would be played until the
missing time had passed.
The AudioSinkWrapper now continues to periodically attempt to open a new
output device if not initially available. Previously such attempts were only
performed on state changes such as seeking or unmuting.
The promise returned from MediaDecoderStateMachine::InvokeSetSink() now
resolves regardless of whether the new device can be opened successfully.
Previously the promise could be rejected if the device was necessary for audio
output at the time of the call but no check for device availability (beyond
that of device enumeration) was performed if playback was suspended or muted
or if a subsequent device change had already been queued. Even previously the
underlying device was changed even when the promise was rejected and could be
used if a state change occurred.
Differential Revision: https://phabricator.services.mozilla.com/D181975
This allows video playback to continue uninterrupted.
The AudioSinkWrapper now maintains the correct playback position in the media
data. Previously the replacement AudioSinkWrapper started its clock at the
"current playback position" from the MediaDecoderStateMachine, which did not
include additional time from looping, so silence would be played until the
missing time had passed.
The AudioSinkWrapper now continues to periodically attempt to open a new
output device if not initially available. Previously such attempts were only
performed on state changes such as seeking or unmuting.
The promise returned from MediaDecoderStateMachine::InvokeSetSink() now
resolves regardless of whether the new device can be opened successfully.
Previously the promise could be rejected if the device was necessary for audio
output at the time of the call but no check for device availability (beyond
that of device enumeration) was performed if playback was suspended or muted
or if a subsequent device change had already been queued. Even previously the
underlying device was changed even when the promise was rejected and could be
used if a state change occurred.
Differential Revision: https://phabricator.services.mozilla.com/D181975
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
Similarly to other commits, it's necessary to sometimes reduce the precision of
returned time values, to ensure there's no change to returned numbers.
Differential Revision: https://phabricator.services.mozilla.com/D173313
Similarly to other commits, it's necessary to sometimes reduce the precision of
returned time values, to ensure there's no change to returned numbers.
Differential Revision: https://phabricator.services.mozilla.com/D173313
