[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

A way around the software rendering problem, without having to change the spec much at all, would just be to encourage browser makers to include the renderer type in the WebGL RENDERER string.  For example I believe Chrome's WebGL returns something like "WebKit WebGL", but if it returned "WebKit WebGL (SwiftShader)" when rendering with SwiftShader then software rendering could be detected accurately and any fallbacks implemented.  This avoids having to define "slow", "software rendering" or "fallback".  Presumably a similar thing could be done for any future browsers that adopt a software WebGL renderer.  That will allow us to return to a situation where we can get a WebGL context we are confident is hardware accelerated, or choose to keep using a software rendered one, or fall back to canvas 2D.

Not much to do with the general device advisories suggestion, but I think it solves that particular point well.


On 9 May 2012 13:51, Thor Harald Johansen <thj@thj.no> wrote:
How about adding a flag (false by default) that allows an acquired
context to be queried and configured before activation?

That is what the {async:true} flag is going to be, once we have specified and implemented async context creation.

Ah! You're referring to what I'd call a "non-blocking" call, then? With things like node.js being all the rage, "asynchronous" has kind of come to mean "event callback" to many developers.

Even "non-blocking" isn't a very good term. The main benefit here is not the speed of the call, but the delayed resource creation that allows for additional setup. I am struggling to find a good word for the concept, really. It's not really asynchronous if it synchronizes with the first call that requires hardware resources, is it...

Still, is there actually a need for an explicit flag? Neither the programmer nor the end user is going to see a visual difference between "no resources allocated yet" vs "nothing rendered yet". My original point was that it seems entirely possible to allow the following:

var gl = canvas.getContext("webgl");
var caps = gl.getDeviceCaps();

var buffer = gl.createBuffer(); // HW context auto-created here

...and then drop passing flags into getContext() altogether?