On 13-12-04 09:39 PM, Mark Callow
On 2013/12/05 4:00, Kenneth Russell
If something is not in the spec. it cannot be required for
OK, great. Thanks. If anyone else has concerns at any time, please follow up.
Maybe we need a non-mustpass category for tests like this.
Yes, this was basically my concern above. What made me not
exceedingly worried about this is that this is something that
current browsers already have to have a solution for in order to
behave well in the real world; the solution adopted by at least
Firefox and Chrome is to lose the oldest-used context when creating
a new context, after a certain number of contexts has been reached,
and while that is not a full solution to this problem, it is enough
to pass the conformance test discussed here; until an alternative to
doing this is found by some browser, and that alternative doesn't
pass the conformance test, the problem with this conformance test
remains somewhat abstract.
Yes, if some event happens that gives a reasonable chance for
context creation to succeed again, then it's reasonable to fire
Benoit Jacob wrote:
Why not? If some other webgl browser-window or tab is closed so a
hardware context becomes available why can't you give it to this
app. and fire contextrestored?
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
Note that such lost contexts should not be restorable, or else the
application would typically enter an infinite cycle of trying to restore
NOTE: This electronic mail message may contain confidential
and privileged information from HI Corporation. If you are not
the intended recipient, any disclosure, photocopying,
distribution or use of the contents of the received
information is prohibited. If you have received this e-mail in
error, please notify the sender immediately and permanently
delete this message and all related copies.