On 13-12-04 12:35 AM, Brandon Jones wrote:
Firefox does the same thing. The current limits can be seen here:
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
EachSo 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.
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.