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