[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?

OK, great. Thanks. If anyone else has concerns at any time, please follow up.


On Wed, Dec 4, 2013 at 10:58 AM, Benoit Jacob <bjacob@mozilla.com> wrote:
> On 13-12-04 01:35 PM, Kenneth Russell wrote:
>> 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?
> I don't have a strong objection. I understand that a test can be useful
> even if what it tests isn't technically "in the spec". This might be
> such a case.
> Benoit
>> Thanks,
>> -Ken

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