68ms used to GetHWEncoderCapabilities() during Fenix startup

RESOLVED FIXED in Firefox 68

Status

()

defect
P2
normal
RESOLVED FIXED
2 months ago
2 months ago

People

(Reporter: jesup, Assigned: cpearce)

Tracking

(Blocks 1 bug)

Trunk
mozilla68
Unspecified
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

(Whiteboard: [qf:p2:responsiveness])

Attachments

(1 attachment)

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.

this is pretty bad. p2

Whiteboard: [qf] → [qf:p2:responsiveness]
Assignee: nobody → cpearce
Priority: -- → P2

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.

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.

Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f6d24071d2ba
Cache GFXInfo WebRTC HW encode/decode result on Android. r=snorp
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.