In addition to updating the interface, this patch also significantly alters the
structure of this test. In particular, it removes the Test* functions in favour
of using template magic.
I did this because I noticed that, in the majority of cases, the stub function
was being called with all zero arguments, and then we check for the expected
error code. I thought that maybe we could replace that repetition with some
templates that instantiate a blank tuple that may then be applied to a callable
object.
See the (MAYBE_)TEST_HOOK* and TEST_DETOUR* macro definitions for detailed
information about how to use these things.
The test successfully completes with both 32-bit and 64-bit builds.
--HG--
extra : rebase_source : 95e9a3386c0a6c5f9f78b1e8fa5a88c1c30e9b51
This patch makes the interceptor's AddHook functions private, and converts
the stubs from simple function pointers into objects containing both the stub
function pointer, plus a INIT_ONCE sentinel.
Setting a hook now requires calling Set or SetDetour on the stub, which ensures
that the hook attempt happens once and only once.
The constructor for the new object is constexpr, so it should not generate
static initializers if it is declared statically.
Note that, as a corollary of the new behaviour, we no longer need to set guards
around any hook setting code. I have removed those when present.
--HG--
extra : rebase_source : 260ec9f99839468d9994186fddd7cf2b33e6c87d
This commit implements the CONTENT_FRAME_TIME metric for the webrender code
path. It follows the same structure as the previous commit implementing it for
the non-webrender code path.
MozReview-Commit-ID: 6aI5uISjgge
--HG--
extra : rebase_source : acbf83d0071e8932b5e96016e6e39e27a7b4da8c
extra : histedit_source : a0f93f80441e5f45c0113244d15400d0f53d9c92
This commit adds the CONTENT_FRAME_TIME metric which tracks the time from the beginning
of a paint in the content process until it is presented in the compositor.
There is existing logging for frame latency which tracks from the beginning of a refresh
tick until the frame is presented. This is undesirable for this probe as javascript and
layout can run in this time period. So this probe uses the existing infrastructure for
logging frame latency, but uses a start time from BeginTransaction in layer manager.
MozReview-Commit-ID: 5z9LS3tsZTY
--HG--
extra : rebase_source : cecb7149f50b2abe7a827dc20f1e8b8ade199258
extra : histedit_source : 581f8f38fc8335575d7275b903a8e1d6a9e5a369
This commit adds a helper function for determining if the WebRenderBridgeParent
is for a content process and replaces uses with it appropriately.
MozReview-Commit-ID: 6YZhjYEYS3P
--HG--
extra : rebase_source : 8ecb1f9146376ac84b84680a5a3454200c940d6a
clang-cl complains about things like:
z:/build/build/src/obj-firefox/dist/include/mozilla/interceptor/VMSharingPolicies.h(53,50): warning: use of identifier 'GetLocalView' found via unqualified lookup into dependent bases of class templates is a Microsoft extension [-Wmicrosoft-template]
return TrampolineCollection<MMPolicy>(*this, GetLocalView(), GetRemoteView(),
^
in various files in interceptor/, and since the warnings are in headers,
rather than in sources, they're rather annoying. Let's fix this to be
standards-complaint and make clang-cl stop complaining.
Summary:
There are two tests failing:
Test that decodingInfo rejects if the video configuration contentType has more than one parameter
and
Test that decodingInfo rejects if the audio configuration contentType has more than one parameter
Our nsContentTypeParser doesn't provide an ability to count the number of parameters, only to retrieve one if the name is known.
Considering the scope of the extra work, we'll leave it as-is for now
Reviewers: bryce
Tags: #secure-revision
Bug #: 1471165
Differential Revision: https://phabricator.services.mozilla.com/D1835
Summary:
Additionally, consider all videos <= 480p to be smooth and power efficient as:
1- Hardware decoding it typically not used for those
2- We can't do any better
3- Any machines should be able to do 480p
Depends on D1794
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1796
Summary:
MediaCapabilities provide a finer detail on VP9 being supported or not. YouTube will use that information to determine which resolutions to support when using VP9
Depends on D1772
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1794
Summary:
If the benchmark task hasn't run yet, we will assume smoothness for now.
Depends on D1771
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1772
Summary:
This will allow to be called from the MediaCapabilities taskqueue if we find that a decoder won't be hardware accelerated.
It is still assumed that Benchmark::Init() was called at least once on the main thread.
Depends on D1628
Tags: #secure-revision
Differential Revision: https://phabricator.services.mozilla.com/D1767
Summary:
Most tests will pass now.
The remaining tests failing are related to incompatibility with our bindings generator, and will be addressed in a later change.
Depends on D1719
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1628
Summary:
The Apple VT decoder requires SPS+PPS at construction time. If not provided, in earlier macOS it used to give an error. In the current 10.13 it appears to work, however the decoder always report to be software only.
To properly determine the decoder capabilities, we construct a SPS NAL from the codec mimetype provided.
Details on the structure of the mimetype can be found in https://tools.ietf.org/html/rfc6381#section-3.3 and is a 1:1 match with the data found in the SPS.
Depends on D1718
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1719
Summary:
We'll need it to properly build a SPS/PPS extradata later. Also, change the types used. The original data is stored on two bytes ASCII, it will always fit in a uint8_t. Additionally, this is how those values are stored in a SPS.
Depends on D1678
Reviewers: bryce
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1718
Summary:
By default, when creating a H264 decoder it is wrapped into a H264Converter which will only create the actual decoder once a valid SPS/PPS has been seen.
As creating valid SPS/PPS NALs isn't trivial, when all we care about are capabilities of such decoder, we do not wrap the decoder so that it will be immediately created.
We can then test its capabilities.
We only enable this on windows, as on mac we need to generate a SPS/PPS, otherwise the mac decoder always report that HW decoding is not enabled.
Depends on D1632
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1633
Summary:
To properly determine if a decoder is hardware accelerated, we must pass information about the compositor to the decoder.
Depends on D1631
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1632
Summary:
For flac, mp3 and adts, if a codec was provided but wasn't supported in the container, it would have reported Maybe instead of No
Depends on D1628
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1629
Summary:
We now provides more detailed information for audio (check sampling rate and channels if provided).
And check for the power efficient attribute. We directly correlate this information with the decoder being hardware accelerated or not. All audio codecs are deemed to be power efficient.
Depends on D1626
Tags: #secure-revision
Bug #: 1409664
Differential Revision: https://phabricator.services.mozilla.com/D1627
shindli
Aaron Klotz
Bas Schouten
Rok Garbas
Boris Zbarsky
Narcis Beleuzu
Ryan VanderMeulen
Ryan Hunt
Nathan Froyd
Gijs Kruitbosch
David Parks
André Bargull
Dragan Mladjenovic
Jean-Yves Avenard