Based on [1], in Beta96, the usage of using WMF in content process is less than 1000, which is gradually decreased by versions. That shows that we could probably stop supporting using WMF in the content process, which caused some blocking and crashes before.
And we also don't need to keep collecting this probe because it has finished its job.
[1] https://mzl.la/3ujQZri
Differential Revision: https://phabricator.services.mozilla.com/D137596
This will allow higher sample rate decoding when the platform supports it, and
will offer a similar error in cases where the platform does not.
Depends on D109380
Differential Revision: https://phabricator.services.mozilla.com/D109381
No code changes.
Build issues were found by renaming `MOZ_GECKO_PROFILER` to something else in toolkit/moz.configure, in both unified and non-unified builds, on all supported platforms.
Also updated some profiler-related comments.
Differential Revision: https://phabricator.services.mozilla.com/D105375
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
When calling PDM::SupportsMimeType not enough information is provided for the PDM to categorically state that a codec isn't supported.
Only creating the decoder successfully matters and the PDMFactory only uses the value returned by Support as a hint to further query the PDM.
Without this change WMFDecoderModule::SupportsMimeType in the GPU process would always return false as it doesn't know yet the KnownCompositor.
Differential Revision: https://phabricator.services.mozilla.com/D100305
Upon starting the RDD and GPU process; we check their decoding capabilities and send it to the parent process. It will then broadcast this information to all content children so that RemodeDecoderModule::Supports can return if a codec is supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D100306
When calling PDM::SupportsMimeType not enough information is provided for the PDM to categorically state that a codec isn't supported.
Only creating the decoder successfully matters and the PDMFactory only uses the value returned by Support as a hint to further query the PDM.
Without this change WMFDecoderModule::SupportsMimeType in the GPU process would always return false as it doesn't know yet the KnownCompositor.
Differential Revision: https://phabricator.services.mozilla.com/D100305
In bug 1595994 we attempted to streamline the ability to determine which decoder was available regardless of the process they would be running in. This was subsequently done via the PDMFactory.
As there are several JS API that can query which codec are supported, it requires a synchronous mechanism.
This allowed to make a determination during the PlatformDecoderModule::Supports call, depending on which process it was going to be called frome.
Having a synchronous IPC call to the RemoteDecoderManagerParent has too many caveats to be workable.
So what we do instead is first determine at launch if the required external framework are available and pass this information to each content process.
When checking if a decoder is available, we make a best guess at determining if the PDM would support such codec, without actually loading such framework when running in the content process.
Supports can no longer make a decision based on the process currently running and as such PDM::CreateAudio/VideoDecoder using an optional system framework now need to further check the validity of the CreateDecoderParam argument.
Differential Revision: https://phabricator.services.mozilla.com/D95245
This is a subset of the parameters passed via CreateDecoderParams and is so
Supports() calls have access to KnowsCompositor and Options when determining
if decoding is supported.
Depends on D54877
Differential Revision: https://phabricator.services.mozilla.com/D54878
We have reports of VPx WMF failures in the wild causing performance issues, but
it can be hard to detect these failures. Having explicit markers in the profiler
with more information will make it easier to see if users are running into these
issues if they can provide profiles. I've also added logs to enrich cases where
we will use logging to debug.
Driveby fix a comment that says we're asserting when we no longer are.
Differential Revision: https://phabricator.services.mozilla.com/D93672
We have reports of VPx WMF failures in the wild causing performance issues, but
it can be hard to detect these failures. Having explicit markers in the profiler
with more information will make it easier to see if users are running into these
issues if they can provide profiles. I've also added logs to enrich cases where
we will use logging to debug.
Driveby fix a comment that says we're asserting when we no longer are.
Differential Revision: https://phabricator.services.mozilla.com/D93672
We have reports of VPx WMF failures in the wild causing performance issues, but
it can be hard to detect these failures. Having explicit markers in the profiler
with more information will make it easier to see if users are running into these
issues if they can provide profiles. I've also added logs to enrich cases where
we will use logging to debug.
Driveby fix a comment that says we're asserting when we no longer are.
Differential Revision: https://phabricator.services.mozilla.com/D93672
It will now be up to the caller to determine where the decoder is going to run. This allows to simplify the audio decoders so that they can run synchronously and be wrapped in a Wasm sandbox (which doesn't support multi-threading)
The structure guarantees that all MediaDataDecoder methods are called on the same thread it's been initialised.
To achieve this, wherever a MediaDataDecoder was created, we wrap it in a MediaDataDecoderProxy that ensures that all methods are running on the given thread.
We keep the behaviour of all methods in all MediaDataDecoder to assert that they are running on the expected thread for diagnostic purposes. It could go in the future.
Video decoders that could block excessingly the thread on which they are called are made to run on their own task queue.
The Apple decoder is mostly entirely asynchronous, with the exception of the drain method which could block.
We exclude the android and omx decoders are the framework they use is 100% asynchronous and already operate on another thread.
Differential Revision: https://phabricator.services.mozilla.com/D86929
This converts `nsAutoPtr` usage in dom/media to `UniquePtr`. Beyond just a
search and replace we also needed to update assignment and access of the
`UniquePtr`s. This falls into a few categories:
- Assignment from a newly constructed object switches to `MakeUnique`
- Assignment from a raw ptr switches to `UniquePtr::reset`
- Handing out a raw ptr now requires `UniquePtr::get`
- Uses `UniquePtr::release` rather than `nsAutoPtr::forget`
- A few spots are updated to return a `UniquePtr` rather than a raw ptr
Differential Revision: https://phabricator.services.mozilla.com/D60084
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55442
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
Currently it's completely unclear at use sites that the getters for `once`
static prefs return the pref value from startup, rather than the current pref
value. (Bugs have been caused by this.) This commit improves things by changing
the getter name to make it clear that the pref value obtained is from startup.
This required changing things within libpref so it distinguishes between the
"base id" (`foo_bar`) and the "full id" (`foo_bar` or
`foo_bar_DoNotUseDirectly` or `foo_bar_AtStartup` or
`foo_bar_AtStartup_DoNotUseDirectly`; the name used depends on the `mirror` and
`do_not_use_directly` values in the YAML definition.) The "full id" is used in
most places, while the "base id" is used for the `GetPrefName_*` and
`GetPrefDefault_*` functions.
(This is a nice demonstration of the benefits of the YAML file, BTW. Making
this change with the old code would have involved adding an entry to every
single pref in StaticPrefList.h.)
The patch also rejigs the comment at the top of StaticPrefList.yaml, to clarify
some things.
Differential Revision: https://phabricator.services.mozilla.com/D38604
--HG--
extra : moz-landing-system : lando
