1259536 - [Meta] Get telemetry for *why* WebGL fails when it does

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect)

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

It would help to understand if it's our blocklisting or some other reason WebGL context creation may fail.

Comment 1

[Benoit Girard (:BenWa)]

I'm exploring the data we have in 'toolkit/components/telemetry/docs/environment.rst' and seeing how we can query this data:
toolkit/components/telemetry/docs/environment.rst

Looks like we already collect quite a bit of this data through the gfx.features.* fields.

Comment 2

[Benoit Girard (:BenWa)]

Exploring doing SQL query using the Longitudinal table: https://github.com/mozilla/telemetry-batch-view/blob/longitudinal/src/main/scala/streams/Longitudinal.scala

Comment 3

[Benoit Girard (:BenWa)]

I think it make sense to use the SQL queries.

I had a look and the longitudinal table only exposes a subset of the graphics telemetry ping data. I also believe that we will want to perhaps add a few fields to the telemetry ping while we're at it to make sure we can answer all the queries we want.

:rvitillo once I add the missing fields are there any reason why we can't include all the graphics field in the longitudinal table? Or at least one of the table?

Comment 4

[Roberto Agostino Vitillo (:rvitillo)]

(In reply to Benoit Girard (:BenWa) from comment #3)
> :rvitillo once I add the missing fields are there any reason why we can't
> include all the graphics field in the longitudinal table? Or at least one of
> the table?

It would be great if once you add new fields you could also update the gfx schema in [1], which is currently incomplete. The schema will be used for validation and for development of derived datasets. 

Once the changes have landed, you should file a Bug to add the new fields to the longitudinal dataset and put me in CC. 

[1] https://github.com/mozilla-services/mozilla-pipeline-schemas/blob/master/telemetry/main.schema.json#L371

Comment 5

[Benoit Girard (:BenWa)]

Alright I did a bit more digging today.

I'm now convinced the sql/redash is (almost[0]) exactly what we need. From what I was told:
* It's faster to query than spark (if I understood correctly)
* It supports pivot table which is exactly what we need to break down say 'webgl failure causes' into obvious populations.
* If the field you need isn't available in the pivot table you can add it to the query and re-generate it.
* It's easy to edit/fork a query/dashboard. This way we can break things down further if we need them.

We're still missing important failure causes for WebGL in telemetry. Going to file a bug to get better WebGL feature status into the telemetry ping which will depend on bug 1254899.

[0] Something like crash-stats super search is the main thing that missing IMO. Basically just saves you from having to hand edit SQL yourself.