[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?
Apologies for returning so late to this discussion.
While I agree that the conformance tests must verify specified
behavior, there are already many tests which verify higher-level
constructs than simply what is written in the WebGL, OpenGL ES, or
GLSL ES specs. For example, there are several rendering and shader
tests which came from real-world use cases like Google Maps, and these
tests verify the combination of several constructs in these specs. In
some sense these tests shouldn't be needed, since lower-level tests
for the various primitives exist separately, but the reality is that
they exercise various driver bugs that we don't want to have regress
ever again. The only way to ensure this is to have them in the "must
pass" section of the conformance suite.
I believe that the new test in question, which is a regression test
for a bug in Chrome, doesn't impose any onerous restriction on a WebGL
implementation, and it would be either difficult or undesirable to
specify exactly the behavior being tested.
I'm planning to leave the new test in the conformance suite until such
a time comes that a WebGL implementer wants to revisit its behavior.
On Thu, Dec 5, 2013 at 11:42 AM, Jeff Gilbert <email@example.com> wrote:
> I believe we already have a place for these tests in the 'extra' folder. It would be nice to make them a little more visible, though. (particularly if we're going to add to them)
> ----- Original Message -----
> From: "Benoit Jacob" <firstname.lastname@example.org>
> To: "Mark Callow" <email@example.com>, "Kenneth Russell" <firstname.lastname@example.org>
> Cc: "public webgl" <email@example.com>
> Sent: Thursday, December 5, 2013 5:09:39 AM
> Subject: Re: [Public WebGL] If you can create N contexts, should you always be able to create N+1 contexts?
> On 13-12-04 09:39 PM, Mark Callow wrote:
>> On 2013/12/05 4:00, Kenneth Russell wrote:
>>> OK, great. Thanks. If anyone else has concerns at any time, please follow up.
>> If something is not in the spec. it cannot be required for conformance.
>> 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.
>> Benoit Jacob wrote:
>>> 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
>>> that context.
>> 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?
> Yes, if some event happens that gives a reasonable chance for context
> creation to succeed again, then it's reasonable to fire contextrestored.
>> 合が有ります。正式なメール受信者では無い場合はメール複製、 再配信また
>> れましたら削除を行い配信者にご連絡をお願いい たし ます.
>> 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.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: