https://perfht.ml/2F72j29 shows us spending about 100ms just trying to get some webgl data (in this method: https://searchfox.org/mozilla-central/rev/6e0e603f4852b8e571e5b8ae133e772b18b6016e/toolkit/modules/Troubleshoot.jsm#310 ) So, first of all, this looks expensive to me. If we incur 100ms jank every first time we initialize a webgl context in a process (to load the dlls and initialize a direct3d thing and whatnot) that seems really sad. Can we improve that? Second, about:support runs in the parent, so this initialization is kinda useless: nothing else will use a canvas webgl context in the parent directly (hopefully). But this also means it's extra expensive - we're janking the UI thread and that's sad. I'm not a graphics bod but it'd be great if we could make this better. The first thing that springs to mind is asking the gpu process (or a content process?) to do the data gathering for us and send it back, which presumably/hopefully would have some of this stuff ready for us in the common case, but also the (async) ipc would keep the main UI process responsive. There's already infrastructure to return data async so that's not an issue. I don't know if we can do something about the actual cost of initializing the webgl context itself, and/or if it's cheaper in web content processes. It may also be worth checking if we pay this cost per-content process, which would be extra sad. Maybe it's less the second time we init because of OS-level or disk-level caching for the dll files? Still, the 3d context stuff would probably rerun every time...

Prefs affect about:support data, so we cannot cache that data reliably. We can talk (and have talked in the past) about WebGL context creation delay, but most of it seems required. In case it's not clear, WebGL contexts are created anew each time. We don't (and can't) reuse WebGL contexts between canvases. It might be possible to reuse GLContexts for multiple WebGLContexts, but this is extra engineering, complexity, and fragility for minimal benefit. about:support should probably be in a content process, which would solve the UI jank. I'll look at a patch that tightens up either information gathering in about:support or GLContext creation, but I don't want anything that introduces new caching layers or IPC.