In order to make sure we're not regressing Android performance when we turn on WebRender on GeckoView, we should figure out how to measure performance.
I talked to chutten on IRC and learned the following things:
The way telemetry works on GeckoView is that GV collects the data and stores it, and the embedding application is responsible for submitting the data. Fenix for example uses the glean SDK to submit the data.
On the backend it is possible to distinguish data submitted from Fennec vs different GV embeddings (Fenix, reference browser, etc.) which is basically all we need, as long as we have the right probes in place, and can actually get at the data.
In terms of getting at the data, it's not published to telemetry.m.o and whether or not we can get to it from databricks is "still up in the air". sql.telemetry.m.o is apparently where Fenix and ReferenceBrowser data ends up for now.
In terms of probes, :snorp pointed me to
GV_STARTUP_RUNTIME_MS which is the GV-equivalent of
FENNEC_STARTUP_TIME_GECKOREADY which is one that we should probably track, in case WR regresses gecko startup time.
So there's some more details to be figured out here, with the end goal being to construct a dashboard where we can monitor the probe data to ensure we're not regressing things.