subject:"\[whatwg\] Challenging canvas.supportsContext"

Dear list,

I'd like to question the usefulness of canvas.supportsContext. I tried to
think of an actual application use case for it, and couldn't find one. It
also doesn't seem like any valid application use case was given on this
list when this topic was discussed around September 2012.

The closest thing that I could find being discussed, was use cases by JS
frameworks or libraries that already expose similar feature-detection APIs.
However, that only shifts the question to: what is the reason for them to
expose such APIs? In the end, I claim that the only thing that we should
recognize as a reason to add a feature to the HTML spec, is
*application*use cases.

So let's look at the naive application usage pattern for supportsContext:

  if (canvas.supportsContext(webgl)) {
context = canvas.getContext(webgl);
  }

The problem is that the same can be achieved with just the getContext call,
and checking whether it succeeded.

In other words, I'm saying that no matter what JS libraries/frameworks may
offer for feature detection, in the end, applications don't want to just *
detect* features --- applications want to *use* features. So they'll just
pair supportsContext calls with getContext calls, making the
supportsContext calls useless.

There is also the argument that supportsContext can be much cheaper than a
getContext, given that it only has to guarantee that getContext must fail
if supportsContext returned false. But this argument is overlooking that in
the typical failure case, which is failure due to system/driver
blacklisting, getContext returns just as fast as supportsContext --- as
they both just check the blacklist and return. Outside of exceptional cases
(out of memory...), the slow path in getContext is the *success* case, and
again, in that case a real application would want to actually *use* that
context.

Keep in mind that supportsContext can't guarantee that if it returns true,
then a subsequent getContext will succeed. The spec doesn't require it to,
either. So if the existence of supportsContext misleads application
developers into no longer checking for getContext failures, then we'll just
have rendered canvas-using applications a little bit more fragile. Another
problem with supportsContext is that it's untestable, at least when it
returns true; it is spec-compliant to just implement it as returning
whether the JS interface for the required canvas context exists, which is
quite useless. Given such deep problems, I think that the usefulness bar
for accepting supportsContext into the spec should be quite high.

So, is there an application use case that actually benefits from
supportsContext?

Cheers,
Benoit

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 11:17 AM, Benoit Jacob jacob.benoi...@gmail.com wrote:
 So let's look at the naive application usage pattern for supportsContext:

   if (canvas.supportsContext(webgl)) {
 context = canvas.getContext(webgl);
   }

 The problem is that the same can be achieved with just the getContext call,
 and checking whether it succeeded.

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.

~TJ

Re: [whatwg] Challenging canvas.supportsContext

2013/6/19 Tab Atkins Jr. jackalm...@gmail.com

 On Wed, Jun 19, 2013 at 11:17 AM, Benoit Jacob jacob.benoi...@gmail.com
 wrote:
  So let's look at the naive application usage pattern for supportsContext:
 
if (canvas.supportsContext(webgl)) {
  context = canvas.getContext(webgl);
}
 
  The problem is that the same can be achieved with just the getContext
 call,
  and checking whether it succeeded.

 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.


I tried to address this very argument in my above email; maybe I wasn't
clear enough.

1. If supportsContext() fails, then getContext() fails just as fast. In
that case, supportsContext isn't any faster.
2. If supportsContext succeeds, then the application is going to want to
proceed with calling getContext, so nothing is achieved by supportsContext
being cheaper than getContext.

If you disagree with that argument, then I would like, again, to hear about
what would be an application use case that actually benefits from
supportsContext.

Benoit

Re: [whatwg] Challenging canvas.supportsContext


On 6/19/13 2:17 PM, Benoit Jacob wrote:

The closest thing that I could find being discussed, was use cases by JS
frameworks or libraries that already expose similar feature-detection APIs.
However, that only shifts the question to: what is the reason for them to
expose such APIs?


I _think_ the issue is poorly-designed detection APIs that do the 
detection even if the consumer of the framework/library doesn't care 
about that particular feature.


That means that right now those frameworks are doing a getContext() call 
but then no one cares that they did.



There is also the argument that supportsContext can be much cheaper than a
getContext, given that it only has to guarantee that getContext must fail
if supportsContext returned false. But this argument is overlooking that in
the typical failure case, which is failure due to system/driver
blacklisting, getContext returns just as fast as supportsContext


I think the argument here is that the common case for getContext is in 
fact more and more the success case.  So the framework/library is 
wasting time successfully creating a context that no one actually cares 
about.


If the above is correct, I agree with Benoit: the right fix is to fix 
the libraries to do the getContext() lazily when someone actually asks 
whether WebGL is enabled.


If I'm wrong, then I'd like to understand what problem we _are_ trying 
to solve.  That is, what the cases are that want to check that they can 
create a context but not actually create one.


-Boris

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 11:29 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 6/19/13 2:17 PM, Benoit Jacob wrote:
 The closest thing that I could find being discussed, was use cases by JS
 frameworks or libraries that already expose similar feature-detection
 APIs.
 However, that only shifts the question to: what is the reason for them to
 expose such APIs?


 I _think_ the issue is poorly-designed detection APIs that do the detection
 even if the consumer of the framework/library doesn't care about that
 particular feature.

 That means that right now those frameworks are doing a getContext() call but
 then no one cares that they did.


 There is also the argument that supportsContext can be much cheaper than a
 getContext, given that it only has to guarantee that getContext must fail
 if supportsContext returned false. But this argument is overlooking that
 in
 the typical failure case, which is failure due to system/driver
 blacklisting, getContext returns just as fast as supportsContext

 I think the argument here is that the common case for getContext is in fact
 more and more the success case.  So the framework/library is wasting time
 successfully creating a context that no one actually cares about.

 If the above is correct, I agree with Benoit: the right fix is to fix the
 libraries to do the getContext() lazily when someone actually asks whether
 WebGL is enabled.

 If I'm wrong, then I'd like to understand what problem we _are_ trying to
 solve.  That is, what the cases are that want to check that they can create
 a context but not actually create one.

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.

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), you'll
still incur the start-up costs of spinning up a context.  Doing that
early or late doesn't matter too much - it's bad either way.

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.  No capacity for lying
there without breaking sites.

~TJ

Re: [whatwg] Challenging canvas.supportsContext

Looking back at the previous discussion:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037229.html
(and succeeding emails)
  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037693.html

Accurate feature detection in libraries like Modernizr was mentioned
as a key use case:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html

Additionally, though, application developers wanted to be able to ask
questions like is software rendering supported for WebGL:

  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037232.html

I think this second use case is valid. One could imagine a graphing or
charting library which would use low-power, software-rendered WebGL if
available, but otherwise would fall back to using
CanvasRenderingContext2D.

I'd like to see supportsContext remain in the spec.

-Ken



On Wed, Jun 19, 2013 at 12:34 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Wed, Jun 19, 2013 at 11:29 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 6/19/13 2:17 PM, Benoit Jacob wrote:
 The closest thing that I could find being discussed, was use cases by JS
 frameworks or libraries that already expose similar feature-detection
 APIs.
 However, that only shifts the question to: what is the reason for them to
 expose such APIs?


 I _think_ the issue is poorly-designed detection APIs that do the detection
 even if the consumer of the framework/library doesn't care about that
 particular feature.

 That means that right now those frameworks are doing a getContext() call but
 then no one cares that they did.


 There is also the argument that supportsContext can be much cheaper than a
 getContext, given that it only has to guarantee that getContext must fail
 if supportsContext returned false. But this argument is overlooking that
 in
 the typical failure case, which is failure due to system/driver
 blacklisting, getContext returns just as fast as supportsContext

 I think the argument here is that the common case for getContext is in fact
 more and more the success case.  So the framework/library is wasting time
 successfully creating a context that no one actually cares about.

 If the above is correct, I agree with Benoit: the right fix is to fix the
 libraries to do the getContext() lazily when someone actually asks whether
 WebGL is enabled.

 If I'm wrong, then I'd like to understand what problem we _are_ trying to
 solve.  That is, what the cases are that want to check that they can create
 a context but not actually create one.

 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.

 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), you'll
 still incur the start-up costs of spinning up a context.  Doing that
 early or late doesn't matter too much - it's bad either way.

 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.  No capacity for lying
 there without breaking sites.

 ~TJ

Re: [whatwg] Challenging canvas.supportsContext


On 6/19/13 3:43 PM, Kenneth Russell wrote:

Accurate feature detection in libraries like Modernizr was mentioned
as a key use case:

   
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html


Right, this is the use case that's not really making sense to me.  The 
fact that Modernizr was doing this _eagerly_ sounds like a bug in 
Modernizr to me...



Additionally, though, application developers wanted to be able to ask
questions like is software rendering supported for WebGL:


That's definitely something that new API would be needed to address, yes.

-Boris

Re: [whatwg] Challenging canvas.supportsContext


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.


-Boris

Re: [whatwg] Challenging canvas.supportsContext

2013-06-19 Thread Brandon Benvie


On 6/19/2013 12:46 PM, Boris Zbarsky wrote:

On 6/19/13 3:43 PM, Kenneth Russell wrote:

Accurate feature detection in libraries like Modernizr was mentioned
as a key use case:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html


Right, this is the use case that's not really making sense to me. The 
fact that Modernizr was doing this _eagerly_ sounds like a bug in 
Modernizr to me...


The point of using Modernizr or something like it is to detect 
availability of features on page load, and then conditionally load 
polyfills/alternate fallback implementations. It specifically does need 
to do eager detection to be useful. It can't wait until the first usage 
to do feature detection; it needs to be done up front when preparing 
dependencies for the main application.


This is also why Modernizr provides a custom build tool. It allows for 
users to only do the feature detection on features they know they need 
to care about, because each check has some cost that needs to be paid 
early on in a page load.

Re: [whatwg] Challenging canvas.supportsContext


On 6/19/13 4:22 PM, Brandon Benvie wrote:

The point of using Modernizr or something like it is to detect
availability of features on page load, and then conditionally load
polyfills/alternate fallback implementations. It specifically does need
to do eager detection to be useful. It can't wait until the first usage
to do feature detection; it needs to be done up front when preparing
dependencies for the main application.


I see.  For this use case, the current definition of supportsContext is 
of limited utility, unless you make some assumptions about behavior that 
the spec does not require


-Boris

Re: [whatwg] Challenging canvas.supportsContext

2013-06-19 Thread James Robinson

On Wed, Jun 19, 2013 at 1:22 PM, Brandon Benvie bben...@mozilla.com wrote:

On 6/19/2013 12:46 PM, Boris Zbarsky wrote:

On 6/19/13 3:43 PM, Kenneth Russell wrote:

Accurate feature detection in libraries like Modernizr was mentioned
as a key use case:

http://lists.whatwg.org/**pipermail/whatwg-whatwg.org/**
2012-September/037249.htmlhttp://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html

Right, this is the use case that's not really making sense to me. The
fact that Modernizr was doing this _eagerly_ sounds like a bug in Modernizr
to me...

The point of using Modernizr or something like it is to detect
availability of features on page load, and then conditionally load
polyfills/alternate fallback implementations. It specifically does need to
do eager detection to be useful. It can't wait until the first usage to do
feature detection; it needs to be done up front when preparing dependencies
for the main application.

What would a page using Modernizr (or other library) to feature detect
WebGL do if the supportsContext('webgl') call succeeds but the later
getContext('webgl') call fails?

I'm also failing to see the utility of the supportsContext() call. It's
impossible for a browser to promise that supportsContext('webgl') implies
that getContext('webgl') will succeed without doing all of the expensive
work, so any correctly authored page will have to handle a
getContext('webgl') failure anyway.

- James

This is also why Modernizr provides a custom build tool. It allows for
users to only do the feature detection on features they know they need to
care about, because each check has some cost that needs to be paid early on
in a page load.

Re: [whatwg] Challenging canvas.supportsContext

2013/6/19 Boris Zbarsky bzbar...@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

Re: [whatwg] Challenging canvas.supportsContext

2013-06-19 Thread Brandon Benvie


On 6/19/2013 2:05 PM, James Robinson wrote:
What would a page using Modernizr (or other library) to feature detect 
WebGL do if the supportsContext('webgl') call succeeds but the later 
getContext('webgl') call fails?


I don't have an example, I was just explaining how Mozernizr is often used.

I'm also failing to see the utility of the supportsContext() call. 
 It's impossible for a browser to promise that 
supportsContext('webgl') implies that getContext('webgl') will succeed 
without doing all of the expensive work, so any correctly authored 
page will have to handle a getContext('webgl') failure anyway.


Given this, it would seem supportsContext is completely useless. The 
whole purpose of a feature detection check is to detect if a feature 
actually works or not. Accuracy is more important than cost.

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 2:20 PM, Brandon Benvie bben...@mozilla.com wrote:
 On 6/19/2013 2:05 PM, James Robinson wrote:
 I'm also failing to see the utility of the supportsContext() call.  It's
 impossible for a browser to promise that supportsContext('webgl') implies
 that getContext('webgl') will succeed without doing all of the expensive
 work, so any correctly authored page will have to handle a
 getContext('webgl') failure anyway.

 Given this, it would seem supportsContext is completely useless. The whole
 purpose of a feature detection check is to detect if a feature actually
 works or not. Accuracy is more important than cost.

Hmm, I guess I agree.  That sucks, but you're right - it's much more
important that you *actually* be able to generate a context when the
feature-detect says you can.

~TJ

Re: [whatwg] Challenging canvas.supportsContext

2013-06-19 Thread Paul Irish

On the Modernizr side, an old version did indeed create a context for
feature detection. For the past two years we have advocated the soft
`WebGLRenderingContext in window` test instead. There, of course, is some
gap between the results of that detect and how successful a getContext call
will be, but I don't have data those false positive rates.

A use case of a Modernizr user is to detect WebGL and show a browser prompt
if it's not detected.  From my understanding nearly no developer re-use the
same context for both detection and use.

I asked mrdoob, developer of three.js if supportsContext would be useful to
the project.. He said they currently create 2 webgl contexts because,
API-wise is not easy to reuse the context that you created for checking if
it was available. Well, it's not pretty, at least

I know the Chrome Web Store had a usecase for detection without context
creation: they wanted to not show apps in the marketplace that couldn't run
on the user's machine.

I agree that supportsContext is only useful if it's more accurate that
!!window.WebGLRenderingContext.



On Wed, Jun 19, 2013 at 2:05 PM, James Robinson jam...@google.com wrote:

 On Wed, Jun 19, 2013 at 1:22 PM, Brandon Benvie bben...@mozilla.com
 wrote:

  On 6/19/2013 12:46 PM, Boris Zbarsky wrote:
 
  On 6/19/13 3:43 PM, Kenneth Russell wrote:
 
  Accurate feature detection in libraries like Modernizr was mentioned
  as a key use case:
 
  http://lists.whatwg.org/**pipermail/whatwg-whatwg.org/**
  2012-September/037249.html
 http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037249.html
 
 
 
  Right, this is the use case that's not really making sense to me. The
  fact that Modernizr was doing this _eagerly_ sounds like a bug in
 Modernizr
  to me...
 
 
  The point of using Modernizr or something like it is to detect
  availability of features on page load, and then conditionally load
  polyfills/alternate fallback implementations. It specifically does need
 to
  do eager detection to be useful. It can't wait until the first usage to
 do
  feature detection; it needs to be done up front when preparing
 dependencies
  for the main application.
 

 What would a page using Modernizr (or other library) to feature detect
 WebGL do if the supportsContext('webgl') call succeeds but the later
 getContext('webgl') call fails?

 I'm also failing to see the utility of the supportsContext() call.  It's
 impossible for a browser to promise that supportsContext('webgl') implies
 that getContext('webgl') will succeed without doing all of the expensive
 work, so any correctly authored page will have to handle a
 getContext('webgl') failure anyway.

 - James


  This is also why Modernizr provides a custom build tool. It allows for
  users to only do the feature detection on features they know they need to
  care about, because each check has some cost that needs to be paid early
 on
  in a page load.

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 2:20 PM, Brandon Benvie bben...@mozilla.com wrote:
 On 6/19/2013 2:05 PM, James Robinson wrote:

 What would a page using Modernizr (or other library) to feature detect
 WebGL do if the supportsContext('webgl') call succeeds but the later
 getContext('webgl') call fails?


 I don't have an example, I was just explaining how Mozernizr is often used.


 I'm also failing to see the utility of the supportsContext() call.  It's
 impossible for a browser to promise that supportsContext('webgl') implies
 that getContext('webgl') will succeed without doing all of the expensive
 work, so any correctly authored page will have to handle a
 getContext('webgl') failure anyway.


 Given this, it would seem supportsContext is completely useless. The whole
 purpose of a feature detection check is to detect if a feature actually
 works or not. Accuracy is more important than cost.

supportsContext() can give a much more accurate answer than
!!window.WebGLRenderingContext. I can only speak for Chromium, but in
that browser, it can take into account factors such as whether the GPU
sub-process was able to start, whether WebGL is blacklisted on the
current card, whether WebGL is disabled on the current domain due to
previous GPU resets, and whether WebGL initialization succeeded on any
other page. All of these checks can be done without the heavyweight
operation of actually creating an OpenGL context.

-Ken

Re: [whatwg] Challenging canvas.supportsContext

2013-06-19 Thread James Robinson

On Wed, Jun 19, 2013 at 3:04 PM, Kenneth Russell k...@google.com wrote:

 On Wed, Jun 19, 2013 at 2:20 PM, Brandon Benvie bben...@mozilla.com
 wrote:
  On 6/19/2013 2:05 PM, James Robinson wrote:
 
  What would a page using Modernizr (or other library) to feature detect
  WebGL do if the supportsContext('webgl') call succeeds but the later
  getContext('webgl') call fails?
 
 
  I don't have an example, I was just explaining how Mozernizr is often
 used.
 
 
  I'm also failing to see the utility of the supportsContext() call.  It's
  impossible for a browser to promise that supportsContext('webgl')
 implies
  that getContext('webgl') will succeed without doing all of the expensive
  work, so any correctly authored page will have to handle a
  getContext('webgl') failure anyway.
 
 
  Given this, it would seem supportsContext is completely useless. The
 whole
  purpose of a feature detection check is to detect if a feature actually
  works or not. Accuracy is more important than cost.

 supportsContext() can give a much more accurate answer than
 !!window.WebGLRenderingContext. I can only speak for Chromium, but in
 that browser, it can take into account factors such as whether the GPU
 sub-process was able to start, whether WebGL is blacklisted on the
 current card, whether WebGL is disabled on the current domain due to
 previous GPU resets, and whether WebGL initialization succeeded on any
 other page. All of these checks can be done without the heavyweight
 operation of actually creating an OpenGL context.


That's true, but the answer still doesn't promise anything about what
getContext() will do.  It may still return null and code will have to check
for that.  What's the use case for calling supportsContext() without
calling getContext()?

- James


 -Ken

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 3:06 PM, James Robinson jam...@google.com wrote:
 On Wed, Jun 19, 2013 at 3:04 PM, Kenneth Russell k...@google.com wrote:

 On Wed, Jun 19, 2013 at 2:20 PM, Brandon Benvie bben...@mozilla.com
 wrote:
  On 6/19/2013 2:05 PM, James Robinson wrote:
 
  What would a page using Modernizr (or other library) to feature detect
  WebGL do if the supportsContext('webgl') call succeeds but the later
  getContext('webgl') call fails?
 
 
  I don't have an example, I was just explaining how Mozernizr is often
  used.
 
 
  I'm also failing to see the utility of the supportsContext() call.
  It's
  impossible for a browser to promise that supportsContext('webgl')
  implies
  that getContext('webgl') will succeed without doing all of the
  expensive
  work, so any correctly authored page will have to handle a
  getContext('webgl') failure anyway.
 
 
  Given this, it would seem supportsContext is completely useless. The
  whole
  purpose of a feature detection check is to detect if a feature actually
  works or not. Accuracy is more important than cost.

 supportsContext() can give a much more accurate answer than
 !!window.WebGLRenderingContext. I can only speak for Chromium, but in
 that browser, it can take into account factors such as whether the GPU
 sub-process was able to start, whether WebGL is blacklisted on the
 current card, whether WebGL is disabled on the current domain due to
 previous GPU resets, and whether WebGL initialization succeeded on any
 other page. All of these checks can be done without the heavyweight
 operation of actually creating an OpenGL context.


 That's true, but the answer still doesn't promise anything about what
 getContext() will do.  It may still return null and code will have to check
 for that.  What's the use case for calling supportsContext() without calling
 getContext()?

Any application which has a complex set of fallback paths. For example,

  - Preference 1: supportsContext('webgl', { softwareRendered: true })
  - Preference 2: supportsContext('2d', { gpuAccelerated: true })
  - Preference 3: supportsContext('webgl', { softwareRendered: false })
  - Fallback: 2D canvas

I agree that ideally, if supportsContext returns true then -- without
any other state changes that might affect supportsContext's result --
getContext should return a valid rendering context. It's simply
impossible to guarantee this correspondence 100% of the time, but if
supportsContext's spec were tightened somehow, and conformance tests
were added which asserted consistent results between supportsContext
and getContext, would that address your concern?

-Ken

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 3:24 PM, Kenneth Russell k...@google.com wrote:
 That's true, but the answer still doesn't promise anything about what
 getContext() will do.  It may still return null and code will have to check
 for that.  What's the use case for calling supportsContext() without calling
 getContext()?

 Any application which has a complex set of fallback paths. For example,

   - Preference 1: supportsContext('webgl', { softwareRendered: true })
   - Preference 2: supportsContext('2d', { gpuAccelerated: true })
   - Preference 3: supportsContext('webgl', { softwareRendered: false })
   - Fallback: 2D canvas

 I agree that ideally, if supportsContext returns true then -- without
 any other state changes that might affect supportsContext's result --
 getContext should return a valid rendering context. It's simply
 impossible to guarantee this correspondence 100% of the time, but if
 supportsContext's spec were tightened somehow, and conformance tests
 were added which asserted consistent results between supportsContext
 and getContext, would that address your concern?

It seems like this falls into the canPlayType() bucket, where you can
definitely give negatives, but your positives are at best hopeful.
Maybe we should just have it do the same thing, and return maybe or
probably rather than a boolean true?

~TJ

Re: [whatwg] Challenging canvas.supportsContext

2013-06-19 Thread James Robinson

On Wed, Jun 19, 2013 at 3:24 PM, Kenneth Russell k...@google.com wrote:

 On Wed, Jun 19, 2013 at 3:06 PM, James Robinson jam...@google.com wrote:
  On Wed, Jun 19, 2013 at 3:04 PM, Kenneth Russell k...@google.com wrote:
 
  supportsContext() can give a much more accurate answer than
  !!window.WebGLRenderingContext. I can only speak for Chromium, but in
  that browser, it can take into account factors such as whether the GPU
  sub-process was able to start, whether WebGL is blacklisted on the
  current card, whether WebGL is disabled on the current domain due to
  previous GPU resets, and whether WebGL initialization succeeded on any
  other page. All of these checks can be done without the heavyweight
  operation of actually creating an OpenGL context.
 
 
  That's true, but the answer still doesn't promise anything about what
  getContext() will do.  It may still return null and code will have to
 check
  for that.  What's the use case for calling supportsContext() without
 calling
  getContext()?

 Any application which has a complex set of fallback paths. For example,

   - Preference 1: supportsContext('webgl', { softwareRendered: true })
   - Preference 2: supportsContext('2d', { gpuAccelerated: true })
   - Preference 3: supportsContext('webgl', { softwareRendered: false })
   - Fallback: 2D canvas


I'm assuming you have (1) and (3) flipped here and both supportsContext()
and getContext() support additional attributes to dictate whether a
software-provided context can be supplied.  In that case, in order to write
correct code I'd still have to attempt to fetch the contexts before using
them, i.e.:

var ctx = canvas.getContext('webgl', { 'allowSoftware': false});
if (ctx) {
  doPreference1(ctx);
  return;
}
ctx = canvas.getContext('2d', {'allowSoftware': false});
if (ctx) {
  doPreference2(ctx);
// etc

how could I simplify this code using supportsContext() ?



 I agree that ideally, if supportsContext returns true then -- without
 any other state changes that might affect supportsContext's result --
 getContext should return a valid rendering context.


It seems overwhelmingly likely that one of the state changes that might
affect the result will be attempting to instantiate a real context.


 It's simply
 impossible to guarantee this correspondence 100% of the time, but if
 supportsContext's spec were tightened somehow, and conformance tests
 were added which asserted consistent results between supportsContext
 and getContext, would that address your concern?


I don't see how supportsContext() could be as accurate as getContext()
without doing all of the work getContext() does.  If it's not 100%
accurate, when is it useful?

- James




 -Ken

Re: [whatwg] Challenging canvas.supportsContext

On Wed, Jun 19, 2013 at 3:39 PM, James Robinson jam...@google.com wrote:



 On Wed, Jun 19, 2013 at 3:24 PM, Kenneth Russell k...@google.com wrote:

 On Wed, Jun 19, 2013 at 3:06 PM, James Robinson jam...@google.com wrote:
  On Wed, Jun 19, 2013 at 3:04 PM, Kenneth Russell k...@google.com wrote:
 
  supportsContext() can give a much more accurate answer than
  !!window.WebGLRenderingContext. I can only speak for Chromium, but in
  that browser, it can take into account factors such as whether the GPU
  sub-process was able to start, whether WebGL is blacklisted on the
  current card, whether WebGL is disabled on the current domain due to
  previous GPU resets, and whether WebGL initialization succeeded on any
  other page. All of these checks can be done without the heavyweight
  operation of actually creating an OpenGL context.
 
 
  That's true, but the answer still doesn't promise anything about what
  getContext() will do.  It may still return null and code will have to
  check
  for that.  What's the use case for calling supportsContext() without
  calling
  getContext()?

 Any application which has a complex set of fallback paths. For example,

   - Preference 1: supportsContext('webgl', { softwareRendered: true })
   - Preference 2: supportsContext('2d', { gpuAccelerated: true })
   - Preference 3: supportsContext('webgl', { softwareRendered: false })
   - Fallback: 2D canvas


 I'm assuming you have (1) and (3) flipped here and both supportsContext()
 and getContext() support additional attributes to dictate whether a
 software-provided context can be supplied.  In that case, in order to write
 correct code I'd still have to attempt to fetch the contexts before using
 them, i.e.:

 var ctx = canvas.getContext('webgl', { 'allowSoftware': false});
 if (ctx) {
   doPreference1(ctx);
   return;
 }
 ctx = canvas.getContext('2d', {'allowSoftware': false});
 if (ctx) {
   doPreference2(ctx);
 // etc

 how could I simplify this code using supportsContext() ?



 I agree that ideally, if supportsContext returns true then -- without
 any other state changes that might affect supportsContext's result --
 getContext should return a valid rendering context.


 It seems overwhelmingly likely that one of the state changes that might
 affect the result will be attempting to instantiate a real context.

In my experience, in Chromium, creation of the underlying OpenGL
context for a WebGLRenderingContext almost never fails in isolation.
Instead, more general failures happen such as the GPU process failing
to boot, or creation of all OpenGL contexts (including the
compositor's) failing. These failures would be detected before the app
calls supportsContext('webgl'). For this reason I believe
supportsContext's answer can be highly accurate in almost every
situation.


 It's simply
 impossible to guarantee this correspondence 100% of the time, but if
 supportsContext's spec were tightened somehow, and conformance tests
 were added which asserted consistent results between supportsContext
 and getContext, would that address your concern?


 I don't see how supportsContext() could be as accurate as getContext()
 without doing all of the work getContext() does.  If it's not 100% accurate,
 when is it useful?

This is a specious question. My point is that the answer can be
accurate enough to be useful, and I'm personally willing to sign up to
make the implementation follow a stricter spec.

-Ken


 - James




 -Ken

Re: [whatwg] Challenging canvas.supportsContext