[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Blacklisted driver notification

I think that the notification about driver updates should stem from the browser (and not the individual application).
- It's the browsers business white/black listing drivers
- A common user experience that can be optimized to the benefit of everybody
- The driver update advise can be made much more specific and helpful then a webapp using a single flag ever could.

There are some concerns that need to be addressed:
- Not leaking out more identifyable bits for supercookies
- Not annoying the user with driver update dialogs all over

This leads to a relatively simple mechanism which consists of two parts:
Polling for driver update:
#1 A web-application can poll the browser to display a driver update dialog to the user, perhaps something like: pollDriverUpdate()
#2 The user can decide to say "no", and he can decide to persist that choice (like for saving passwords) or change it in the settings. so pollDriverUpdate() may return false without any dialog being shown. Calling the pollDriverUpdate() function without any driver being outdated, equally no dialog is shown and false is returned.
#3 If the poll to a driver update is accepted by the user, an appropriate and well curated help dialog will guide them trough the process as smoothly as possible using the available operating system, vendor and GPU information.

Figuring out weather to do polling:
- An application may decide by itself that performance is too slow (by any number of internal measurements) and call the pollDriverUpdate() function.
- An application may request a performance profile with the conditional that if the driver is outdated and if the performance profile is not fulfilled, the poll dialog mechanism kicks in. This could look like: pollDriverUpdateIfLess({shaderPerformance: 4.0}) which may return false for any of the described reasons a pollDriverUpdate() would.