1551890 - 68ms used to GetHWEncoderCapabilities() during Fenix startup

Status: RESOLVED FIXED

(Core :: Audio/Video, defect, P2)

Description

[Randell Jesup [:jesup] (needinfo me)]

Called from mozilla::widget::GfxInfoBase::GetFeatureStatus()
https://perfht.ml/2VBIdou

Deferring this until needed, or doing it off some type of post-startup idle callback would be preferable.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

this is pretty bad. p2

Comment 2

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

According to this profile, we're spending most of our time inside android.media.MediaCodecList.getCodecCount, apparently allocating objects for the codec list. That's code we can't control. It looks like this is cached inside Android, as we seem to only pay that price first time. It doesn't look like there's a faster way to query for the info we need, so probably the best we can do is cache result in the user's profile and invalidate the cache whenever the OS is updated.

I don't think we can easily defer this calculation until later, as the caller expects a synchronous result.

Comment 3

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

Attachment: Bug 1551890 - Cache GFXInfo WebRTC HW encode/decode result on Android. r?snorp

Profiling shows that we're spending a lot of time on startup inside
android.media.MediaCodecList.getCodecCount when GfxInfo::GetFeatureStatus calls
over to Java to determine whether hardware accelerated video encoding is
supported.

Looking at the Java stacks in the profile, Android is spending most of our time
creating a list of codecs. It doesn't look like there's a faster way to query
for hardware accelerated video support. So to speed this up we can cache the
value in the user's profile. We also store the OS version, which we can use to
detect when the OS is updated so we can invalidate the cache then.

Presumably an OS update is the only way a device can have its hardware acceleration
support status change.

With this change, the time we take figuring out the HW encode/decode status
goes from ~100ms on a cold run to ~0.01ms on a cache hit on my HD8 tablet.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f6d24071d2ba
Cache GFXInfo WebRTC HW encode/decode result on Android. r=snorp

Comment 5

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/f6d24071d2ba