GPUProcessCrashTelemetryLogger is used to report telemetry of the time used to recover a decoder from GPU crash.
It uses MediaDecoderOwnerID to identify which video we're dealing with.
It uses MediaDataDecoderID to make sure that the old MediaDataDecoder has been deleted and we're already recovered.
It reports two recovery times, one is calculated from GPU crashed (that is, the time when VideoDecoderChild::ActorDestory() is called) and the other is calculated from the MFR is notified with NS_ERROR_DOM_MEDIA_NEED_NEW_DECODER error.
MozReview-Commit-ID: 82BRc2Vs3cw
--HG--
extra : rebase_source : 8c92501f625d44e9391a2432b98842769ed8a199
When GPU process crashes, the MediaDecoder, MDSM, and MFR are all destroyed.
So, we use MediaDecoderOwner to identify which video we're dealing with.
MozReview-Commit-ID: 1cv08M7Cpcf
--HG--
extra : rebase_source : 62f7be874d97a58eb4c1d7a98b4e9fe83a9313d3
We keep the GPU crash time and send back to MFR through MediaResult.
We cannot save the information in VideoDecoderChild as a static member because we are going to read it in MFR's task queue and the data was written in VideoDecoderManager's thread. This is going to be racing.
MozReview-Commit-ID: FXqOgelWY6e
--HG--
extra : rebase_source : 5c0561e009ad16983e1ff910216f9cf7901b5542
Here, we calculate the recovery time from two different start points because that when GPU crashes, VideoDecoderChild::ActorDestory() is called, but VideoDecoderChild doesn't dispatch events to trigger decoder recreation immediately.
Instead, it waits until a new VideoDecoderManager has been recreated [1], and then rejects all pending promises to MFR with a NS_ERROR_DOM_MEDIA_NEED_NEW_DECODER, which triggers playback pipeline recreation.
These two probes help us to know the gap between "GPU crash" and "MFR is notified". We don't need to wait for VideoDecoderManager recreation if we're certain that we don't create remote video decoder anymore. And if the gap is large, it might be a significant optimization.
[1] http://searchfox.org/mozilla-central/rev/51b3d67a5ec1758bd2fe7d7b6e75ad6b6b5da223/dom/media/ipc/VideoDecoderChild.cpp#124-145
MozReview-Commit-ID: DcI2CwWORxZ
--HG--
extra : rebase_source : 2f69330b9721cd4d6895f93b3a3cbc740de54e8c
Practically speaking, with code inlining, this doesn't change anything,
but will allow, in a subsequent change, to easily divert the exported
allocation functions (malloc, etc.) in order to inject replace-malloc
in the pipeline.
The added macro magic is copied from replace-malloc.c.
At the same time, reformat the functions we're touching.
--HG--
extra : rebase_source : f615909101f832f3cc471e23a3cc44a60886843f
Because malloc_decls.h is meant to be included multiple times, it
shouldn't actually declare things itself.
--HG--
extra : rebase_source : 9d6f9b2c61407265377845963a19ace2614160f4
valloc is supposed to page-align data, but mozjemalloc's definition of
pagesize is statically compiled in and might not match the actual page
size at runtime (because of MALLOC_STATIC_SIZES). We change valloc in
mozjemalloc to use the runtime page size.
--HG--
extra : rebase_source : c5b1b56e783b311ac1620a87d910e019e3f18b49
* Works around a driver / kernel crash on some mac machines.
* Allow more sharing of box shadow and clip render tasks.
* Some shader tidy ups.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7e3c8dee71214b5244431de64f65b5a1f71c0108
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e2eeb653097659da42e2c3daf4d7139172785bbf
This patch needs to update rust-azure to 0.21.0.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#17598
<!-- Either: -->
- [] There are tests for these changes OR
- [] These changes do not require tests because _____
Source-Repo: https://github.com/servo/servo
Source-Revision: 3a4b98ad38214495ac0f1f1aa1052f0c583ffe5c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5650f24356c24ee80c4ca4e9560c75c6a6813ccd
Preprocess the generated bindings to support the new BuildFlag
annotation, so that we can compare bindings despite build flag changes.
The build system preprocessor is used because it's easy-to-use and
invoking the actual C++ preprocessor would require much more work.
However, as a result, we use a MOZ_PREPROCESSOR macro to make the build
system preprocessor not handle `#include` lines in the binding files.
MozReview-Commit-ID: 3Gweuwnb1V3
--HG--
extra : rebase_source : 3a1769e4b45bab3175b3609d08e53534380facce
To construct an empty set, we need to use the `set()` notation. In order
to do that, we need to expose `set` to the moz.build sandbox.
MozReview-Commit-ID: DMyKnF0FEx2
--HG--
extra : rebase_source : 5cfe8080ec333a1eca70cd3edba2aaaff6406820
Add a BuildFlag annotation, which when specified for classes, will wrap
generated code in `#ifdef` or `#ifndef` blocks. This functionality is
used for conditionally excluding generated code when NIghtly becomes
Beta, without the need to regenerate bindings.
MozReview-Commit-ID: L2NFM8CHKqF
--HG--
extra : rebase_source : 6ebc82d11fd1aa4aeb57a46262e678480d23de83
We show a message:
1) On first run
2) When there are no highlights
However, these are actually the same case (there are no highlights) so I wanted
to defer to that situation.
I felt it was easier to rm the WelcomePanel and rewrite it than it was to try
to morph it into an empty state for the highlights.
MozReview-Commit-ID: CrRbzA0NoRx
--HG--
extra : rebase_source : ed21103350ea13813062e214d3aec22805cfa7d7
