Re: [Public WebGL] If you can create N contexts, should you always be able to create N+1 contexts?

[Benoit Jacob <bjacob@mozilla.com>]

On 13-12-04 12:35 AM, Brandon Jones wrote:

Sorry for the awkward subject line, I'll try my best to explain:

I've just finished addressing an issue in Chrome where in some cases canvas.getContext would stop returning WebGL contexts after creating a reasonable amount of them. (See this bug, reported by Patrick Cozzi) After fixing this issue, I've created a conformance test to verify the behavior.

The question is whether or not the behavior tested here is desired. Specifically it tests that N contexts can be created (N = 50 by default) without issue while still holding references to all previous contexts. Functionally the test is extremely similar to context-creation-and-deletion, with the difference being that that test allows the contexts to fall out of scope each iteration so they can be garbage collected. The new test does not require that all N contexts must be active once, however. In Chrome once certain limits are reached the least recently used context will be forcibly lost to make room for the new ones.

Firefox does the same thing. The current limits can be seen here:

http://hg.mozilla.org/mozilla-central/file/7476bb2b8e9c/content/canvas/src/WebGLContext.cpp#l656

That behavior isn't described by the spec, however. There's nothing that says you can't simply start returning null at some point in response to memory pressure.

The problem here is that what you just said applies not only to us, browser makers implementing WebGL on top of e.g. OpenGL ; it also applies to driver vendors implementing OpenGL on top of hardware with finite resources. So in low-memory conditions, before we get to decide whether we want to return null, the system's OpenGL implementation could already have made that decision for us.

So if you want to spec WebGL to disallow getContext returning null if it has previously returned non-null, then we need to think about what we are going to do if OpenGL context creation fails.

Luckily, we always have the option of context loss. I am unsure whether it is currently conformant for getContext to return a context already in lost state (and generate webglcontextlost immediately)? 2.1 Context Creation says

Each WebGLRenderingContext has a webgl context lost flag, which is initially unset.

So maybe it's not conformant at the moment, but even so, it seems that it would only be a minor change to the spec, a strict relaxation, to make it conformant for getContext to return a lost context?

Note that such lost contexts should not be restorable, or else the application would typically enter an infinite cycle of trying to restore that context.

The new test works as-is in Firefox and Safari (And Opera will gain our fix by default), so I don't think it's a big concern, but does anyone have reason to object to testing this behavior? If so, what are your opinions on how large number of context allocations should behave? Is it ever acceptable to fail to return a context if an identical creation previously succeeded?

To summarize, I don't have an strong preference between these two options:
 - 1) (Current Firefox behavior) if OpenGL context creations fails, then WebGL context creation fails.
 - 2) (What I described above) if OpenGL context creations fails, then WebGL context creation returns a lost non-restorable context.

What I do care about is avoiding speccing things in a way that is not implementable in low-memory circumstances. Mandating that getContext must return a non-lost context, seems unimplementable in low-memory circumstances.

Benoit

--Brandon