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

Re: [Public WebGL] another proposal to temporarily expose some device/driver information only when really needed

On Wed, May 2, 2012 at 10:43 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
That would remove the reason not to put getDeviceAdvisories on the WebGL context: users concerned about performance could simply do

var advisories = canvas.getContext("webgl", {async:true}).

I don't think this really works. These device properties are associated with the GPU; if the context is lost and restored on a different GPU, the properties change.  This means you want an active, non-lost WebGL context in order to retrieve that data.  In the above, the context you're calling the function on would be in the lost state, where it doesn't yet know anything about the hardware.

Async context creation is still useful here, since it avoids (or at least makes it possible to avoid) a 100ms browser hitch while you do this, but I think you still have to wait the 100ms before this information is available.
You don't need to do the actual OpenGL context creation just to return the correct advisory: all you need is GPU/driver detection and blacklist processing. So we could imagine that async context creation makes getDeviceAdvisories available before the webglcontextrestored event. For example, it could be available either:
 - immediately after getContext returns (requires the browser to synchronously check the blacklist, which is cheap enough)
 - or once the webglcontextlost event is dispatched, deferring OpenGL context creation until the script has handled that event
 - or we could introduce a new kind of event.


Good point, but by "slow" I didn't mean "this machine is slow compared to other machine". Instead, I meant "this feature is slow compared to other features that you might prefer to use instead, on this given machine".

That's a little vague, especially if there end up being more than two APIs available.  If this really means "slower than 2d canvas"--which is still pretty vague, since it probably depends on which features you exercise--maybe it shouldn't pretend to be generic, and actually say "slowerThan2DCanvas"?
On Wed, May 2, 2012 at 1:53 PM, Ashley Gullen <ashley@scirra.com> wrote:
"blacklisted": a device is present but was blacklisted (not used) due to known issues.  A Swiftshader WebGL context would say "blacklisted", because it *could* have used a GPU, but didn't because the driver was unstable or whatever.  In that case I'd want to ditch the blacklisted WebGL context and fall back to Canvas 2D.  Alternatively a message could be issued indicating the user needs to upgrade their driver or hardware.  Considering Firefox's stats show something like 50% of users have a blacklisted driver, I think it's essential to expose this information.

This is a bit of a different issue.  The solution for this that's been kicked around for a while is to add a parameter to context creation, eg. "suppressUpgradePrompt".  If not set, the browser is allowed to pop up a UI saying "your drivers are too old for WebGL, click <a href="" href="http://nvidia.com/drivers" target="_blank">nvidia.com/drivers>here</a> for new ones".  If set, it would act as now and fail silently.

Browsers currently can't do this, because there's no way for the browser to know if showing that is appropriate or not.  If the page has a Canvas (or DOM, for that matter) fallback, or if it's an optional feature of the page that can simply be turned off, pages often won't want browsers distracting the user with that.

Glenn Maynard