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

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

On Wed, Dec 4, 2013 at 4:25 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
> 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.

While the WebGL spec doesn't currently really allow
getContext('webgl') to return a context in the lost state -- at least,
some applications would be surprised by that -- it does spec that the
'webglcontextcreationerror' event is dispatched to the canvas if
context creation fails.

I'd like to see this new test remain in the conformance suite because
it covers a quality of implementation bug in Chrome. It seems that
Firefox and other browsers provide the same basic quality assurance.
Note that the test doesn't assert that all of the WebGL contexts are
active simultaneously; it just verifies that the new one is created
successfully. The WebGL implementation can forcibly delete the oldest
underlying OpenGL contexts, and send lost context notifications to the
associated WebGL contexts, to pass the test if necessary.

To ask again: any strong objections to leaving this new test in place?
If so, any suggestions on how to modify it to make it acceptable?



You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl