W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2013

Re: [whatwg] Challenging canvas.supportsContext

From: Benoit Jacob <jacob.benoit.1@gmail.com>
Date: Wed, 19 Jun 2013 17:12:54 -0400
Message-ID: <CAJTmd9rbEkTe9D1n0BP-EsStAggH1BLCpdLfNm5s5RGrELzcug@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: WHATWG <whatwg@lists.whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
2013/6/19 Boris Zbarsky <bzbarsky@mit.edu>

> On 6/19/13 3:34 PM, Tab Atkins Jr. wrote:
>
>> This is missing the point.  You don't want to wait until it's actually
>> time to create the context.  Unless you torture your code flow, by the
>> time you're creating a context you should already know that the
>> context is supported.  The knowledge of which context to use is most
>> useful well before that, when you're first entering the app.
>>
>
> But supportsContext doesn't give any guarantee that the getContext will
> succeed.
>
>
>  Plus, it doesn't matter how late you do the detection - if you do a
>> straight *detection* at all rather than an initialization (that is, if
>> you throw away the context you've just created for testing)
>>
>
> OK, but why are we making that assumption?  I guess if people insist on
> doing that, then we do in fact need something that will basically try to
> guess whether getContext might succeed.
>
>
>  Like @supports, the supportsContext() method can be easy and reliable
>> with a very simple definition for "supports" - it returns true if
>> calling getContext() with the same arguments would return a context
>> rather than erroring, and false otherwise.
>>
>
> Just so we're clear, this is _not_ what supportsContext is specified to
> do.  As specced, it will return false if you know for a fact that
> getContext would return null.  It will return true if you think that
> getContext might not return null.  This means that a true return doesn't
> really mean squat about what getContext will do.
>
> And the reason for that is that you can't tell whether getContext will
> return null until you try to do it, given how getContext is specced.
>

Yes, it seems that supportsContext being under-specified allows for
confusion to happen, as it is given different meanings in different emails
in this thread, that are mutually incompatible:

>From Tab's 1st email:

> *The problem that supportsContext() solves, and which was brought up*
> * repeatedly during the drive to add this, is that spinning up contexts*
> * can be expensive.*
>

>From Tab's 2nd email:

> *Like @supports, the supportsContext() method can be easy and reliable*
> * with a very simple definition for "supports" - it returns true if*
> * calling getContext() with the same arguments would return a context*
> * rather than erroring, and false otherwise.*
>

The incompatibility is that the second quote's requirement can only be met
if supportsContext("webgl") actually creates an OpenGL context --- which is
incompatible with the first quote, which requires supportsContext to be
significantly quicker than getContext, which can only be achieved by not
actually creating an OpenGL context.

(Replace "OpenGL context" by "Direct3D device" or whichever concept applies
to the operating system at hand).

Benoit




>
> -Boris
>
Received on Wednesday, 19 June 2013 21:13:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:22 UTC