1325212 - Use in-process software rendering in the parent until GPU process has spun up

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect, P3)

Description

[George Wright (:gw280) (needinfo me!)]

Discussed this possibility with Milan today. Looking at our telemetry data, the 75th percentile for GPU process launch times is around 3.5 seconds, the 99th percentile is around 10 seconds and we have a few truly pathological cases where it takes >64 seconds. Our launch times show similar data to the content process', but the content process is less critical as the user doesn't actually use it until they start to browse to a page (about:home is rendered in the parent).

We probably want to look into doing the inverse of what we do when the GPU process dies; that is, start off with in-process rendering and use that until the GPU process has fully initialised, then switch to h/w accelerated.

Ryan also pointed out that these sorts of startup times are going to impact "instant" restarts when we get around to shipping that, so we *might* need to employ a similar mechanism there too.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

It would be valuable to add some additional telemetry to try to narrow down where this time is being spent.

Comment 2

[George Wright (:gw280) (needinfo me!)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
> It would be valuable to add some additional telemetry to try to narrow down
> where this time is being spent.

bug 1324095

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Two possible paint points here: one is canvas data. I'm not sure what would happen if we invalidated and started using a new compositor. The other is flickering. We wouldn't want to composite in the new window until both the UI and content have been repainted.

Comment 4

[Ryan Hunt [:rhunt] (on leave until early May)]

So regarding the telemetry times that we are getting right now, we have a timeout set by a pref (default = 5000ms) for how long we will wait for the GPU process to launch before we abort and do software. [1]

This timeout can begin in a few different places but is basically when we need the UI process is ready to make a compositor [2] and ends when the GPU process opens IPC [3].

So unless the UI process is very slow to request a compositor, I believe this limits how much time is spent forking/creating the process vs. initializing? 

[1] https://searchfox.org/mozilla-central/rev/60785fce6d52289c2e147364863f9d42207c5f91/gfx/thebes/gfxPrefs.h#496
[2] https://searchfox.org/mozilla-central/rev/ac40ca3ec39efe85bfb111274c10ee4ceea5bb7a/gfx/ipc/GPUProcessManager.cpp#496
[3] https://searchfox.org/mozilla-central/rev/60785fce6d52289c2e147364863f9d42207c5f91/gfx/ipc/GPUParent.cpp#79