[whatwg] [canvas] Proposal for supportsContext

[Glenn Maynard]

On Mon, Sep 10, 2012 at 2:39 PM, Dean Jackson <dino at apple.com> wrote:

> > Can't Modernizr just lazy load the WebGL context?  (i.e. only try to
> create a context if the web page actually asks if WebGL is supported)
>
> Yes, it could. But we don't control Modernizr or any other scripts people
> might use. I'd rather provide something at the browser-level to protect
> from bad practice than expect every page to behave nicely.
>

Expecting pages to use a supportsContext API is still expecting pages to
behave nicely.

If you really want to protect users from the behavior of pages, you'd
really need to make creating the context cheap.  For example, don't switch
to a high-power GPU until the page actually draws something, and--since
many pages use both Canvas and WebGL for one-shot rendering--be sure to
switch back to the low-power GPU after some idle time.  (That means saving
the WebGL state so it can be restored if the context is used again
later--or as a last-ditch fallback, triggering context loss.  I expect
you'd want to be able to "downgrade" the GPU like this anyway, or else
every page that does a quick draw-once-show-forever WebGL render would hurt
laptop battery life.)  A caching approach could also be used, to avoid
creating the actual low-level context if all the page is doing is creating
a context and doing a couple getParameter calls.

(By the way, I'm not sure about it being "bad practice" to create a context
in advance.  It's just standard feature testing, which is exactly how
JavaScript developers have been taught to detect features.  It doesn't work
as well with WebGL as with other APIs, since WebGL availability can change
over a single page view, but it'll work most of the time.)


On Mon, Sep 10, 2012 at 2:44 PM, Tobie Langel <tobie.langel at gmail.com>
 wrote:

> It does. Only expose the API when you can create the context.
>

Whether you can create a WebGL context can change after creating the
HTMLCanvasElement.  (For example, the driver blacklist might be updated, or
you might create another context which is mutually exclusive with it.)  Of
course, properties on an object shouldn't change dynamically.

On Mon, Sep 10, 2012 at 3:03 PM, Rick Waldron <waldron.rick at gmail.com>
 wrote:

> Has anyone considered a single global WebGL object with all of those

constructors defined as properties?
>

It's too late; WebGL is a shipping, widely-used API.  (This isn't a WebGL
problem, either; it's just doing what every other API on the platform does.
 I don't think WebIDL even has a mechanism to put interfaces inside other
objects.)

-- 
Glenn Maynard