[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Blacklisted driver notification
On Mon, Mar 5, 2012 at 8:22 PM, Benoit Jacob <firstname.lastname@example.org> wrote:
Regarding your other question about encouraging the user to update drivers: I'd let the application do that if they really want to. The typical Firefox user either doesn't know what a driver is, or doesn't want to be bothered about it, or wouldn't know how to do it, or can't anyway because their OEM locked down driver updates. The application might know more about the user than we do, e.g. a hardcore 3D shooter game might be able to assume that its users care about graphics drivers. What we should do to help, is implement the webglcontextcreationerror event --- I feel bad that we still haven't done it.
It may or may not make sense for browsers to make driver recommendations, but it doesn't make sense at all for individual WebGL apps to do this.
In fact, the application and the browser know different pieces of information:
- the browser knows the system details
- the application knows when it's appropriate to make a driver update suggestion 
: note that another reason why it is very hard for the browser to know when to make a driver update suggestion, is that many apps prefer to silently fall back to a non-WebGL version and would regard a browser dialog about drivers as disrupting their user experience.
So maybe (this is a pie-in-the-sky proposal) the browser could offer an API to make the driver update suggestion, but the application would have to manually trigger it.
(PS. is my font size OK this time?)
It's possible that individual browsers might be kept up to date, as new hardware and drivers are released and tested. If individual apps are doing it, it's guaranteed that most of them will be either out of date or wrong. They also don't have the information needed to implement it, such as GPU hardware IDs and driver versions.
I think it also makes sense that the people maintaining the driver blacklists maintain the driver upgrade table, since they're closely tied. The two-state result--"blacklisted" vs. "not blacklisted"--becomes a three-state field: "blacklisted, but there isn't a working driver yet (so don't ask the user to upgrade)", "blacklisted, and a newer working driver is available", and "working". When a new version of a blacklisted driver is removed from the blacklist because it's been fixed, the entries for the old versions are switched from the first to the second state.
I doubt the "knows more about the user" is meaningful. If I implement a casual 3d game and the user's drivers are out of date, what do I do? The user is likely not "hardcore" user, but I'd absolutely still want the user to be asked to upgrade his drivers, if the alternative is that my product doesn't work and the user leaves. If you give us app developers the choice of whether to ask the user to upgrade drivers or go away, we're *always* going to ask the user to upgrade.