Closed Bug 1593725 Opened 1 year ago Closed 1 year ago

Cache gfx blacklist information for content processes so as to avoid having to look at 28 prefs and scan the blocklist 28 times for each child

Categories

(Core :: Graphics, task)

task
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox72 --- fixed

People

(Reporter: Gijs, Assigned: Gijs)

References

Details

Attachments

(1 file)

My understanding is that gfx blacklist state of various bits doesn't change except if the blocklist changes.

Right now, whenever we start a content process we check every supported gfx info feature. This entails a pref read and, if the pref is not present (the default), more detailed checks that look up some hardware information and then compare it with the blacklist.

This is not great, but it's even worse under fission, where every time we load content from a new domain, we spin a new content process, which looks all this up again. It trips the maximum number of pref checks in browser_preferences_usage.js for each of the blacklist prefs.

AFAICT, we can cache this information and invalidate the cache when any of the prefs is set. If the blocklist changes and that impacts our adapters / hardware, that causes one of the prefs to be set.

Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/a1901e1e614f
cache gfx information so we don't re-read prefs and re-search blocklists for each content process, r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
You need to log in before you can comment on or make changes to this bug.