1522930 - GMP initialization does main thread I/O at startup

Status: REOPENED

(Core :: Audio/Video: GMP, enhancement, P3)

Description

[Andrew Swan [:aswan]]

When the addon manager starts up, GMP is initialized here-ish:
https://searchfox.org/mozilla-central/rev/465dbfe030dfec7756b9b523029e90d48dd5ecce/toolkit/mozapps/extensions/internal/GMPProvider.jsm#589

The first reference to the gmp service initializes it which leads to main thread I/O here:
https://searchfox.org/mozilla-central/rev/465dbfe030dfec7756b9b523029e90d48dd5ecce/dom/media/gmp/GMPServiceParent.cpp#217

Ideally we would defer all this work until at least after the first paint of the browser UI.

Comment 1

[Andrew Swan [:aswan]]

Chris, I picked you at random from people who have touched GMP code recently. Is it feasible to delay GMP initialization as described above?

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

We can probably defer this to after first paint. It needs to happen before we start loading pages, as said pages may try to use GMPs, and fail if we've not initialized the GMPs.

Comment 3

[Florian Quèze [:florian]]

Could we also move the I/O off main thread?

Comment 4

[Paul Adenot (:padenot)]

Chris, I made a guess at the priority here, I'll let you have a go at this if you feel it's important.

Comment 5

[Emma Malysz]

Attachment: Bug 1522930, delay GMP initialization until after first point to improve perceived performance.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2c6d8b14baf7
delay GMP initialization until after first point to improve perceived performance. r=mconley

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/2c6d8b14baf7

Comment 8

[Florian Quèze [:florian]]

Here is a startup profile on the 2018 ref hardware captured on today's Nightly. The view is zoomed to start at the end of the early blank paint, and stop after first paint of the browser UI (right before we initialize NSS) https://bit.ly/2ybWoWz

The load of GMPProviders.jsm is in this range, and the main thread I/O triggered by it is later within the range, when we start the Privileged Content process. Nothing changes on screen during this range, so re-ordering things inside it will have no user-impact.