This patch enables the compositor process memory reporting for both the
dedicated GPU process case, and the integrated with the main process
case. This will simply cause us to list all of the entries in the shared
surfaces cache to show what is presently mapped in.
By delegating responsibility for shared surfaces reporting to imagelib,
we can cross reference the GPU shared surfaces cache with the local
surface cache in a content process (or the main process). This will
allow us to identify entries that are in the GPU cache but not in the
content/main process cache, and aid in debugging memory leaks. This
functionality is pref'd off by default behind image.mem.debug-reporting.
Additionally, we want to report every entry that was mapped into the
compositor process, in the compositor process memory report. This will
give us a sense of how much of our resident memory is consumed by mapped
images in absence of the more detailed cross referencing above.
At present, surface providers roll up all of their individual surfaces
into a single reporting unit. Specifically this means animated image
frames are all reported as a block. This patch removes that
consolidation and reports every frame as its own SurfaceMemoryReport.
This is important because each frame may have its own external image ID,
and we want to cross reference that with what we expect from the GPU
shared surfaces cache.
This exposes methods to capture a snapshot of the SharedSurfacesParent
cache for memory reporting purposes. It yields the identifiers, image
properties and references to images mapped in the cache. This will be
used by the compositor process to list everything it has mapped into its
memory space. It will also be used by the content processes / main
process to list images that specific process had mapped into the
compositor process. This will allow us to easily identify what images
remain in the compositor process, but are missing from the surface
cache.
This will be useful for AudioWorklet-specific storage and behavior.
PaintWorkletImpl is in layout/style, because it will be referenced
from CSS.cpp in the same directory.
Depends on D6108
Differential Revision: https://phabricator.services.mozilla.com/D6109
--HG--
extra : moz-landing-system : lando
When opening a web console and a browser console, we instantiate two NetworkMonitor
instances in the same process and they need independant states.
Differential Revision: https://phabricator.services.mozilla.com/D6054
--HG--
extra : moz-landing-system : lando
This patch prevents the test-coverage task from running on builds that are not related to code coverage.
Differential Revision: https://phabricator.services.mozilla.com/D6444
--HG--
extra : moz-landing-system : lando
Replace mozilla.widget.use-argb-visuals pref by -moz-gtk-csd-transparent-background media query at browser.css
to draw transparent background. The media query is set by toolkit code and enabled when compatible
window manager is detected.
Differential Revision: https://phabricator.services.mozilla.com/D6658
--HG--
extra : moz-landing-system : lando
This changeset extends the async initialize functionality added in the prior
changeset by wrapping the Initialize resolver in a promise. This allows us to
use familiar promise machinery to handle async init of the CDM. We do this by
creating the promise and setting up handling when we receive the init message on
the ChromiumCDMChild, but resolving the promise in the `OnInitialized` callback
from the CDM to the ChromiumCDMChild.
We still only support CDM9 as of this changeset. As such, we now manually call
`OnInitialized` to make sure the ChromiumCDMParent is notified that the CDM has
initialized. When we implement the CDM10 interface, these manual calls will be
moved to the CDM9 compat layer, and Widevine CDM10+ can perform its own
callback.
This changeset adds a failure path to initialization, as the `OnInitialized`
interface we implement allows for failure. However, since we manually call into
this path for CDM9 we shouldn't get any such failures. Once CDM10 is fully
implemented its possible that the init callback could indicate failure, and the
handling here would be invoked.
Depends on D6061
Differential Revision: https://phabricator.services.mozilla.com/D6066
--HG--
extra : moz-landing-system : lando
Starting at the Widevine CDM10 interface, the CDM is expected to make a callback
to an `OnInititalized` function to signal initialization has taken place. Prior
to this, it was sufficient to call the init function on the CDM, with no waiting
for a callback.
This changeset puts in place the IPDL to support async init, as well as the
handling for the ChromiumCDMParent and ChromiumCDMProxy. The code is not fully
updated to handle CDM10, so CDM9 is the only compatible CDM. Because CDM9 does
not perform the init callback, we immediately call our IPDL to signal init has
taken place. This also accommodates the clearkey case, which uses the CDM9
interface.
Further changesets will put in place more elaborate handling to accommodate the
possible failure of init, as well as implementing the handling `OnInitialized`
function explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D6061
--HG--
extra : moz-landing-system : lando
mach try fuzzy has some stronger requirements compared to mach test.
Depends on D6673
Differential Revision: https://phabricator.services.mozilla.com/D6674
--HG--
extra : moz-landing-system : lando
Create a new mochitest that suspends enumerateDevice(). This can happen when the current window navigates away. This is achieved by using an iframe to enumerate devices and clearing the iframe window before the promise is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D2709
--HG--
extra : moz-landing-system : lando
create LazyActorClass based off ObservedActorFactory and RegisterdFactory classes for use in RootActor and BrowsingContextActor;
Depends on D6468
Differential Revision: https://phabricator.services.mozilla.com/D6470
--HG--
rename : devtools/server/actors/common.js => devtools/shared/protocol/lazy-pool.js
extra : moz-landing-system : lando
_CrtSetReportXxxx stuff is dead decause we do not use debug CRT even in debug
builds for a long time. So I removed it to fix -Wunused-function.
--HG--
extra : source : ba00278fc1deee805e7ed13d0dc0658dee13465c
extra : intermediate-source : 5ffdd1f9f2562f9915f3c8805218fa33a908be20
