1312568 - Consider creating WebGL (1, 2) on startup to determine the availability

Status: NEW

(Core :: Graphics: CanvasWebGL, defect, P3)

Description

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

There would be value in understand what percentage of Firefox systems are WebGL1/2 capable.  Right now, we only get that percentage for the systems where the user attempts to access WebGL functionality.

This would imply creating a context, so additional load on startup. We may want to consider doing it on version/driver change only, if the cost is high.

Being at startup, it may also introduce potential startup instabilities/crashes, so it would have to be behind a crash guard.

It should also be investigated if this locks OS X into discrete graphics configuration, because it happens on startup.

Comment 1

[Andre Vrignaud [:andre] [Seattle - PST]]

For additional context, a recent goal that is driving this discussion is to be able to use Firefox data to state whether or not WebGL is or is not more available than Flash in the marketplace (and hence a viable replacement for developers). Right now we only track whether WebGL is successful if a user should happen to come across it in the wild, and hence do not have a view of general availability. According to Rebecca Weiss, we do not have a valid way to extrapolate this data point from existing telemetry, and hence recommends us explicitly testing for it.

What are the next steps to explore/understand the risks mentioned so we can bottom out on whether or not to do this? Thanks!

Comment 2

[Jukka Jylänki]

(In reply to Milan Sreckovic [:milan] from comment #0)
> There would be value in understand what percentage of Firefox systems are
> WebGL1/2 capable.  Right now, we only get that percentage for the systems
> where the user attempts to access WebGL functionality.

Does navigating to about:support trigger this attempt? That is, are we able to log the information in about:support without having to create a context?

> This would imply creating a context, so additional load on startup. We may
> want to consider doing it on version/driver change only, if the cost is high.

We probably wouldn't want to trigger telemetry upload on each Firefox load up, but perhaps e.g. once a week or so, so it occurs rarely? (not sure how the system works, but each startup sounds like a lot?)

> Being at startup, it may also introduce potential startup
> instabilities/crashes, so it would have to be behind a crash guard.

> It should also be investigated if this locks OS X into discrete graphics
> configuration, because it happens on startup.

That sounds like a great thing if it triggers a crash, because that means it would uncover a bug for us (-> we're missing a blacklist on a faulty driver version, or we have some other bug to fix?). The second part sounds like a real drawback though, if that would happen.

Comment 3

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

(In reply to Jukka Jylänki from comment #2)
> (In reply to Milan Sreckovic [:milan] from comment #0)
> > There would be value in understand what percentage of Firefox systems are
> > WebGL1/2 capable.  Right now, we only get that percentage for the systems
> > where the user attempts to access WebGL functionality.
> 
> Does navigating to about:support trigger this attempt? That is, are we able
> to log the information in about:support without having to create a context?

Going to about:support does trigger it, but only because we create a context when they go to about:support.

> 
> That sounds like a great thing if it triggers a crash, because that means it
> would uncover a bug for us (-> we're missing a blacklist on a faulty driver
> version, or we have some other bug to fix?). The second part sounds like a
> real drawback though, if that would happen.

Sure - I agree that discovering a crash is good.  We don't want people that never used WebGL to now not be able to use the browser at all (startup crash) while we're noticing that the crash happens, and figuring out how to fix it.

Comment 4

[Alessio Placitelli [:Dexter]]

Dropping my .02€ here, please don't eat me alive as I'm not a GFX person, but rather a Telemetry guy :-)

A big chunk of the Telemetry data collection and initialization happens late during the browser startup, 60 seconds into the browsing session. We collect stuff that impacts the startup performance after that time.

Given that we're moving to e10s, does it make any sense to spawn a potentially crashing process late during startup (only on e10s enabled configurations)? I'm not sure how our GFX system works, so this might be a stupid/bad idea.

Even if that would be possible right now, and if we'd flag this kind of data as "opt-out" we would still only get it from e10s builds, which is not enabled on the whole population. But as we roll out and enable e10s on all users, we might get more insights.

Comment 5

[[e-mail]]

I'm not concerned about this measurement being only on e10s builds.  From my recollection, e10s is rolling out via a sampling approach.  Given that the ultimate goal is to estimate the proportion of clients with WebGL support, assuming the sampling is indeed random, the proportion estimate should be the same (with more variance).

There is one potential issue that we should head off right now, though.  :Dexter, how many clients in the 1% Longitudinal sample are currently enrolled in e10s?  If we do pursue this strategy of a delayed onset WebGL test in a separate process (which sounds like a good idea), would we observe enough clients in Longitudinal with this measurement?

Comment 6

[Georg Fritzsche [:gfritzsche]]

(In reply to Rebecca Weiss from comment #5)
> I'm not concerned about this measurement being only on e10s builds.  From my
> recollection, e10s is rolling out via a sampling approach.  Given that the
> ultimate goal is to estimate the proportion of clients with WebGL support,
> assuming the sampling is indeed random, the proportion estimate should be
> the same (with more variance).

The e10s rollout initially was to specific selected populations (specific Windows versions, no or specific addons, etc.).
The populations used now might be sufficient for the use-case, but it would be best to confirm.

Comment 7

[Kelsey Gilbert [:jgilbert]]

We can likely cross-reference e10s-only WebGL activation rates with our GPU data from all users to strongly infer a global WebGL activation rate.

Regardless, we'd gladly accept this as e10s-only.

That said, if we're making a dummy process anyway, we should be able to do this regardless of e10s activation.

To be clear, this is what I'd like to see:
Some N seconds after start-up, spawn a child process, test for webgl1/2, report back status (success, fail w/reason, crash).

This shouldn't need to be e10s-only because the reasons for not enabling e10s don't apply to our probing of webgl activation. (binary plugins, etc)

Comment 8

[Alessio Placitelli [:Dexter]]

(In reply to Jeff Gilbert [:jgilbert] from comment #7)
> To be clear, this is what I'd like to see:
> Some N seconds after start-up, spawn a child process, test for webgl1/2,
> report back status (success, fail w/reason, crash).
> 
> This shouldn't need to be e10s-only because the reasons for not enabling
> e10s don't apply to our probing of webgl activation. (binary plugins, etc)

That sounds even better then! Clearing my ni? then. Since e10s is not a strong requirement anymore (as we can still spawn a new process I guess), we should not be concerned about how many clients in the Longitudinal are enrolled in e10s. Feel free to flag again if that's not the case.

Comment 9

[Andre Vrignaud [:andre] [Seattle - PST]]

Ok, so do we have a plan then? In particular, I want to be cognizant of Milan/Jeff's early concerns about startup time and stability. Sounds like this plan addresses start up time (delay N seconds); how do we feel about stability concerns at the point when we do the test?

My naive thought was e10s might help us by allowing a WebGL test crash to not affect the core browser stability. Is this not the case?

Comment 10

[Kelsey Gilbert [:jgilbert]]

(In reply to Andre Vrignaud [:andre] [Seattle - PST] from comment #9)
> Ok, so do we have a plan then? In particular, I want to be cognizant of
> Milan/Jeff's early concerns about startup time and stability. Sounds like
> this plan addresses start up time (delay N seconds); how do we feel about
> stability concerns at the point when we do the test?
> 
> My naive thought was e10s might help us by allowing a WebGL test crash to
> not affect the core browser stability. Is this not the case?

E10S gives us a separate web-content process, so if a webgl /page/ crashes, it doesn't bring down the whole browser.
We're talking about making a separate probe process. The reasons we don't turn on e10s universally don't apply to a new non-web-content process, so there's no reason to restrict this to e10s that I know of.

Comment 11

[BugBot [:suhaib / :marco]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.