From baj...@ Mon Oct 7 11:38:09 2013 From: baj...@ (Brandon Jones) Date: Mon, 7 Oct 2013 11:38:09 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation Message-ID: Looking at the current WebGL 2 spec ( http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a concern about the proposed method of context creation. It states: *"If getContext() was invoked with a second argument, options, and options has a version property with the value "2", then context will be a WebGL2RenderingContext object. Otherwise context is a WebGLRenderingContext object."* Which is nice and sensible but has a non-obvious drawback. If a page attempts to create a WebGL 2 context on an older browser which does not support the version attribute, the version will probably be ignored and a valid WebGL 1 context will be returned. As such, rather than a simple null check as has been the case thus far the code required to test for WebGL 2 support becomes: var gl = canvas.getContext("webgl", {version: 2}); if (!gl) { /* error */ } var attrs = gl.getContextAttributes(); if (!('version' in attrs) || attrs.version != 2) { /* error */ } It's also fairly undesirable that context creation will act differently depending on browser version. Chrome N will return a WebGL 1 context when a WebGL 2 context is requested, but Chrome N+1 will return null if the context is requested but not supported. The clearest way that I can see to avoid this issue is to use a different contextId string, canvas.getContext("webgl2"), which would consistently return null for when WebGL 2 is not supported on all browser versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Mon Oct 7 12:13:28 2013 From: ben...@ (Ben Vanik) Date: Mon, 7 Oct 2013 12:13:28 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: Message-ID: I'd prefer a new contextId - that's way clearer - it also makes having divergent context creation arguments/etc easier, as they can live in the spec of the context type that uses them. On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones wrote: > Looking at the current WebGL 2 spec ( > http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a > concern about the proposed method of context creation. It states: > > *"If getContext() was invoked with a second argument, options, and > options has a version property with the value "2", then context will be a > WebGL2RenderingContext object. Otherwise context is a WebGLRenderingContext > object."* > > Which is nice and sensible but has a non-obvious drawback. If a page > attempts to create a WebGL 2 context on an older browser which does not > support the version attribute, the version will probably be ignored and a > valid WebGL 1 context will be returned. As such, rather than a simple null > check as has been the case thus far the code required to test for WebGL 2 > support becomes: > > var gl = canvas.getContext("webgl", {version: 2}); > if (!gl) { /* error */ } > var attrs = gl.getContextAttributes(); > if (!('version' in attrs) || attrs.version != 2) { /* error */ } > > It's also fairly undesirable that context creation will act differently > depending on browser version. Chrome N will return a WebGL 1 context when a > WebGL 2 context is requested, but Chrome N+1 will return null if the > context is requested but not supported. > > The clearest way that I can see to avoid this issue is to use a different > contextId string, canvas.getContext("webgl2"), which would consistently > return null for when WebGL 2 is not supported on all browser versions. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Mon Oct 7 12:22:12 2013 From: zmo...@ (Zhenyao Mo) Date: Mon, 7 Oct 2013 12:22:12 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: Message-ID: Probably do not fallback to webgl1 context if webgl2 context is queried but unavailable? On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones wrote: > Looking at the current WebGL 2 spec > (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a concern > about the proposed method of context creation. It states: > > "If getContext() was invoked with a second argument, options, and options > has a version property with the value "2", then context will be a > WebGL2RenderingContext object. Otherwise context is a WebGLRenderingContext > object." > > Which is nice and sensible but has a non-obvious drawback. If a page > attempts to create a WebGL 2 context on an older browser which does not > support the version attribute, the version will probably be ignored and a > valid WebGL 1 context will be returned. As such, rather than a simple null > check as has been the case thus far the code required to test for WebGL 2 > support becomes: > > var gl = canvas.getContext("webgl", {version: 2}); > if (!gl) { /* error */ } > var attrs = gl.getContextAttributes(); > if (!('version' in attrs) || attrs.version != 2) { /* error */ } > > It's also fairly undesirable that context creation will act differently > depending on browser version. Chrome N will return a WebGL 1 context when a > WebGL 2 context is requested, but Chrome N+1 will return null if the context > is requested but not supported. > > The clearest way that I can see to avoid this issue is to use a different > contextId string, canvas.getContext("webgl2"), which would consistently > return null for when WebGL 2 is not supported on all browser versions. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Mon Oct 7 12:35:30 2013 From: baj...@ (Brandon Jones) Date: Mon, 7 Oct 2013 12:35:30 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: Message-ID: The problem is that older browsers (think Chrome 24 or Firefox 18 or similar) will not have any reason to look for the version attribute, and thus will create a Webgl 1 context no matter what. That's not a fallback, it's just normal API behavior. On Mon, Oct 7, 2013 at 12:22 PM, Zhenyao Mo wrote: > Probably do not fallback to webgl1 context if webgl2 context is > queried but unavailable? > > On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones wrote: > > Looking at the current WebGL 2 spec > > (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a > concern > > about the proposed method of context creation. It states: > > > > "If getContext() was invoked with a second argument, options, and options > > has a version property with the value "2", then context will be a > > WebGL2RenderingContext object. Otherwise context is a > WebGLRenderingContext > > object." > > > > Which is nice and sensible but has a non-obvious drawback. If a page > > attempts to create a WebGL 2 context on an older browser which does not > > support the version attribute, the version will probably be ignored and a > > valid WebGL 1 context will be returned. As such, rather than a simple > null > > check as has been the case thus far the code required to test for WebGL 2 > > support becomes: > > > > var gl = canvas.getContext("webgl", {version: 2}); > > if (!gl) { /* error */ } > > var attrs = gl.getContextAttributes(); > > if (!('version' in attrs) || attrs.version != 2) { /* error */ } > > > > It's also fairly undesirable that context creation will act differently > > depending on browser version. Chrome N will return a WebGL 1 context > when a > > WebGL 2 context is requested, but Chrome N+1 will return null if the > context > > is requested but not supported. > > > > The clearest way that I can see to avoid this issue is to use a different > > contextId string, canvas.getContext("webgl2"), which would consistently > > return null for when WebGL 2 is not supported on all browser versions. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Oct 7 12:42:28 2013 From: bja...@ (Benoit Jacob) Date: Mon, 07 Oct 2013 15:42:28 -0400 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: Message-ID: <52530EA4.5070606@mozilla.com> Isn't that an excellent reason to make webgl2 a separate context id, not an attribute on the webgl context id ? Benoit On 13-10-07 03:35 PM, Brandon Jones wrote: > The problem is that older browsers (think Chrome 24 or Firefox 18 or > similar) will not have any reason to look for the version attribute, > and thus will create a Webgl 1 context no matter what. That's not a > fallback, it's just normal API behavior. > > > On Mon, Oct 7, 2013 at 12:22 PM, Zhenyao Mo > wrote: > > Probably do not fallback to webgl1 context if webgl2 context is > queried but unavailable? > > On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones > wrote: > > Looking at the current WebGL 2 spec > > (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I > have a concern > > about the proposed method of context creation. It states: > > > > "If getContext() was invoked with a second argument, options, > and options > > has a version property with the value "2", then context will be a > > WebGL2RenderingContext object. Otherwise context is a > WebGLRenderingContext > > object." > > > > Which is nice and sensible but has a non-obvious drawback. If a page > > attempts to create a WebGL 2 context on an older browser which > does not > > support the version attribute, the version will probably be > ignored and a > > valid WebGL 1 context will be returned. As such, rather than a > simple null > > check as has been the case thus far the code required to test > for WebGL 2 > > support becomes: > > > > var gl = canvas.getContext("webgl", {version: 2}); > > if (!gl) { /* error */ } > > var attrs = gl.getContextAttributes(); > > if (!('version' in attrs) || attrs.version != 2) { /* error */ } > > > > It's also fairly undesirable that context creation will act > differently > > depending on browser version. Chrome N will return a WebGL 1 > context when a > > WebGL 2 context is requested, but Chrome N+1 will return null if > the context > > is requested but not supported. > > > > The clearest way that I can see to avoid this issue is to use a > different > > contextId string, canvas.getContext("webgl2"), which would > consistently > > return null for when WebGL 2 is not supported on all browser > versions. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Mon Oct 7 12:42:56 2013 From: zmo...@ (Zhenyao Mo) Date: Mon, 7 Oct 2013 12:42:56 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: Message-ID: I see your point. In order to make the webgl2 context creation fail if it's not supported, we have to use a context name that's not recognized. Then a different context name like "webgl2" seems a good idea to me. On Mon, Oct 7, 2013 at 12:35 PM, Brandon Jones wrote: > The problem is that older browsers (think Chrome 24 or Firefox 18 or > similar) will not have any reason to look for the version attribute, and > thus will create a Webgl 1 context no matter what. That's not a fallback, > it's just normal API behavior. > > > On Mon, Oct 7, 2013 at 12:22 PM, Zhenyao Mo wrote: >> >> Probably do not fallback to webgl1 context if webgl2 context is >> queried but unavailable? >> >> On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones wrote: >> > Looking at the current WebGL 2 spec >> > (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a >> > concern >> > about the proposed method of context creation. It states: >> > >> > "If getContext() was invoked with a second argument, options, and >> > options >> > has a version property with the value "2", then context will be a >> > WebGL2RenderingContext object. Otherwise context is a >> > WebGLRenderingContext >> > object." >> > >> > Which is nice and sensible but has a non-obvious drawback. If a page >> > attempts to create a WebGL 2 context on an older browser which does not >> > support the version attribute, the version will probably be ignored and >> > a >> > valid WebGL 1 context will be returned. As such, rather than a simple >> > null >> > check as has been the case thus far the code required to test for WebGL >> > 2 >> > support becomes: >> > >> > var gl = canvas.getContext("webgl", {version: 2}); >> > if (!gl) { /* error */ } >> > var attrs = gl.getContextAttributes(); >> > if (!('version' in attrs) || attrs.version != 2) { /* error */ } >> > >> > It's also fairly undesirable that context creation will act differently >> > depending on browser version. Chrome N will return a WebGL 1 context >> > when a >> > WebGL 2 context is requested, but Chrome N+1 will return null if the >> > context >> > is requested but not supported. >> > >> > The clearest way that I can see to avoid this issue is to use a >> > different >> > contextId string, canvas.getContext("webgl2"), which would consistently >> > return null for when WebGL 2 is not supported on all browser versions. > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Mon Oct 7 15:48:52 2013 From: jgi...@ (Jeff Gilbert) Date: Mon, 7 Oct 2013 15:48:52 -0700 (PDT) Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: Message-ID: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Mozilla's prototype uses a new 'webgl2' context creation id, which seems like the obvious solution. -Jeff ----- Original Message ----- From: "Zhenyao Mo" To: "Brandon Jones" Cc: "public webgl" Sent: Monday, October 7, 2013 12:42:56 PM Subject: Re: [Public WebGL] False positives with WebGL 2 context creation I see your point. In order to make the webgl2 context creation fail if it's not supported, we have to use a context name that's not recognized. Then a different context name like "webgl2" seems a good idea to me. On Mon, Oct 7, 2013 at 12:35 PM, Brandon Jones wrote: > The problem is that older browsers (think Chrome 24 or Firefox 18 or > similar) will not have any reason to look for the version attribute, and > thus will create a Webgl 1 context no matter what. That's not a fallback, > it's just normal API behavior. > > > On Mon, Oct 7, 2013 at 12:22 PM, Zhenyao Mo wrote: >> >> Probably do not fallback to webgl1 context if webgl2 context is >> queried but unavailable? >> >> On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones wrote: >> > Looking at the current WebGL 2 spec >> > (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a >> > concern >> > about the proposed method of context creation. It states: >> > >> > "If getContext() was invoked with a second argument, options, and >> > options >> > has a version property with the value "2", then context will be a >> > WebGL2RenderingContext object. Otherwise context is a >> > WebGLRenderingContext >> > object." >> > >> > Which is nice and sensible but has a non-obvious drawback. If a page >> > attempts to create a WebGL 2 context on an older browser which does not >> > support the version attribute, the version will probably be ignored and >> > a >> > valid WebGL 1 context will be returned. As such, rather than a simple >> > null >> > check as has been the case thus far the code required to test for WebGL >> > 2 >> > support becomes: >> > >> > var gl = canvas.getContext("webgl", {version: 2}); >> > if (!gl) { /* error */ } >> > var attrs = gl.getContextAttributes(); >> > if (!('version' in attrs) || attrs.version != 2) { /* error */ } >> > >> > It's also fairly undesirable that context creation will act differently >> > depending on browser version. Chrome N will return a WebGL 1 context >> > when a >> > WebGL 2 context is requested, but Chrome N+1 will return null if the >> > context >> > is requested but not supported. >> > >> > The clearest way that I can see to avoid this issue is to use a >> > different >> > contextId string, canvas.getContext("webgl2"), which would consistently >> > return null for when WebGL 2 is not supported on all browser versions. > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Tue Oct 8 12:51:31 2013 From: baj...@ (Brandon Jones) Date: Tue, 8 Oct 2013 12:51:31 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: Seems like there's pretty solid consensus around using a "webgl2" contextId. I've submitted a pull request to make the change in the spec. https://github.com/KhronosGroup/WebGL/pull/394 On Mon, Oct 7, 2013 at 3:48 PM, Jeff Gilbert wrote: > Mozilla's prototype uses a new 'webgl2' context creation id, which seems > like the obvious solution. > > -Jeff > > ----- Original Message ----- > From: "Zhenyao Mo" > To: "Brandon Jones" > Cc: "public webgl" > Sent: Monday, October 7, 2013 12:42:56 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > > I see your point. In order to make the webgl2 context creation fail > if it's not supported, we have to use a context name that's not > recognized. > > Then a different context name like "webgl2" seems a good idea to me. > > On Mon, Oct 7, 2013 at 12:35 PM, Brandon Jones wrote: > > The problem is that older browsers (think Chrome 24 or Firefox 18 or > > similar) will not have any reason to look for the version attribute, and > > thus will create a Webgl 1 context no matter what. That's not a fallback, > > it's just normal API behavior. > > > > > > On Mon, Oct 7, 2013 at 12:22 PM, Zhenyao Mo wrote: > >> > >> Probably do not fallback to webgl1 context if webgl2 context is > >> queried but unavailable? > >> > >> On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones > wrote: > >> > Looking at the current WebGL 2 spec > >> > (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a > >> > concern > >> > about the proposed method of context creation. It states: > >> > > >> > "If getContext() was invoked with a second argument, options, and > >> > options > >> > has a version property with the value "2", then context will be a > >> > WebGL2RenderingContext object. Otherwise context is a > >> > WebGLRenderingContext > >> > object." > >> > > >> > Which is nice and sensible but has a non-obvious drawback. If a page > >> > attempts to create a WebGL 2 context on an older browser which does > not > >> > support the version attribute, the version will probably be ignored > and > >> > a > >> > valid WebGL 1 context will be returned. As such, rather than a simple > >> > null > >> > check as has been the case thus far the code required to test for > WebGL > >> > 2 > >> > support becomes: > >> > > >> > var gl = canvas.getContext("webgl", {version: 2}); > >> > if (!gl) { /* error */ } > >> > var attrs = gl.getContextAttributes(); > >> > if (!('version' in attrs) || attrs.version != 2) { /* error */ } > >> > > >> > It's also fairly undesirable that context creation will act > differently > >> > depending on browser version. Chrome N will return a WebGL 1 context > >> > when a > >> > WebGL 2 context is requested, but Chrome N+1 will return null if the > >> > context > >> > is requested but not supported. > >> > > >> > The clearest way that I can see to avoid this issue is to use a > >> > different > >> > contextId string, canvas.getContext("webgl2"), which would > consistently > >> > return null for when WebGL 2 is not supported on all browser versions. > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Oct 8 13:20:14 2013 From: din...@ (Dean Jackson) Date: Wed, 09 Oct 2013 07:20:14 +1100 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: On 8 Oct 2013, at 9:48 am, Jeff Gilbert wrote: > > Mozilla's prototype uses a new 'webgl2' context creation id, which seems like the obvious solution. ?webgl2? or ?experimental-webgl2?? Have we decided whether or not to keep suggesting a prefix? Dean > > -Jeff > > ----- Original Message ----- > From: "Zhenyao Mo" > To: "Brandon Jones" > Cc: "public webgl" > Sent: Monday, October 7, 2013 12:42:56 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > > I see your point. In order to make the webgl2 context creation fail > if it's not supported, we have to use a context name that's not > recognized. > > Then a different context name like "webgl2" seems a good idea to me. > > On Mon, Oct 7, 2013 at 12:35 PM, Brandon Jones wrote: >> The problem is that older browsers (think Chrome 24 or Firefox 18 or >> similar) will not have any reason to look for the version attribute, and >> thus will create a Webgl 1 context no matter what. That's not a fallback, >> it's just normal API behavior. >> >> >> On Mon, Oct 7, 2013 at 12:22 PM, Zhenyao Mo wrote: >>> >>> Probably do not fallback to webgl1 context if webgl2 context is >>> queried but unavailable? >>> >>> On Mon, Oct 7, 2013 at 11:38 AM, Brandon Jones wrote: >>>> Looking at the current WebGL 2 spec >>>> (http://www.khronos.org/registry/webgl/specs/latest/2.0/), I have a >>>> concern >>>> about the proposed method of context creation. It states: >>>> >>>> "If getContext() was invoked with a second argument, options, and >>>> options >>>> has a version property with the value "2", then context will be a >>>> WebGL2RenderingContext object. Otherwise context is a >>>> WebGLRenderingContext >>>> object." >>>> >>>> Which is nice and sensible but has a non-obvious drawback. If a page >>>> attempts to create a WebGL 2 context on an older browser which does not >>>> support the version attribute, the version will probably be ignored and >>>> a >>>> valid WebGL 1 context will be returned. As such, rather than a simple >>>> null >>>> check as has been the case thus far the code required to test for WebGL >>>> 2 >>>> support becomes: >>>> >>>> var gl = canvas.getContext("webgl", {version: 2}); >>>> if (!gl) { /* error */ } >>>> var attrs = gl.getContextAttributes(); >>>> if (!('version' in attrs) || attrs.version != 2) { /* error */ } >>>> >>>> It's also fairly undesirable that context creation will act differently >>>> depending on browser version. Chrome N will return a WebGL 1 context >>>> when a >>>> WebGL 2 context is requested, but Chrome N+1 will return null if the >>>> context >>>> is requested but not supported. >>>> >>>> The clearest way that I can see to avoid this issue is to use a >>>> different >>>> contextId string, canvas.getContext("webgl2"), which would consistently >>>> return null for when WebGL 2 is not supported on all browser versions. >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Oct 8 16:03:11 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 8 Oct 2013 16:03:11 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: On Mon, Oct 7, 2013 at 3:48 PM, Jeff Gilbert wrote: > > Mozilla's prototype uses a new 'webgl2' context creation id, which seems like the obvious solution. I'd personally hoped to avoid updating the canvas spec every time a new version of WebGL came out, but perhaps this is inevitable. On Tue, Oct 8, 2013 at 1:20 PM, Dean Jackson wrote: > ?webgl2? or ?experimental-webgl2?? Have we decided whether or not to keep > suggesting a prefix? Good question. A browser definitely should not expose the "webgl2" context type by default until it passes the (still to be written) conformance tests. Since it seems that most browsers have a way to turn on experimental features nowadays, I think the spec should just define a "webgl2" context type, and that browsers shouldn't expose an "experimental-webgl2" context type at all. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From din...@ Tue Oct 8 20:04:55 2013 From: din...@ (Dean Jackson) Date: Wed, 09 Oct 2013 14:04:55 +1100 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: On 9 Oct 2013, at 10:03 am, Kenneth Russell wrote: > > On Mon, Oct 7, 2013 at 3:48 PM, Jeff Gilbert wrote: >> >> Mozilla's prototype uses a new 'webgl2' context creation id, which seems like the obvious solution. > > I'd personally hoped to avoid updating the canvas spec every time a > new version of WebGL came out, but perhaps this is inevitable. Me too. I don?t think the extra code is much of a burden, because you?re already writing an app that has two code paths if you?re using WebGL2 (or, you expect to fail if you don?t have WebGL2). Also, if you use probablySupportsContext you can detect this pretty early and avoid looking at getContextAttributes: canvas.probablySupportsContext(?webgl?, { version: 2 }) (Yes, I know you?ll *still* have to write code to handle failing cases) Brandon?s other point is interesting: > Chrome N will return a WebGL 1 context when a WebGL 2 context is requested, but Chrome N+1 will return null if the context is requested but not supported. It?s pretty easy to detect which type of context you got, since they are different interfaces. Again, a good app has to handle this already, especially if they explicitly asking for a WebGL 2 API. And many people will probably use a library that handles it all for them. But, I?m just expressing an opinion. I don?t feel too strongly. > On Tue, Oct 8, 2013 at 1:20 PM, Dean Jackson wrote: >> ?webgl2? or ?experimental-webgl2?? Have we decided whether or not to keep >> suggesting a prefix? > > Good question. A browser definitely should not expose the "webgl2" > context type by default until it passes the (still to be written) > conformance tests. > > Since it seems that most browsers have a way to turn on experimental > features nowadays, I think the spec should just define a "webgl2" > context type, and that browsers shouldn't expose an > "experimental-webgl2" context type at all. FWIW, I think the ?experimental? approach worked pretty well, but I seem to be in the minority these days w.r.t prefixing things. I don?t know about Firefox, but Blink and WebKit seem to be taking different approaches to experimental features. As Ken suggested, Blink?s approach is to protect things with runtime flags that the user must toggle. WebKit decided to enable things by default, but put them behind a prefix. There are downsides to both. In the former, you only get testing by people who have made the effort to find and switch the toggle. In the latter, you?re increasing the risk of exposing things to the Web too early (and thus making it harder to change later). Dean ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Oct 8 20:36:37 2013 From: bja...@ (Benoit Jacob) Date: Tue, 08 Oct 2013 23:36:37 -0400 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: <5254CF45.8020108@mozilla.com> On 13-10-08 11:04 PM, Dean Jackson wrote: > > On 9 Oct 2013, at 10:03 am, Kenneth Russell wrote: > >> On Mon, Oct 7, 2013 at 3:48 PM, Jeff Gilbert wrote: >>> Mozilla's prototype uses a new 'webgl2' context creation id, which seems like the obvious solution. >> I'd personally hoped to avoid updating the canvas spec every time a >> new version of WebGL came out, but perhaps this is inevitable. > Me too. I don?t think the extra code is much of a burden, because you?re > already writing an app that has two code paths if you?re using > WebGL2 (or, you expect to fail if you don?t have WebGL2). Also, does the canvas spec really need to have an exhaustive list of supported context ids? > Also, if you use probablySupportsContext you can detect this > pretty early and avoid looking at getContextAttributes: > > canvas.probablySupportsContext(?webgl?, { version: 2 }) For what it's worth, Mozilla has no plans at the moment --- for all I know, I can always be wrong --- to implement probablySupportsContext. > I don?t know about Firefox, but Blink and WebKit seem to be taking > different approaches to experimental features. As Ken suggested, > Blink?s approach is to protect things with runtime flags that the user > must toggle. WebKit decided to enable things by default, but put them > behind a prefix. Firefox is taking the runtime flags approach. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Tue Oct 8 20:51:32 2013 From: baj...@ (Brandon Jones) Date: Tue, 8 Oct 2013 20:51:32 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <5254CF45.8020108@mozilla.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> <5254CF45.8020108@mozilla.com> Message-ID: On Tue, Oct 8, 2013 at 8:36 PM, Benoit Jacob wrote: > For what it's worth, Mozilla has no plans at the moment --- for all I > know, I can always be wrong --- to implement probablySupportsContext. > There was some pushback when we proposed adding it to Chrome as well. It's not clear that we'll be adding it either. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Tue Oct 8 21:31:56 2013 From: baj...@ (Brandon Jones) Date: Tue, 8 Oct 2013 21:31:56 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: On Tue, Oct 8, 2013 at 8:04 PM, Dean Jackson wrote: > > I don?t think the extra code is much of a burden, because you?re > already writing an app that has two code paths if you?re using > WebGL2 (or, you expect to fail if you don?t have WebGL2). > [...] > It?s pretty easy to detect which type of context you got, since they are > different interfaces. Again, a good app has to handle this already, > especially if they explicitly asking for a WebGL 2 API. And > many people will probably use a library that handles it all for them. > I feel pretty strongly that if the user requests a WebGL2 context and the browser can't deliver one it should *always* return null to eliminate any confusion about the success/fail state. However, if we *do* decide to press on with the version context attribute instead of a new contextId I would request that we specify the behavior as such: If a version is specified in the context attributes the browser will first attempt to create a WebGL context matching that version number. If it cannot create a matching context, a context of the previous WebGL version should be attempted, and so on through version 1 at which point if no context can be created null is returned. I personally would find that to be a very awkward API to work with and am not in favor of it at all, but it has the benefit of consistent behavior across all browser version and a semi-plausible excuse for the users ("We give you a context that's as close as possible to your requested feature set.") --Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Oct 9 10:48:29 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 9 Oct 2013 10:48:29 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones wrote: > > I feel pretty strongly that if the user requests a WebGL2 context and the > browser can't deliver one it should always return null to eliminate any > confusion about the success/fail state. Agreed -- this is the way OpenGL context creation works, and to provide the best evolutionary path for WebGL, I don't think context creation should fall back to earlier versions. I guess I'd hoped that browsers would start paying attention to the "version" attribute even before they started supporting WebGL 2, so that the "webgl" context type could continue to be used. If that became the case in, for example, shipping versions of Firefox, Safari, IE and Chrome, would that address the concerns? -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Wed Oct 9 11:32:03 2013 From: baj...@ (Brandon Jones) Date: Wed, 9 Oct 2013 11:32:03 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: Unfortunately I think that would actually aggravate the problem. Say we got version support (without webgl2) into Chrome 31, and then WebGL2 support starts showing up in Chrome Canary 33. Developers will build a sample app, test it against Canary (gets a context) and test it against stable (gets null, developer falls back to WebGL1) Great! Moving on! After releasing their app, however, they start hearing from people running Chrome 30, 29, 28, etc (due to business policy, broken upgrade system, malware, whatever) who complain that rather than getting a friendly "not supported" screen or WebGL 1 fallback the app simply fails, spewing back a console full of "missing function" errors. This is really an easy problem to fix, but 99% of developers wouldn't even know it needed fixing until they hit it in the wild. No amount of developer outreach on our part is likely to change that, and it will be one of those "Why the hell did they think this was a good idea?" things that developers love to Grumble about. This is why I would prefer a crappy solution that's completely consistent vs. a "clean" solution that acts differently across browser versions. On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: > On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones wrote: > > > > I feel pretty strongly that if the user requests a WebGL2 context and the > > browser can't deliver one it should always return null to eliminate any > > confusion about the success/fail state. > > Agreed -- this is the way OpenGL context creation works, and to > provide the best evolutionary path for WebGL, I don't think context > creation should fall back to earlier versions. > > I guess I'd hoped that browsers would start paying attention to the > "version" attribute even before they started supporting WebGL 2, so > that the "webgl" context type could continue to be used. > > If that became the case in, for example, shipping versions of Firefox, > Safari, IE and Chrome, would that address the concerns? > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Wed Oct 9 12:33:07 2013 From: din...@ (Dean Jackson) Date: Thu, 10 Oct 2013 06:33:07 +1100 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> Message-ID: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> If we do expose a new ?webgl2? context type, we?ll need to coordinate with the HTML WG (W3C + WHATWG). It?s not really our decision alone. Dean On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > Unfortunately I think that would actually aggravate the problem. Say we got version support (without webgl2) into Chrome 31, and then WebGL2 support starts showing up in Chrome Canary 33. Developers will build a sample app, test it against Canary (gets a context) and test it against stable (gets null, developer falls back to WebGL1) Great! Moving on! > > After releasing their app, however, they start hearing from people running Chrome 30, 29, 28, etc (due to business policy, broken upgrade system, malware, whatever) who complain that rather than getting a friendly "not supported" screen or WebGL 1 fallback the app simply fails, spewing back a console full of "missing function" errors. > > This is really an easy problem to fix, but 99% of developers wouldn't even know it needed fixing until they hit it in the wild. No amount of developer outreach on our part is likely to change that, and it will be one of those "Why the hell did they think this was a good idea?" things that developers love to Grumble about. This is why I would prefer a crappy solution that's completely consistent vs. a "clean" solution that acts differently across browser versions. > > > On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: > On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones wrote: > > > > I feel pretty strongly that if the user requests a WebGL2 context and the > > browser can't deliver one it should always return null to eliminate any > > confusion about the success/fail state. > > Agreed -- this is the way OpenGL context creation works, and to > provide the best evolutionary path for WebGL, I don't think context > creation should fall back to earlier versions. > > I guess I'd hoped that browsers would start paying attention to the > "version" attribute even before they started supporting WebGL 2, so > that the "webgl" context type could continue to be used. > > If that became the case in, for example, shipping versions of Firefox, > Safari, IE and Chrome, would that address the concerns? > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Oct 9 13:03:06 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 9 Oct 2013 13:03:06 -0700 (PDT) Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> Message-ID: <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> FWIW, we still technically haven't specced 'experimental-webgl', which has indeed created a bug which still needs to be resolved. (cross-contextid getContext for webgl) If I remember correctly, the amount of coordination required here would be pretty low. We should just say "Hey, we're doing X", and they'll document it in the canvas spec. -Jeff ----- Original Message ----- From: "Dean Jackson" To: "Brandon Jones" Cc: "Kenneth Russell" , "Jeff Gilbert" , "Zhenyao Mo" , "public webgl" Sent: Wednesday, October 9, 2013 12:33:07 PM Subject: Re: [Public WebGL] False positives with WebGL 2 context creation If we do expose a new ?webgl2? context type, we?ll need to coordinate with the HTML WG (W3C + WHATWG). It?s not really our decision alone. Dean On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > Unfortunately I think that would actually aggravate the problem. Say we got version support (without webgl2) into Chrome 31, and then WebGL2 support starts showing up in Chrome Canary 33. Developers will build a sample app, test it against Canary (gets a context) and test it against stable (gets null, developer falls back to WebGL1) Great! Moving on! > > After releasing their app, however, they start hearing from people running Chrome 30, 29, 28, etc (due to business policy, broken upgrade system, malware, whatever) who complain that rather than getting a friendly "not supported" screen or WebGL 1 fallback the app simply fails, spewing back a console full of "missing function" errors. > > This is really an easy problem to fix, but 99% of developers wouldn't even know it needed fixing until they hit it in the wild. No amount of developer outreach on our part is likely to change that, and it will be one of those "Why the hell did they think this was a good idea?" things that developers love to Grumble about. This is why I would prefer a crappy solution that's completely consistent vs. a "clean" solution that acts differently across browser versions. > > > On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: > On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones wrote: > > > > I feel pretty strongly that if the user requests a WebGL2 context and the > > browser can't deliver one it should always return null to eliminate any > > confusion about the success/fail state. > > Agreed -- this is the way OpenGL context creation works, and to > provide the best evolutionary path for WebGL, I don't think context > creation should fall back to earlier versions. > > I guess I'd hoped that browsers would start paying attention to the > "version" attribute even before they started supporting WebGL 2, so > that the "webgl" context type could continue to be used. > > If that became the case in, for example, shipping versions of Firefox, > Safari, IE and Chrome, would that address the concerns? > > -Ken > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From din...@ Wed Oct 9 13:27:54 2013 From: din...@ (Dean Jackson) Date: Thu, 10 Oct 2013 07:27:54 +1100 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> Message-ID: <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> On 10 Oct 2013, at 7:03 am, Jeff Gilbert wrote: > FWIW, we still technically haven't specced 'experimental-webgl', which has indeed created a bug which still needs to be resolved. (cross-contextid getContext for webgl) > > If I remember correctly, the amount of coordination required here would be pretty low. We should just say "Hey, we're doing X", and they'll document it in the canvas spec. Not completely. There is a list public-script-coord at W3C - they might have some opinions on new context names vs option attributes. I?m still not sure a new context name is worth it. var isWebGL2 = ?WebGL2RenderingContext? in window; var gl = canvas.getContext(?webgl?, { version: (isWebGL2 ? 2 : 1) }); versus var isWebGL2 = true; var gl = canvas.getContext(?webgl2?); if (!gl) { gl = canvas.getContext(?webgl?); isWebGL2 = false; } (many other ways to write this of course) There will be many more places in my app where I have to decide to use WebGL2 or WebGL1 API entry points. e.g. I?ll have to map drawElementsInstancedANGLE to drawElementsInstanced (not to mention querying the extension etc). I think the amount of code to do that will far outweigh the extra lines for creating a context. Dean > > -Jeff > > ----- Original Message ----- > From: "Dean Jackson" > To: "Brandon Jones" > Cc: "Kenneth Russell" , "Jeff Gilbert" , "Zhenyao Mo" , "public webgl" > Sent: Wednesday, October 9, 2013 12:33:07 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > If we do expose a new ?webgl2? context type, we?ll need to coordinate with the HTML WG (W3C + WHATWG). It?s not really our decision alone. > > Dean > > On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > >> Unfortunately I think that would actually aggravate the problem. Say we got version support (without webgl2) into Chrome 31, and then WebGL2 support starts showing up in Chrome Canary 33. Developers will build a sample app, test it against Canary (gets a context) and test it against stable (gets null, developer falls back to WebGL1) Great! Moving on! >> >> After releasing their app, however, they start hearing from people running Chrome 30, 29, 28, etc (due to business policy, broken upgrade system, malware, whatever) who complain that rather than getting a friendly "not supported" screen or WebGL 1 fallback the app simply fails, spewing back a console full of "missing function" errors. >> >> This is really an easy problem to fix, but 99% of developers wouldn't even know it needed fixing until they hit it in the wild. No amount of developer outreach on our part is likely to change that, and it will be one of those "Why the hell did they think this was a good idea?" things that developers love to Grumble about. This is why I would prefer a crappy solution that's completely consistent vs. a "clean" solution that acts differently across browser versions. >> >> >> On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: >> On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones wrote: >>> >>> I feel pretty strongly that if the user requests a WebGL2 context and the >>> browser can't deliver one it should always return null to eliminate any >>> confusion about the success/fail state. >> >> Agreed -- this is the way OpenGL context creation works, and to >> provide the best evolutionary path for WebGL, I don't think context >> creation should fall back to earlier versions. >> >> I guess I'd hoped that browsers would start paying attention to the >> "version" attribute even before they started supporting WebGL 2, so >> that the "webgl" context type could continue to be used. >> >> If that became the case in, for example, shipping versions of Firefox, >> Safari, IE and Chrome, would that address the concerns? >> >> -Ken >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Wed Oct 9 13:42:57 2013 From: baj...@ (Brandon Jones) Date: Wed, 9 Oct 2013 13:42:57 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> Message-ID: The presence of the WebGL2RenderingContext type does not guarantee that creation of that context type will succeed. As such, the code snippet would actually be something like this: var gl = null; var isWebGL2 = ?WebGL2RenderingContext? in window; if (isWebGL2) gl = canvas.getContext(?webgl?, { version: 2 }); if (!gl) { gl = canvas.getContext(?webgl?); isWebGL2 = false; } But really I feel like the bigger issue here is that the above is very unintuitive, especially when compared to the current behavior of WebGL 1 (Failure always returns null). Nobody would think to write that unless they copied it from a tutorial or had already run into the bug. If we have to opportunity to create an API that "just works", and all it takes is some cooperation with the other WGs, I'm not sure why we would go out of our way to avoid it. On Wed, Oct 9, 2013 at 1:27 PM, Dean Jackson wrote: > > On 10 Oct 2013, at 7:03 am, Jeff Gilbert wrote: > > > FWIW, we still technically haven't specced 'experimental-webgl', which > has indeed created a bug which still needs to be resolved. (cross-contextid > getContext for webgl) > > > > If I remember correctly, the amount of coordination required here would > be pretty low. We should just say "Hey, we're doing X", and they'll > document it in the canvas spec. > > Not completely. There is a list public-script-coord at W3C - they might > have some opinions on new context names vs option attributes. > > I?m still not sure a new context name is worth it. > > var isWebGL2 = ?WebGL2RenderingContext? in window; > var gl = canvas.getContext(?webgl?, { version: (isWebGL2 ? 2 : 1) }); > > versus > > var isWebGL2 = true; > var gl = canvas.getContext(?webgl2?); > if (!gl) { > gl = canvas.getContext(?webgl?); > isWebGL2 = false; > } > > (many other ways to write this of course) > > There will be many more places in my app where I have to decide to use > WebGL2 or WebGL1 API entry points. e.g. I?ll have to map > drawElementsInstancedANGLE to drawElementsInstanced (not to mention > querying the extension etc). I think the amount of code to do that will far > outweigh the extra lines for creating a context. > > Dean > > > > > -Jeff > > > > ----- Original Message ----- > > From: "Dean Jackson" > > To: "Brandon Jones" > > Cc: "Kenneth Russell" , "Jeff Gilbert" < > jgilbert...@>, "Zhenyao Mo" , "public webgl" < > public_webgl...@> > > Sent: Wednesday, October 9, 2013 12:33:07 PM > > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > > > If we do expose a new ?webgl2? context type, we?ll need to coordinate > with the HTML WG (W3C + WHATWG). It?s not really our decision alone. > > > > Dean > > > > On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > > > >> Unfortunately I think that would actually aggravate the problem. Say we > got version support (without webgl2) into Chrome 31, and then WebGL2 > support starts showing up in Chrome Canary 33. Developers will build a > sample app, test it against Canary (gets a context) and test it against > stable (gets null, developer falls back to WebGL1) Great! Moving on! > >> > >> After releasing their app, however, they start hearing from people > running Chrome 30, 29, 28, etc (due to business policy, broken upgrade > system, malware, whatever) who complain that rather than getting a friendly > "not supported" screen or WebGL 1 fallback the app simply fails, spewing > back a console full of "missing function" errors. > >> > >> This is really an easy problem to fix, but 99% of developers wouldn't > even know it needed fixing until they hit it in the wild. No amount of > developer outreach on our part is likely to change that, and it will be one > of those "Why the hell did they think this was a good idea?" things that > developers love to Grumble about. This is why I would prefer a crappy > solution that's completely consistent vs. a "clean" solution that acts > differently across browser versions. > >> > >> > >> On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell > wrote: > >> On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones > wrote: > >>> > >>> I feel pretty strongly that if the user requests a WebGL2 context and > the > >>> browser can't deliver one it should always return null to eliminate any > >>> confusion about the success/fail state. > >> > >> Agreed -- this is the way OpenGL context creation works, and to > >> provide the best evolutionary path for WebGL, I don't think context > >> creation should fall back to earlier versions. > >> > >> I guess I'd hoped that browsers would start paying attention to the > >> "version" attribute even before they started supporting WebGL 2, so > >> that the "webgl" context type could continue to be used. > >> > >> If that became the case in, for example, shipping versions of Firefox, > >> Safari, IE and Chrome, would that address the concerns? > >> > >> -Ken > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Oct 9 14:05:53 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 9 Oct 2013 14:05:53 -0700 (PDT) Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> Message-ID: <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> This still falls apart if someone wants to have 'experimental-webgl2' return a WebGL2RenderingContext. (Our prototype does this, since it's a naive extrapolation from webgl1) I also don't think we should go out of our way to avoid coordination, given that this is only required once every few years. We sort of already missed the boat for `version`, unless we want to see this sort of non-intuitive glue code everywhere. -Jeff ----- Original Message ----- From: "Brandon Jones" To: "Dean Jackson" Cc: "Jeff Gilbert" , "Kenneth Russell" , "Zhenyao Mo" , "public webgl" Sent: Wednesday, October 9, 2013 1:42:57 PM Subject: Re: [Public WebGL] False positives with WebGL 2 context creation The presence of the WebGL2RenderingContext type does not guarantee that creation of that context type will succeed. As such, the code snippet would actually be something like this: var gl = null; var isWebGL2 = ?WebGL2RenderingContext? in window; if (isWebGL2) gl = canvas.getContext(?webgl?, { version: 2 }); if (!gl) { gl = canvas.getContext(?webgl?); isWebGL2 = false; } But really I feel like the bigger issue here is that the above is very unintuitive, especially when compared to the current behavior of WebGL 1 (Failure always returns null). Nobody would think to write that unless they copied it from a tutorial or had already run into the bug. If we have to opportunity to create an API that "just works", and all it takes is some cooperation with the other WGs, I'm not sure why we would go out of our way to avoid it. On Wed, Oct 9, 2013 at 1:27 PM, Dean Jackson wrote: > > On 10 Oct 2013, at 7:03 am, Jeff Gilbert wrote: > > > FWIW, we still technically haven't specced 'experimental-webgl', which > has indeed created a bug which still needs to be resolved. (cross-contextid > getContext for webgl) > > > > If I remember correctly, the amount of coordination required here would > be pretty low. We should just say "Hey, we're doing X", and they'll > document it in the canvas spec. > > Not completely. There is a list public-script-coord at W3C - they might > have some opinions on new context names vs option attributes. > > I?m still not sure a new context name is worth it. > > var isWebGL2 = ?WebGL2RenderingContext? in window; > var gl = canvas.getContext(?webgl?, { version: (isWebGL2 ? 2 : 1) }); > > versus > > var isWebGL2 = true; > var gl = canvas.getContext(?webgl2?); > if (!gl) { > gl = canvas.getContext(?webgl?); > isWebGL2 = false; > } > > (many other ways to write this of course) > > There will be many more places in my app where I have to decide to use > WebGL2 or WebGL1 API entry points. e.g. I?ll have to map > drawElementsInstancedANGLE to drawElementsInstanced (not to mention > querying the extension etc). I think the amount of code to do that will far > outweigh the extra lines for creating a context. > > Dean > > > > > -Jeff > > > > ----- Original Message ----- > > From: "Dean Jackson" > > To: "Brandon Jones" > > Cc: "Kenneth Russell" , "Jeff Gilbert" < > jgilbert...@>, "Zhenyao Mo" , "public webgl" < > public_webgl...@> > > Sent: Wednesday, October 9, 2013 12:33:07 PM > > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > > > If we do expose a new ?webgl2? context type, we?ll need to coordinate > with the HTML WG (W3C + WHATWG). It?s not really our decision alone. > > > > Dean > > > > On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > > > >> Unfortunately I think that would actually aggravate the problem. Say we > got version support (without webgl2) into Chrome 31, and then WebGL2 > support starts showing up in Chrome Canary 33. Developers will build a > sample app, test it against Canary (gets a context) and test it against > stable (gets null, developer falls back to WebGL1) Great! Moving on! > >> > >> After releasing their app, however, they start hearing from people > running Chrome 30, 29, 28, etc (due to business policy, broken upgrade > system, malware, whatever) who complain that rather than getting a friendly > "not supported" screen or WebGL 1 fallback the app simply fails, spewing > back a console full of "missing function" errors. > >> > >> This is really an easy problem to fix, but 99% of developers wouldn't > even know it needed fixing until they hit it in the wild. No amount of > developer outreach on our part is likely to change that, and it will be one > of those "Why the hell did they think this was a good idea?" things that > developers love to Grumble about. This is why I would prefer a crappy > solution that's completely consistent vs. a "clean" solution that acts > differently across browser versions. > >> > >> > >> On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell > wrote: > >> On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones > wrote: > >>> > >>> I feel pretty strongly that if the user requests a WebGL2 context and > the > >>> browser can't deliver one it should always return null to eliminate any > >>> confusion about the success/fail state. > >> > >> Agreed -- this is the way OpenGL context creation works, and to > >> provide the best evolutionary path for WebGL, I don't think context > >> creation should fall back to earlier versions. > >> > >> I guess I'd hoped that browsers would start paying attention to the > >> "version" attribute even before they started supporting WebGL 2, so > >> that the "webgl" context type could continue to be used. > >> > >> If that became the case in, for example, shipping versions of Firefox, > >> Safari, IE and Chrome, would that address the concerns? > >> > >> -Ken > >> > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ash...@ Thu Oct 10 05:38:58 2013 From: ash...@ (Ashley Gullen) Date: Thu, 10 Oct 2013 13:38:58 +0100 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> Message-ID: Long-term, it seems a little odd that a single canvas context type would have different context ids for each version. For example, there's no "2d" and then "2dv5" context for canvas2d v5: you just always ask for the "2d" context. The methods which are available depend on the version you got, which then I assume you'd feature detect for (e.g. check the ellipse function exists before you use it) - and you always only get the latest version, you can't ask for an older version of the 2d context. If WebGL were to work the same, why not drop the version attribute completely? Surely legacy apps designed to work with WebGL1 would keep working even if you gave them a WebGL2 context? Are there any cases where you'd deliberately want a WebGL1 context when WebGL2 was available? Then you could feature-detect or look at the VERSION parameter to check if WebGL2 features are available. Alternatively if the version is important, I guess the "?WebGL2RenderingContext? in window" check is a way of feature-detecting that the 'version' attribute of getContext will be understood. On 9 October 2013 22:05, Jeff Gilbert wrote: > > This still falls apart if someone wants to have 'experimental-webgl2' > return a WebGL2RenderingContext. (Our prototype does this, since it's a > naive extrapolation from webgl1) > > I also don't think we should go out of our way to avoid coordination, > given that this is only required once every few years. We sort of already > missed the boat for `version`, unless we want to see this sort of > non-intuitive glue code everywhere. > > -Jeff > > ----- Original Message ----- > From: "Brandon Jones" > To: "Dean Jackson" > Cc: "Jeff Gilbert" , "Kenneth Russell" < > kbr...@>, "Zhenyao Mo" , "public webgl" < > public_webgl...@> > Sent: Wednesday, October 9, 2013 1:42:57 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > The presence of the WebGL2RenderingContext type does not guarantee that > creation of that context type will succeed. As such, the code snippet would > actually be something like this: > > var gl = null; > var isWebGL2 = ?WebGL2RenderingContext? in window; > if (isWebGL2) > gl = canvas.getContext(?webgl?, { version: 2 }); > > if (!gl) { > gl = canvas.getContext(?webgl?); > isWebGL2 = false; > } > > But really I feel like the bigger issue here is that the above is very > unintuitive, especially when compared to the current behavior of WebGL 1 > (Failure always returns null). Nobody would think to write that unless they > copied it from a tutorial or had already run into the bug. > > If we have to opportunity to create an API that "just works", and all it > takes is some cooperation with the other WGs, I'm not sure why we would go > out of our way to avoid it. > > > On Wed, Oct 9, 2013 at 1:27 PM, Dean Jackson wrote: > > > > > On 10 Oct 2013, at 7:03 am, Jeff Gilbert wrote: > > > > > FWIW, we still technically haven't specced 'experimental-webgl', which > > has indeed created a bug which still needs to be resolved. > (cross-contextid > > getContext for webgl) > > > > > > If I remember correctly, the amount of coordination required here would > > be pretty low. We should just say "Hey, we're doing X", and they'll > > document it in the canvas spec. > > > > Not completely. There is a list public-script-coord at W3C - they might > > have some opinions on new context names vs option attributes. > > > > I?m still not sure a new context name is worth it. > > > > var isWebGL2 = ?WebGL2RenderingContext? in window; > > var gl = canvas.getContext(?webgl?, { version: (isWebGL2 ? 2 : 1) }); > > > > versus > > > > var isWebGL2 = true; > > var gl = canvas.getContext(?webgl2?); > > if (!gl) { > > gl = canvas.getContext(?webgl?); > > isWebGL2 = false; > > } > > > > (many other ways to write this of course) > > > > There will be many more places in my app where I have to decide to use > > WebGL2 or WebGL1 API entry points. e.g. I?ll have to map > > drawElementsInstancedANGLE to drawElementsInstanced (not to mention > > querying the extension etc). I think the amount of code to do that will > far > > outweigh the extra lines for creating a context. > > > > Dean > > > > > > > > -Jeff > > > > > > ----- Original Message ----- > > > From: "Dean Jackson" > > > To: "Brandon Jones" > > > Cc: "Kenneth Russell" , "Jeff Gilbert" < > > jgilbert...@>, "Zhenyao Mo" , "public webgl" < > > public_webgl...@> > > > Sent: Wednesday, October 9, 2013 12:33:07 PM > > > Subject: Re: [Public WebGL] False positives with WebGL 2 context > creation > > > > > > If we do expose a new ?webgl2? context type, we?ll need to coordinate > > with the HTML WG (W3C + WHATWG). It?s not really our decision alone. > > > > > > Dean > > > > > > On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > > > > > >> Unfortunately I think that would actually aggravate the problem. Say > we > > got version support (without webgl2) into Chrome 31, and then WebGL2 > > support starts showing up in Chrome Canary 33. Developers will build a > > sample app, test it against Canary (gets a context) and test it against > > stable (gets null, developer falls back to WebGL1) Great! Moving on! > > >> > > >> After releasing their app, however, they start hearing from people > > running Chrome 30, 29, 28, etc (due to business policy, broken upgrade > > system, malware, whatever) who complain that rather than getting a > friendly > > "not supported" screen or WebGL 1 fallback the app simply fails, spewing > > back a console full of "missing function" errors. > > >> > > >> This is really an easy problem to fix, but 99% of developers wouldn't > > even know it needed fixing until they hit it in the wild. No amount of > > developer outreach on our part is likely to change that, and it will be > one > > of those "Why the hell did they think this was a good idea?" things that > > developers love to Grumble about. This is why I would prefer a crappy > > solution that's completely consistent vs. a "clean" solution that acts > > differently across browser versions. > > >> > > >> > > >> On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell > > wrote: > > >> On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones > > wrote: > > >>> > > >>> I feel pretty strongly that if the user requests a WebGL2 context and > > the > > >>> browser can't deliver one it should always return null to eliminate > any > > >>> confusion about the success/fail state. > > >> > > >> Agreed -- this is the way OpenGL context creation works, and to > > >> provide the best evolutionary path for WebGL, I don't think context > > >> creation should fall back to earlier versions. > > >> > > >> I guess I'd hoped that browsers would start paying attention to the > > >> "version" attribute even before they started supporting WebGL 2, so > > >> that the "webgl" context type could continue to be used. > > >> > > >> If that became the case in, for example, shipping versions of Firefox, > > >> Safari, IE and Chrome, would that address the concerns? > > >> > > >> -Ken > > >> > > > > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Oct 10 06:04:57 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 10 Oct 2013 15:04:57 +0200 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> Message-ID: On Thu, Oct 10, 2013 at 2:38 PM, Ashley Gullen wrote: > If WebGL were to work the same, why not drop the version attribute > completely? Surely legacy apps designed to work with WebGL1 would keep > working even if you gave them a WebGL2 context? > OpenGL ES 3 Shading Language is not backwards compatible to 2. These two examples spring to mind: 1. varying T name; -> [smooth|flat] in|out [centroid] T name; 2. texture2D(sampler2D, vec2) -> texture(sampler{2,3}D, vec{2,3}) Shading language differences might be somewhat migitated by requirements to specify #version, although it might still break some programs that are cought unawares and might use erregious #version specifications. The ES 3 specification also marks legacy features for removal in future versions, that are currently supported in WebGL 1: - Fixed point vertex attributes - Luminance, alpha and luminance alpha formats. - Queryable shader range and precision - vector wise uniform limits Once ES 4 rolls out, those legacy features will not be supported, and so WebGL 3 would break with WebGL 2. The ES 3 specification also changes the runtime behavior in regards to cube map filtering specification, which might break some ES 2 (WebGL 1) programs. Backwards compatibility breaking changes are allowed by the Khronos charter in the act of legacy feature removal. The problem will not become any easier to solve if you defer to solve it until you must. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Oct 10 06:20:11 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 10 Oct 2013 15:20:11 +0200 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> Message-ID: I would prefer a behavior where canvas.getContext('webgl') always returns WebGL 1 (if supported, null if not) and would be synonmyous with canvas.getContext('webgl', {version:1}). The call canvas.getContext('webgl', {version:N}) would return a context corrseponding to N, and nothing else, or null. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Oct 10 16:05:35 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 10 Oct 2013 16:05:35 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> Message-ID: Today this topic was discussed at length during the WebGL WG's conference call. The deciding factor was the fact that if one calls canvas.getContext(contextType, { attrs }) twice in a row with different context creation attributes, the attributes are ignored during the second call. (This has been the specified behavior for a long time, after lengthy discussions before the WebGL 1.0 spec was released.) The consequence would be that canvas.getContext('webgl', { version: 2 }) could return either null, *or* a WebGL 1.0 context, if some other piece of code (a third-party library, perhaps) called getContext('webgl', { version: 1 }) in between two adjacent calls. On the other hand, defining the 'webgl2' context type uses the already-existing mechanism in the Canvas spec to prevent confusion between the two context types. If a request for the 'webgl2' context type returns null, it will always return null. The 2.0 editor's draft will be updated shortly to reflect this change. -Ken On Thu, Oct 10, 2013 at 6:20 AM, Florian B?sch wrote: > I would prefer a behavior where canvas.getContext('webgl') always returns > WebGL 1 (if supported, null if not) and would be synonmyous with > canvas.getContext('webgl', {version:1}). The call canvas.getContext('webgl', > {version:N}) would return a context corrseponding to N, and nothing else, or > null. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Thu Oct 10 16:16:14 2013 From: ben...@ (Ben Houston) Date: Thu, 10 Oct 2013 19:16:14 -0400 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> References: <384174909.2094861.1381186132777.JavaMail.zimbra@mozilla.com> <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> Message-ID: We got caught (and all other threejs users) with Firefox's recent removal of experimental-webgl in favor of just webgl in their mid Sept update. It would be nice too avoid this in the future. Sent from my phone. On Oct 9, 2013 4:07 PM, "Jeff Gilbert" wrote: > > FWIW, we still technically haven't specced 'experimental-webgl', which has > indeed created a bug which still needs to be resolved. (cross-contextid > getContext for webgl) > > If I remember correctly, the amount of coordination required here would be > pretty low. We should just say "Hey, we're doing X", and they'll document > it in the canvas spec. > > -Jeff > > ----- Original Message ----- > From: "Dean Jackson" > To: "Brandon Jones" > Cc: "Kenneth Russell" , "Jeff Gilbert" < > jgilbert...@>, "Zhenyao Mo" , "public webgl" < > public_webgl...@> > Sent: Wednesday, October 9, 2013 12:33:07 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > If we do expose a new ?webgl2? context type, we?ll need to coordinate with > the HTML WG (W3C + WHATWG). It?s not really our decision alone. > > Dean > > On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > > > Unfortunately I think that would actually aggravate the problem. Say we > got version support (without webgl2) into Chrome 31, and then WebGL2 > support starts showing up in Chrome Canary 33. Developers will build a > sample app, test it against Canary (gets a context) and test it against > stable (gets null, developer falls back to WebGL1) Great! Moving on! > > > > After releasing their app, however, they start hearing from people > running Chrome 30, 29, 28, etc (due to business policy, broken upgrade > system, malware, whatever) who complain that rather than getting a friendly > "not supported" screen or WebGL 1 fallback the app simply fails, spewing > back a console full of "missing function" errors. > > > > This is really an easy problem to fix, but 99% of developers wouldn't > even know it needed fixing until they hit it in the wild. No amount of > developer outreach on our part is likely to change that, and it will be one > of those "Why the hell did they think this was a good idea?" things that > developers love to Grumble about. This is why I would prefer a crappy > solution that's completely consistent vs. a "clean" solution that acts > differently across browser versions. > > > > > > On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: > > On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones > wrote: > > > > > > I feel pretty strongly that if the user requests a WebGL2 context and > the > > > browser can't deliver one it should always return null to eliminate any > > > confusion about the success/fail state. > > > > Agreed -- this is the way OpenGL context creation works, and to > > provide the best evolutionary path for WebGL, I don't think context > > creation should fall back to earlier versions. > > > > I guess I'd hoped that browsers would start paying attention to the > > "version" attribute even before they started supporting WebGL 2, so > > that the "webgl" context type could continue to be used. > > > > If that became the case in, for example, shipping versions of Firefox, > > Safari, IE and Chrome, would that address the concerns? > > > > -Ken > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Oct 10 16:25:22 2013 From: jgi...@ (Jeff Gilbert) Date: Thu, 10 Oct 2013 16:25:22 -0700 (PDT) Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> Message-ID: <2102006607.2488344.1381447522500.JavaMail.zimbra@mozilla.com> Firefox didn't remove experimental-webgl, and has no current plans to. (Though we are finally killing `moz-3d` requests) If you encounter this behavior, please file a bug. What we did do is return null if the requested contextId doesn't match the current contextId. Firefox doesn't currently treat 'webgl' and 'experimental-webgl' as aliases, since it's not specced that way, and the canvas spec for getContext requires that mismatched contextId requests return null. This means that `getContext('webgl') && getContext('experimental-webgl')` returns false on Firefox, whereas it returns true on Chrom(e|ium). We did add a warning to Firefox around then, so it's obvious when a page does this. -Jeff ----- Original Message ----- From: "Ben Houston" To: "Jeff Gilbert" Cc: "Zhenyao Mo" , "public webgl" , "Brandon Jones" , "Kenneth Russell" , "Dean Jackson" Sent: Thursday, October 10, 2013 4:16:14 PM Subject: Re: [Public WebGL] False positives with WebGL 2 context creation We got caught (and all other threejs users) with Firefox's recent removal of experimental-webgl in favor of just webgl in their mid Sept update. It would be nice too avoid this in the future. Sent from my phone. On Oct 9, 2013 4:07 PM, "Jeff Gilbert" wrote: > > FWIW, we still technically haven't specced 'experimental-webgl', which has > indeed created a bug which still needs to be resolved. (cross-contextid > getContext for webgl) > > If I remember correctly, the amount of coordination required here would be > pretty low. We should just say "Hey, we're doing X", and they'll document > it in the canvas spec. > > -Jeff > > ----- Original Message ----- > From: "Dean Jackson" > To: "Brandon Jones" > Cc: "Kenneth Russell" , "Jeff Gilbert" < > jgilbert...@>, "Zhenyao Mo" , "public webgl" < > public_webgl...@> > Sent: Wednesday, October 9, 2013 12:33:07 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > If we do expose a new ?webgl2? context type, we?ll need to coordinate with > the HTML WG (W3C + WHATWG). It?s not really our decision alone. > > Dean > > On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: > > > Unfortunately I think that would actually aggravate the problem. Say we > got version support (without webgl2) into Chrome 31, and then WebGL2 > support starts showing up in Chrome Canary 33. Developers will build a > sample app, test it against Canary (gets a context) and test it against > stable (gets null, developer falls back to WebGL1) Great! Moving on! > > > > After releasing their app, however, they start hearing from people > running Chrome 30, 29, 28, etc (due to business policy, broken upgrade > system, malware, whatever) who complain that rather than getting a friendly > "not supported" screen or WebGL 1 fallback the app simply fails, spewing > back a console full of "missing function" errors. > > > > This is really an easy problem to fix, but 99% of developers wouldn't > even know it needed fixing until they hit it in the wild. No amount of > developer outreach on our part is likely to change that, and it will be one > of those "Why the hell did they think this was a good idea?" things that > developers love to Grumble about. This is why I would prefer a crappy > solution that's completely consistent vs. a "clean" solution that acts > differently across browser versions. > > > > > > On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: > > On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones > wrote: > > > > > > I feel pretty strongly that if the user requests a WebGL2 context and > the > > > browser can't deliver one it should always return null to eliminate any > > > confusion about the success/fail state. > > > > Agreed -- this is the way OpenGL context creation works, and to > > provide the best evolutionary path for WebGL, I don't think context > > creation should fall back to earlier versions. > > > > I guess I'd hoped that browsers would start paying attention to the > > "version" attribute even before they started supporting WebGL 2, so > > that the "webgl" context type could continue to be used. > > > > If that became the case in, for example, shipping versions of Firefox, > > Safari, IE and Chrome, would that address the concerns? > > > > -Ken > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Oct 10 18:46:37 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 10 Oct 2013 18:46:37 -0700 Subject: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources In-Reply-To: <932FD1DC-A44A-43D6-B2FB-48F687114E1B@adobe.com> References: <5244158B.4060002@mozilla.com> <932FD1DC-A44A-43D6-B2FB-48F687114E1B@adobe.com> Message-ID: On Thu, Sep 26, 2013 at 2:31 PM, Max Vujovic wrote: > > On Sep 26, 2013, at 4:07 AM, Benoit Jacob wrote: > >> >> A further difficulty of GPUs compared to CPUs is that at least on CPUs >> we can control exactly which instructions are run, which is often key to >> getting constant-time behavior. For example, we can rewrite an if() >> branching with masking instead, or we can carefully avoid a given >> instruction. On GPUs, we only get to give the driver a shader to >> compile... there is an opaque, client-specific optimizing compiler here. >> How do we e.g. prevent it from optimizing code in a way that makes it >> non-constant-time, e.g. by rewriting masking into actual branching? > > Yes, this is definitely a challenge. I would like an extension from hardware vendors that when enabled, guarantees there are no optimizations which introduce timing differences in primitive operations. Currently, without knowing proprietary GPU implementation details, I hypothesize that this is already true for many operations on many GPUs. I've done informal testing on some GPUs and haven't found any timing differences in primitive operations yet. However, we need a test suite to verify this hypothesis on a variety of hardware. When the discussions about timing attacks with CSS shaders were ongoing, an informal poll of major desktop GPU vendors was done, and all of them indicated that they do not expect variability in execution times of arithmetic operations, or even more complex built-in functions, on their GPUs. (If the answer had been anything but this, then there would be no point in pursuing this approach at all.) It's still likely that issues will be found where some operation or built-in function on some GPU has variable enough execution time that it can be exploited in a timing attack. The only way to know is to test more broadly, and perhaps even explicitly invite security researchers to punch holes in the proposal and implementations. Over time I believe it will be possible to gain confidence in the approach. The potential benefits for developers are so large that it's worth more in-depth investigation. In order to facilitate more widespread testing of this proposal, I suggest moving it to draft status so it's legal by the WebGL extension process to implement it behind a flag in a web browser. Are there any objections to doing so? -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Thu Oct 10 19:03:33 2013 From: cal...@ (Mark Callow) Date: Fri, 11 Oct 2013 11:03:33 +0900 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> Message-ID: <52575C75.7020002@artspark.co.jp> On 2013/10/11 8:05, Kenneth Russell wrote: > The consequence would getContextbe that canvas.getContext('webgl', { version: 2 > }) could return either null, *or* a WebGL 1.0 context, if some other > piece of code (a third-party library, perhaps) called > getContext('webgl', { version: 1 }) in between two adjacent calls. Two adjacent calls to what? For this to happen, wouldn't the other piece of code have to be the *first* to call canvas.getContext? That seems a somewhat unlikely scenario. Typically either 3rd party code is used to set up the context or the application does it itself. If the application wants WebGL 2 and is using 3rd party set-up code, presumably the author would choose 3rd party code that supports WebGL 2. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Thu Oct 10 19:16:18 2013 From: ben...@ (Ben Houston) Date: Thu, 10 Oct 2013 22:16:18 -0400 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <2102006607.2488344.1381447522500.JavaMail.zimbra@mozilla.com> References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <2102006607.2488344.1381447522500.JavaMail.zimbra@mozilla.com> Message-ID: Hi Jeff, Ah, I understand. In http://Clara.io we had webgl detection code that checked for a webgl context, and if it wasn't found would display a helpful message, but then the version of ThreeJS we had would create a experimental-webgl context as that was its default until recently. Now I understand why that failed for us. Thank you. Best regards, On Thu, Oct 10, 2013 at 7:25 PM, Jeff Gilbert wrote: > Firefox didn't remove experimental-webgl, and has no current plans to. (Though we are finally killing `moz-3d` requests) If you encounter this behavior, please file a bug. > > What we did do is return null if the requested contextId doesn't match the current contextId. Firefox doesn't currently treat 'webgl' and 'experimental-webgl' as aliases, since it's not specced that way, and the canvas spec for getContext requires that mismatched contextId requests return null. > This means that `getContext('webgl') && getContext('experimental-webgl')` returns false on Firefox, whereas it returns true on Chrom(e|ium). > > We did add a warning to Firefox around then, so it's obvious when a page does this. > > -Jeff > > ----- Original Message ----- > From: "Ben Houston" > To: "Jeff Gilbert" > Cc: "Zhenyao Mo" , "public webgl" , "Brandon Jones" , "Kenneth Russell" , "Dean Jackson" > Sent: Thursday, October 10, 2013 4:16:14 PM > Subject: Re: [Public WebGL] False positives with WebGL 2 context creation > > We got caught (and all other threejs users) with Firefox's recent removal > of experimental-webgl in favor of just webgl in their mid Sept update. It > would be nice too avoid this in the future. > > Sent from my phone. > On Oct 9, 2013 4:07 PM, "Jeff Gilbert" wrote: > >> >> FWIW, we still technically haven't specced 'experimental-webgl', which has >> indeed created a bug which still needs to be resolved. (cross-contextid >> getContext for webgl) >> >> If I remember correctly, the amount of coordination required here would be >> pretty low. We should just say "Hey, we're doing X", and they'll document >> it in the canvas spec. >> >> -Jeff >> >> ----- Original Message ----- >> From: "Dean Jackson" >> To: "Brandon Jones" >> Cc: "Kenneth Russell" , "Jeff Gilbert" < >> jgilbert...@>, "Zhenyao Mo" , "public webgl" < >> public_webgl...@> >> Sent: Wednesday, October 9, 2013 12:33:07 PM >> Subject: Re: [Public WebGL] False positives with WebGL 2 context creation >> >> If we do expose a new ?webgl2? context type, we?ll need to coordinate with >> the HTML WG (W3C + WHATWG). It?s not really our decision alone. >> >> Dean >> >> On 10 Oct 2013, at 5:32 am, Brandon Jones wrote: >> >> > Unfortunately I think that would actually aggravate the problem. Say we >> got version support (without webgl2) into Chrome 31, and then WebGL2 >> support starts showing up in Chrome Canary 33. Developers will build a >> sample app, test it against Canary (gets a context) and test it against >> stable (gets null, developer falls back to WebGL1) Great! Moving on! >> > >> > After releasing their app, however, they start hearing from people >> running Chrome 30, 29, 28, etc (due to business policy, broken upgrade >> system, malware, whatever) who complain that rather than getting a friendly >> "not supported" screen or WebGL 1 fallback the app simply fails, spewing >> back a console full of "missing function" errors. >> > >> > This is really an easy problem to fix, but 99% of developers wouldn't >> even know it needed fixing until they hit it in the wild. No amount of >> developer outreach on our part is likely to change that, and it will be one >> of those "Why the hell did they think this was a good idea?" things that >> developers love to Grumble about. This is why I would prefer a crappy >> solution that's completely consistent vs. a "clean" solution that acts >> differently across browser versions. >> > >> > >> > On Wed, Oct 9, 2013 at 10:48 AM, Kenneth Russell wrote: >> > On Tue, Oct 8, 2013 at 9:31 PM, Brandon Jones >> wrote: >> > > >> > > I feel pretty strongly that if the user requests a WebGL2 context and >> the >> > > browser can't deliver one it should always return null to eliminate any >> > > confusion about the success/fail state. >> > >> > Agreed -- this is the way OpenGL context creation works, and to >> > provide the best evolutionary path for WebGL, I don't think context >> > creation should fall back to earlier versions. >> > >> > I guess I'd hoped that browsers would start paying attention to the >> > "version" attribute even before they started supporting WebGL 2, so >> > that the "webgl" context type could continue to be used. >> > >> > If that became the case in, for example, shipping versions of Firefox, >> > Safari, IE and Chrome, would that address the concerns? >> > >> > -Ken >> > >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> -- Best regards, Ben Houston Voice: 613-762-4113 Skype: ben.exocortex Twitter: @exocortexcom http://Exocortex.com - Passionate CG Software Professionals. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu Oct 10 22:56:17 2013 From: bja...@ (Benoit Jacob) Date: Fri, 11 Oct 2013 01:56:17 -0400 Subject: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources In-Reply-To: References: <5244158B.4060002@mozilla.com> <932FD1DC-A44A-43D6-B2FB-48F687114E1B@adobe.com> Message-ID: <52579301.9080704@mozilla.com> On 13-10-10 09:46 PM, Kenneth Russell wrote: > On Thu, Sep 26, 2013 at 2:31 PM, Max Vujovic wrote: >> On Sep 26, 2013, at 4:07 AM, Benoit Jacob wrote: >> >>> A further difficulty of GPUs compared to CPUs is that at least on CPUs >>> we can control exactly which instructions are run, which is often key to >>> getting constant-time behavior. For example, we can rewrite an if() >>> branching with masking instead, or we can carefully avoid a given >>> instruction. On GPUs, we only get to give the driver a shader to >>> compile... there is an opaque, client-specific optimizing compiler here. >>> How do we e.g. prevent it from optimizing code in a way that makes it >>> non-constant-time, e.g. by rewriting masking into actual branching? >> Yes, this is definitely a challenge. I would like an extension from hardware vendors that when enabled, guarantees there are no optimizations which introduce timing differences in primitive operations. Currently, without knowing proprietary GPU implementation details, I hypothesize that this is already true for many operations on many GPUs. I've done informal testing on some GPUs and haven't found any timing differences in primitive operations yet. However, we need a test suite to verify this hypothesis on a variety of hardware. > When the discussions about timing attacks with CSS shaders were > ongoing, an informal poll of major desktop GPU vendors was done, and > all of them indicated that they do not expect variability in execution > times of arithmetic operations, or even more complex built-in > functions, on their GPUs. (If the answer had been anything but this, > then there would be no point in pursuing this approach at all.) This NVIDIA whitepaper says otherwise: https://developer.nvidia.com/content/cuda-pro-tip-flush-denormals-confidence /"But multi-instruction sequences such as square root and (notably for my example later in this post) reciprocal square root, must do extra work and take a slower path for denormal values (including the cost of detecting them)."/ Of course, this article also tells how to avoid this problem in the case of CUDA by flushing denormals to zero, but that is a CUDA compile flag. Will that option be made available to OpenGL? This ARM whitepaper shows that denormals are a reality in OpenGL, and not just on desktop GPUs but also on some mobile GPUs: http://malideveloper.arm.com/engage-with-mali/benchmarking-floating-point-precision-part-iii/ The reason why denormals are slow is also pretty fundamental: they are a minority case that requires special handling, so CPU/GPU vendors prefer to implement them in microcode to save silicon. There is really no reason for this to change. So a prerequisite for constant-time shader arithmetic is probably to have an OpenGL extension for enabling flush-to-zero behavior to avoid the denormals problem. That is going to degrade shader precision, but is still the best that could be had if constant-time execution is wanted. Benoit > > It's still likely that issues will be found where some operation or > built-in function on some GPU has variable enough execution time that > it can be exploited in a timing attack. The only way to know is to > test more broadly, and perhaps even explicitly invite security > researchers to punch holes in the proposal and implementations. Over > time I believe it will be possible to gain confidence in the approach. > The potential benefits for developers are so large that it's worth > more in-depth investigation. > > In order to facilitate more widespread testing of this proposal, I > suggest moving it to draft status so it's legal by the WebGL extension > process to implement it behind a flag in a web browser. Are there any > objections to doing so? > > -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu Oct 10 23:00:28 2013 From: bja...@ (Benoit Jacob) Date: Fri, 11 Oct 2013 02:00:28 -0400 Subject: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources In-Reply-To: References: <5244158B.4060002@mozilla.com> <932FD1DC-A44A-43D6-B2FB-48F687114E1B@adobe.com> Message-ID: <525793FC.1090700@mozilla.com> On 13-10-10 09:46 PM, Kenneth Russell wrote: > In order to facilitate more widespread testing of this proposal, I > suggest moving it to draft status so it's legal by the WebGL extension > process to implement it behind a flag in a web browser. Are there any > objections to doing so? I don't object to this extension being promoted to draft. By all means, it's going to be interesting to watch and could lead to useful OpenGL extensions being drafted e.g. to enable flush-to-zero, see the other email that I just sent. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Oct 11 13:05:13 2013 From: kbr...@ (Kenneth Russell) Date: Fri, 11 Oct 2013 13:05:13 -0700 Subject: [Public WebGL] False positives with WebGL 2 context creation In-Reply-To: <52575C75.7020002@artspark.co.jp> References: <0C0F2F4E-1A6F-4035-803D-EDDE6BB10992@apple.com> <1431736167.2331762.1381348986837.JavaMail.zimbra@mozilla.com> <062D7609-5E66-4542-A428-F01924EA04E0@apple.com> <864601825.2342212.1381352753128.JavaMail.zimbra@mozilla.com> <52575C75.7020002@artspark.co.jp> Message-ID: On Thu, Oct 10, 2013 at 7:03 PM, Mark Callow wrote: > On 2013/10/11 8:05, Kenneth Russell wrote: > > The consequence would getContextbe that canvas.getContext('webgl', { > version: 2 > }) could return either null, *or* a WebGL 1.0 context, if some other > piece of code (a third-party library, perhaps) called > getContext('webgl', { version: 1 }) in between two adjacent calls. > > Two adjacent calls to what? For this to happen, wouldn't the other piece of > code have to be the *first* to call canvas.getContext? That seems a somewhat > unlikely scenario. Typically either 3rd party code is used to set up the > context or the application does it itself. If the application wants WebGL 2 > and is using 3rd party set-up code, presumably the author would choose 3rd > party code that supports WebGL 2. Two calls to canvas.getContext. Specifically: 1) Main code calls canvas.getContext('webgl', { version: 2 }) 2) WebGL 2 is unsupported on this machine, so this returns null 3) The main code invokes some third-party library which calls canvas.getContext('webgl') against the same canvas 4) This causes a WebGL 1 context to be created for the canvas 5) Main code calls canvas.getContext('webgl', { version: 2 }) again 6) Because a 'webgl' type context has already been created for the canvas, the context creation attributes are ignored, so the "version: 2" dictionary entry has no effect, and the previously-created WebGL 1 context is returned This surprising behavior was the deciding factor to use a new context ID instead of a context creation attribute. I personally liked the style of the context creation attribute, but this changed my mind. Note that it's infeasible to require that the context creation attributes be considered during second and subsequent calls to Canvas.getContext(). This behavior was argued over at length, and decided, a long time ago. -Ken > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??. > > 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 public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Fri Oct 11 16:24:51 2013 From: baj...@ (Brandon Jones) Date: Fri, 11 Oct 2013 16:24:51 -0700 Subject: [Public WebGL] WebGL 2 conformance test harness Message-ID: I've just posted a pull request on the WebGL github repo that updates the test harness to support WebGL 2 conformance tests: https://github.com/KhronosGroup/WebGL/pull/400 This is a first-stab at updating the conformance test harness to support WebGL 2 contexts and tests. This pull-request is being put up to facilitate discussion about how to best approach this next generation of conformance test. If you have questions, comments, or concerns please add them to the pull request or on here on the mailing list. The primary changes are: - If the "version" query arg is >= 2.0.0 all tests will attempt to create WebGL 2 contexts unless explicitly specified otherwise. (Attempts to create a "webgl2" or "experimental-webgl2" contextId) - If the "version" is less than 2.0.0 a WebGL 1 context will be created, so this harness is still usable for WebGL 1 tests. - wtu.create3DContext now accepts a third parameter, which is an explicit context version. Pass 2 to indicate that a WebGL 2 context is required. If not specified, this will look at the query arg "webglVersion", which is now passed down by the test harness, and defaults to 1 if not present. - The test lists can now accept a --max-version in addition to the --min-version. Most WebGL 1.0 tests should still function correctly with WebGL 2.0 with no changes, so this shouldn't except for tests which are explicitly WebGL 1.0 only. (Such as context-type-test.html) In those cases an equivalent WebGL 2 test should be added. I am currently using --max-version 1.9.9 to indicate WebGL 1-only tests. - WebGL 2-specific tests are currently being placed in the "conformance2" folder, which sits alongside "conformance". - I have added WebGL 2 versions of "constants-and-properties.html", "context-type-test.html", and "methods.html". I've also ported some of the extension tests over to use the newly built-in functions. These have been placed in the "core" folder, which I think is a terrible name but have yet to come up with something better. - Many more tests will be needed to cover the full WebGL 2 functionality, this just provides a framework to build them in. In addition to the above I've also done some minor beautification on the test harness (down with thick blocky borders!) I actually have a version that is more aggressively restyled with the intention of making it work well for mobile devices, but I'll wait until the basics here are in place before I try introducing those changes. This pull request does not handle archiving the 1.0.3 tests. We should either move the current test set into "conformance-suites" or decide that the 2.x tests will exist alongside the 1.x tests and place it in a different folder (tests2?) before accepting this code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Oct 11 16:35:10 2013 From: jgi...@ (Jeff Gilbert) Date: Fri, 11 Oct 2013 16:35:10 -0700 (PDT) Subject: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources In-Reply-To: <52579301.9080704@mozilla.com> References: <5244158B.4060002@mozilla.com> <932FD1DC-A44A-43D6-B2FB-48F687114E1B@adobe.com> <52579301.9080704@mozilla.com> Message-ID: <95494185.2776402.1381534510545.JavaMail.zimbra@mozilla.com> We should check with the GL/GLES groups on this, and see what the vendors have to say about it. -Jeff ----- Original Message ----- From: "Benoit Jacob" To: "Kenneth Russell" Cc: "Max Vujovic" , "public webgl" Sent: Thursday, October 10, 2013 10:56:17 PM Subject: Re: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources On 13-10-10 09:46 PM, Kenneth Russell wrote: > On Thu, Sep 26, 2013 at 2:31 PM, Max Vujovic wrote: >> On Sep 26, 2013, at 4:07 AM, Benoit Jacob wrote: >> >>> A further difficulty of GPUs compared to CPUs is that at least on CPUs >>> we can control exactly which instructions are run, which is often key to >>> getting constant-time behavior. For example, we can rewrite an if() >>> branching with masking instead, or we can carefully avoid a given >>> instruction. On GPUs, we only get to give the driver a shader to >>> compile... there is an opaque, client-specific optimizing compiler here. >>> How do we e.g. prevent it from optimizing code in a way that makes it >>> non-constant-time, e.g. by rewriting masking into actual branching? >> Yes, this is definitely a challenge. I would like an extension from hardware vendors that when enabled, guarantees there are no optimizations which introduce timing differences in primitive operations. Currently, without knowing proprietary GPU implementation details, I hypothesize that this is already true for many operations on many GPUs. I've done informal testing on some GPUs and haven't found any timing differences in primitive operations yet. However, we need a test suite to verify this hypothesis on a variety of hardware. > When the discussions about timing attacks with CSS shaders were > ongoing, an informal poll of major desktop GPU vendors was done, and > all of them indicated that they do not expect variability in execution > times of arithmetic operations, or even more complex built-in > functions, on their GPUs. (If the answer had been anything but this, > then there would be no point in pursuing this approach at all.) This NVIDIA whitepaper says otherwise: https://developer.nvidia.com/content/cuda-pro-tip-flush-denormals-confidence /"But multi-instruction sequences such as square root and (notably for my example later in this post) reciprocal square root, must do extra work and take a slower path for denormal values (including the cost of detecting them)."/ Of course, this article also tells how to avoid this problem in the case of CUDA by flushing denormals to zero, but that is a CUDA compile flag. Will that option be made available to OpenGL? This ARM whitepaper shows that denormals are a reality in OpenGL, and not just on desktop GPUs but also on some mobile GPUs: http://malideveloper.arm.com/engage-with-mali/benchmarking-floating-point-precision-part-iii/ The reason why denormals are slow is also pretty fundamental: they are a minority case that requires special handling, so CPU/GPU vendors prefer to implement them in microcode to save silicon. There is really no reason for this to change. So a prerequisite for constant-time shader arithmetic is probably to have an OpenGL extension for enabling flush-to-zero behavior to avoid the denormals problem. That is going to degrade shader precision, but is still the best that could be had if constant-time execution is wanted. Benoit > > It's still likely that issues will be found where some operation or > built-in function on some GPU has variable enough execution time that > it can be exploited in a timing attack. The only way to know is to > test more broadly, and perhaps even explicitly invite security > researchers to punch holes in the proposal and implementations. Over > time I believe it will be possible to gain confidence in the approach. > The potential benefits for developers are so large that it's worth > more in-depth investigation. > > In order to facilitate more widespread testing of this proposal, I > suggest moving it to draft status so it's legal by the WebGL extension > process to implement it behind a flag in a web browser. Are there any > objections to doing so? > > -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Mon Oct 14 20:36:35 2013 From: cal...@ (Mark Callow) Date: Tue, 15 Oct 2013 12:36:35 +0900 Subject: [Public WebGL] Extension proposal: WEBGL_security_sensitive_resources In-Reply-To: <95494185.2776402.1381534510545.JavaMail.zimbra@mozilla.com> References: <5244158B.4060002@mozilla.com> <932FD1DC-A44A-43D6-B2FB-48F687114E1B@adobe.com> <52579301.9080704@mozilla.com> <95494185.2776402.1381534510545.JavaMail.zimbra@mozilla.com> Message-ID: <525CB843.9090804@artspark.co.jp> On 2013/10/12 8:35, Jeff Gilbert wrote: > We should check with the GL/GLES groups on this, and see what the vendors have to say about it. On what? I have no idea what you are referring. Please don't top post. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha...@ Sun Oct 27 21:12:31 2013 From: sha...@ (Shannon Woods) Date: Mon, 28 Oct 2013 00:12:31 -0400 Subject: [Public WebGL] Rendering feedback loops in WebGL Message-ID: A few bug reports recently filed against ANGLE have made it apparent that there are a number of WebGL applications in the wild which are relying on the ability to bind a single texture both as a render target and as a source texture for sampling in the same draw call. While this is undefined in the OpenGL ES 2.0 spec, it tended to mostly work, or appear working, in Direct3D 9, and it works on some desktop GL drivers. In Direct3D 11, fragments affected by the feedback loop simply render black, and developers are surprised to find code they'd thought was working suddenly broken. The "undefined" part of the specification hasn't seemed to communicate to developers that this is not functionality which should be relied upon. Might this be something that is worth specifying as an outright error at the WebGL level? While it wouldn't be determinable until draw time, an error could be generated if a single texture object is both attached to a texture unit being sampled by the currently bound shader and attached to one of the current framebuffer's attachment points. The OpenGL 2.0 specification requires that the draw not fail overall, but specifies that any fragments affected by the feedback loop are undefined. WebGL may have a bit more freedom in the behavior that it specifies. Would an error here be useful and worthwhile? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dem...@ Sun Oct 27 23:06:40 2013 From: dem...@ (Evgeny Demidov) Date: Mon, 28 Oct 2013 10:06:40 +0400 Subject: [Public WebGL] clamped Float32 in gl.copyTexImage2D ? Message-ID: <526DFEF0.7070008@ipm.sci-nnov.ru> As I understand, Float32 are clamped into [0,1] by gl.copyTexImage2D() in the experimental WebGL2 by Mozila. Is it possible to use not clamped data? As since read/write to the same texture is forbidden in WebGL (2), I could write data into one more texture and then copy them back. Although I don't think it will be popular and I can use one more simple shader too (need I in WebGL1? :) ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Sun Oct 27 23:25:43 2013 From: jgi...@ (Jeff Gilbert) Date: Sun, 27 Oct 2013 23:25:43 -0700 (PDT) Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: References: Message-ID: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> I would love to make this emit an error, maybe INVALID_FRAMEBUFFER_OPERATION. In the mean time, I'm going to at least add a warning against this. -Jeff ----- Original Message ----- From: "Shannon Woods" To: "public webgl" Sent: Sunday, October 27, 2013 9:12:31 PM Subject: [Public WebGL] Rendering feedback loops in WebGL A few bug reports recently filed against ANGLE have made it apparent that there are a number of WebGL applications in the wild which are relying on the ability to bind a single texture both as a render target and as a source texture for sampling in the same draw call. While this is undefined in the OpenGL ES 2.0 spec, it tended to mostly work, or appear working, in Direct3D 9, and it works on some desktop GL drivers. In Direct3D 11, fragments affected by the feedback loop simply render black, and developers are surprised to find code they'd thought was working suddenly broken. The "undefined" part of the specification hasn't seemed to communicate to developers that this is not functionality which should be relied upon. Might this be something that is worth specifying as an outright error at the WebGL level? While it wouldn't be determinable until draw time, an error could be generated if a single texture object is both attached to a texture unit being sampled by the currently bound shader and attached to one of the current framebuffer's attachment points. The OpenGL 2.0 specification requires that the draw not fail overall, but specifies that any fragments affected by the feedback loop are undefined. WebGL may have a bit more freedom in the behavior that it specifies. Would an error here be useful and worthwhile? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Mon Oct 28 00:43:08 2013 From: cal...@ (Mark Callow) Date: Mon, 28 Oct 2013 16:43:08 +0900 Subject: [Public WebGL] clamped Float32 in gl.copyTexImage2D ? In-Reply-To: <526DFEF0.7070008@ipm.sci-nnov.ru> References: <526DFEF0.7070008@ipm.sci-nnov.ru> Message-ID: <526E158C.4000505@artspark.co.jp> On 2013/10/28 15:06, Evgeny Demidov wrote: > > As I understand, Float32 are clamped into [0,1] by gl.copyTexImage2D() > in the experimental WebGL2 by Mozila. > Is it possible to use not clamped data? Before WebGL 2 is released, we need to create a WebGL version of EXT_color_buffer_float and require all implementations that wish to support rendering to float or half-float color buffers to support it. That extension removes the clamping when the destination is float or half-float. There is an extension to do the same thing for WebGL 1 but so far nobody has implemented it. > As since read/write to the same texture is forbidden in WebGL (2), I > could write data into one more texture and then copy them back. > Although I don't think it will be popular and I can use one more > simple shader too (need I in WebGL1? :) Read/write to the same texture is not forbidden. Reading or writing to a texture bound simultaneously to a texture unit and an fbo creates a rendering feedback loop and has "undefined" results, i.e., is not guaranteed to work and may perhaps be forbidden by WebGL. There is no problem with writing to a texture, unbinding either it or the FBO it is attached to, binding it to a texture unit and sampling it. BTW, any implementation that gets the results you think you want when there is a feedback loop will be slow. It likely means there is little if any parallelism going on in fragment processing. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Mon Oct 28 09:34:07 2013 From: baj...@ (Brandon Jones) Date: Mon, 28 Oct 2013 09:34:07 -0700 Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> References: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> Message-ID: In my opinion our default reading of "undefined behavior" should be "throws an error in WebGL" unless there's an obvious course of action that makes the behavior predictable. (ie: Zeroing out textures). In this case, though, I think that an error is the most appropriate response. --Brandon On Sun, Oct 27, 2013 at 11:25 PM, Jeff Gilbert wrote: > > I would love to make this emit an error, maybe > INVALID_FRAMEBUFFER_OPERATION. In the mean time, I'm going to at least add > a warning against this. > > -Jeff > > ----- Original Message ----- > From: "Shannon Woods" > To: "public webgl" > Sent: Sunday, October 27, 2013 9:12:31 PM > Subject: [Public WebGL] Rendering feedback loops in WebGL > > A few bug reports recently filed against ANGLE have made it apparent that > there are a number of WebGL applications in the wild which are relying on > the ability to bind a single texture both as a render target and as a > source texture for sampling in the same draw call. While this is undefined > in the OpenGL ES 2.0 spec, it tended to mostly work, or appear working, in > Direct3D 9, and it works on some desktop GL drivers. In Direct3D 11, > fragments affected by the feedback loop simply render black, and developers > are surprised to find code they'd thought was working suddenly broken. > > The "undefined" part of the specification hasn't seemed to communicate to > developers that this is not functionality which should be relied upon. > Might this be something that is worth specifying as an outright error at > the WebGL level? While it wouldn't be determinable until draw time, an > error could be generated if a single texture object is both attached to a > texture unit being sampled by the currently bound shader and attached to > one of the current framebuffer's attachment points. > > The OpenGL 2.0 specification requires that the draw not fail overall, but > specifies that any fragments affected by the feedback loop are undefined. > WebGL may have a bit more freedom in the behavior that it specifies. Would > an error here be useful and worthwhile? > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Oct 28 18:58:31 2013 From: cal...@ (Mark Callow) Date: Tue, 29 Oct 2013 10:58:31 +0900 Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: References: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> Message-ID: <526F1647.5090702@artspark.co.jp> On 2013/10/29 1:34, Brandon Jones wrote: > In my opinion our default reading of "undefined behavior" should be > "throws an error in WebGL" unless there's an obvious course of action > that makes the behavior predictable. (ie: Zeroing out textures). > > In this case, though, I think that an error is the most appropriate > response. > > The reasons it is not an error in OpenGL {,ES} are (a) nobody wants to do error checking at draw time because of the impact on performance and wish not to "penalize well written applications" and (b) the error report will be unhelpful. Regarding (b), (i) no released application is going to call glGetError() after its draw commands and (ii) the error would not be set until some time after the offending draw call has returned to the caller. a and b.(i) apply to WebGL. b.(ii) does not since WebGL implementations are tracking GL state, unlike the client side of an OpenGL {,ES} implementation. We should be very cautious about opening the door to draw time error checks. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Oct 29 10:32:44 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 29 Oct 2013 10:32:44 -0700 Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: <526F1647.5090702@artspark.co.jp> References: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> <526F1647.5090702@artspark.co.jp> Message-ID: On Mon, Oct 28, 2013 at 6:58 PM, Mark Callow wrote: > On 2013/10/29 1:34, Brandon Jones wrote: > > In my opinion our default reading of "undefined behavior" should be "throws > an error in WebGL" unless there's an obvious course of action that makes the > behavior predictable. (ie: Zeroing out textures). > > In this case, though, I think that an error is the most appropriate > response. > > > The reasons it is not an error in OpenGL {,ES} are (a) nobody wants to do > error checking at draw time because of the impact on performance and wish > not to "penalize well written applications" and (b) the error report will be > unhelpful. Regarding (b), (i) no released application is going to call > glGetError() after its draw commands and (ii) the error would not be set > until some time after the offending draw call has returned to the caller. > > a and b.(i) apply to WebGL. b.(ii) does not since WebGL implementations are > tracking GL state, unlike the client side of an OpenGL {,ES} implementation. The error report will be more helpful than in pure OpenGL. WebGL implementations already report descriptive error messages to the JavaScript console, when the WebGL layer, rather than OpenGL, can catch the error. A few examples from running the conformance suite in Chrome: [.WebGLRenderingContext]GL ERROR :GL_INVALID_OPERATION : glUniform3fv: wrong uniform function for type WebGL: INVALID_VALUE: vertexAttribPointer: index out of range WebGL: INVALID_OPERATION: vertexAttribPointer: no bound ARRAY_BUFFER [.WebGLRenderingContext]GL ERROR :GL_INVALID_OPERATION : glUniform4iv: count > 1 for non-array [.WebGLRenderingContext]GL ERROR :GL_INVALID_OPERATION : glDrawElements: attempt to access out of range vertices in attribute 2 The implementation of these checks should be pretty well optimizable. During calls to bindTexture, bindFramebuffer or framebufferTexture2D it should be possible to quickly detect whether a texture is bound both to a texture unit and the current framebuffer. If no, the draw call will be fast. If yes, then and only then will more expensive checks be needed -- seeing whether the texture bound to a texture unit referenced by a statically used uniform sampler2D is an attachment to the current framebuffer. > We should be very cautious about opening the door to draw time error checks. I agree, but the current undefined behavior has already caused developers to mistakenly write non-portable content. With the coming inclusion of draw_buffers in WebGL 2, this problem will only get worse. Do you have another idea about how to catch this pitfall? Generating an error at draw time seems like the best option to me. -Ken > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??. > > 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 public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Oct 29 14:56:10 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 29 Oct 2013 22:56:10 +0100 Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: References: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> <526F1647.5090702@artspark.co.jp> Message-ID: On Tue, Oct 29, 2013 at 6:32 PM, Kenneth Russell wrote: > WebGL implementations already report descriptive error messages to the > JavaScript console, when the WebGL layer, rather than OpenGL, can > catch the error. A slight tangent, this policy has in the past rendered the error console usless on occasion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Oct 29 15:13:33 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 29 Oct 2013 15:13:33 -0700 Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: References: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> <526F1647.5090702@artspark.co.jp> Message-ID: On Tue, Oct 29, 2013 at 2:56 PM, Florian B?sch wrote: > On Tue, Oct 29, 2013 at 6:32 PM, Kenneth Russell wrote: >> >> WebGL implementations already report descriptive error messages to the >> JavaScript console, when the WebGL layer, rather than OpenGL, can >> catch the error. > > > A slight tangent, this policy has in the past rendered the error console > usless on occasion. Understood. Chrome does stop reporting errors to the console if a context generates too many of them. If this policy seems to not be working, please file a bug at crbug.com and email me the bug ID. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue Oct 29 15:22:02 2013 From: bja...@ (Benoit Jacob) Date: Tue, 29 Oct 2013 18:22:02 -0400 Subject: [Public WebGL] Rendering feedback loops in WebGL In-Reply-To: References: <934383703.5068552.1382941543003.JavaMail.zimbra@mozilla.com> <526F1647.5090702@artspark.co.jp> Message-ID: <5270350A.4010102@mozilla.com> On 13-10-29 06:13 PM, Kenneth Russell wrote: > On Tue, Oct 29, 2013 at 2:56 PM, Florian B?sch wrote: >> On Tue, Oct 29, 2013 at 6:32 PM, Kenneth Russell wrote: >>> WebGL implementations already report descriptive error messages to the >>> JavaScript console, when the WebGL layer, rather than OpenGL, can >>> catch the error. >> >> A slight tangent, this policy has in the past rendered the error console >> usless on occasion. > Understood. Chrome does stop reporting errors to the console if a > context generates too many of them. If this policy seems to not be > working, please file a bug at crbug.com and email me the bug ID. [Apologies to Ken who'll receive this twice] Firefox does the same; the max number of WebGL warnings per context is 32 by default; can be adjusted as the webgl.max-warnings-per-context preference in about:config. Benoit > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Wed Oct 30 07:10:54 2013 From: bja...@ (Benoit Jacob) Date: Wed, 30 Oct 2013 10:10:54 -0400 Subject: [Public WebGL] Mozilla and vendor prefixes Message-ID: <5271136E.20502@mozilla.com> Hi all, This is just a hopefully informative note about the status of vendor prefixes at Mozilla. We've just officially adopted API exposure guidelines that make it official that we don't want to have moz-prefixed stuff anymore, and instead will put experimental features behind flags in about:config. https://wiki.mozilla.org/WebAPI/ExposureGuidelines I believe that this just making official what has been Mozilla policy for a while now, and I believe that Chromium's policy in these matters is also similar. Regarding WebGL extensions, the switch from prefixes to flags has already been effective for a while (in particular for WEBGL_draw_buffers). At the moment we still support a few MOZ_ prefixed WebGL extension strings, but as of Gecko 27 (now in the Aurora channel, set for release in 12 weeks) we generate a deprecation warning when they are used. I believe that we'll remove support for them shortly, after web developers have had some time to notice this warning. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Oct 30 08:10:19 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 30 Oct 2013 16:10:19 +0100 Subject: [Public WebGL] Mozilla and vendor prefixes In-Reply-To: <5271136E.20502@mozilla.com> References: <5271136E.20502@mozilla.com> Message-ID: I welcome the switch away from prefixes, however, putting them behind about:config flags has some significant downsides. The prefixes guarded against developers (not users) to try out experimental features. As such they where useful in gauging the availability of an extension, the behavior in face of actual use and bug reports from users, and ultimately guide when is a good time to remove a prefix. Putting it behind an about:config obscures the support for an extension, it prevents users from trying an experiment using that extension, and it will lead to less testing and bug reports regarding such an extension. This means that extensions will linger in about:config flag state longer, and at the time that they're taken out of it, they will contain more bugs and be less well tested, and only then will statistics become available how widespread the support is in the first place. On Wed, Oct 30, 2013 at 3:10 PM, Benoit Jacob wrote: > > Hi all, > > This is just a hopefully informative note about the status of vendor > prefixes at Mozilla. > > We've just officially adopted API exposure guidelines that make it > official that we don't want to have moz-prefixed stuff anymore, and > instead will put experimental features behind flags in about:config. > > https://wiki.mozilla.org/WebAPI/ExposureGuidelines > > I believe that this just making official what has been Mozilla policy > for a while now, and I believe that Chromium's policy in these matters > is also similar. > > Regarding WebGL extensions, the switch from prefixes to flags has > already been effective for a while (in particular for > WEBGL_draw_buffers). At the moment we still support a few MOZ_ prefixed > WebGL extension strings, but as of Gecko 27 (now in the Aurora channel, > set for release in 12 weeks) we generate a deprecation warning when they > are used. I believe that we'll remove support for them shortly, after > web developers have had some time to notice this warning. > > Benoit > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Wed Oct 30 10:27:13 2013 From: din...@ (Dean Jackson) Date: Thu, 31 Oct 2013 04:27:13 +1100 Subject: [Public WebGL] Mozilla and vendor prefixes In-Reply-To: References: <5271136E.20502@mozilla.com> Message-ID: <09A14A0A-E014-4A36-AB86-C0BD0F0328FF@apple.com> On 31 Oct 2013, at 2:10 am, Florian B?sch wrote: > I welcome the switch away from prefixes, however, putting them behind about:config flags has some significant downsides. > > The prefixes guarded against developers (not users) to try out experimental features. As such they where useful in gauging the availability of an extension, the behavior in face of actual use and bug reports from users, and ultimately guide when is a good time to remove a prefix. > > Putting it behind an about:config obscures the support for an extension, it prevents users from trying an experiment using that extension, and it will lead to less testing and bug reports regarding such an extension. > > This means that extensions will linger in about:config flag state longer, and at the time that they're taken out of it, they will contain more bugs and be less well tested, and only then will statistics become available how widespread the support is in the first place. Florian gives many of the reasons WebKit reluctantly decided to stick with prefixes. Our approach will be to enable things in the development/nightly-build channel in order to get exposure, feedback and testing (as long as they are relatively stable and without obvious security issues). Dean > > On Wed, Oct 30, 2013 at 3:10 PM, Benoit Jacob wrote: > > Hi all, > > This is just a hopefully informative note about the status of vendor > prefixes at Mozilla. > > We've just officially adopted API exposure guidelines that make it > official that we don't want to have moz-prefixed stuff anymore, and > instead will put experimental features behind flags in about:config. > > https://wiki.mozilla.org/WebAPI/ExposureGuidelines > > I believe that this just making official what has been Mozilla policy > for a while now, and I believe that Chromium's policy in these matters > is also similar. > > Regarding WebGL extensions, the switch from prefixes to flags has > already been effective for a while (in particular for > WEBGL_draw_buffers). At the moment we still support a few MOZ_ prefixed > WebGL extension strings, but as of Gecko 27 (now in the Aurora channel, > set for release in 12 weeks) we generate a deprecation warning when they > are used. I believe that we'll remove support for them shortly, after > web developers have had some time to notice this warning. > > Benoit > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Wed Oct 30 10:31:10 2013 From: baj...@ (Brandon Jones) Date: Wed, 30 Oct 2013 10:31:10 -0700 Subject: [Public WebGL] Mozilla and vendor prefixes In-Reply-To: References: <5271136E.20502@mozilla.com> Message-ID: First off, let me say that I too welcome a prefix-less future! Glad to hear Mozilla is taking that route. As for Florian's very valid concerns about hiding extensions behind a flag, I think that the burden is on the WebGL implementors and the Working Group to ensure that extensions don't get stuck in draft limbo for very long. Hiding behind a flag will hopefully mean less broken apps if we realize that an extension needs to be changed. (Witness the mess that was floating point texture filtering.) If we let extensions stall in draft status, though, then they may as well have not been implemented at all under this new policy. To that end we should take a serious look at extensions like WEBGL_draw_buffers and EXT_frag_depth to see if it's appropriate to move them to "Community approved" status. (Has anyone else implemented them yet?) On Wed, Oct 30, 2013 at 8:10 AM, Florian B?sch wrote: > I welcome the switch away from prefixes, however, putting them behind > about:config flags has some significant downsides. > > The prefixes guarded against developers (not users) to try out > experimental features. As such they where useful in gauging the > availability of an extension, the behavior in face of actual use and bug > reports from users, and ultimately guide when is a good time to remove a > prefix. > > Putting it behind an about:config obscures the support for an extension, > it prevents users from trying an experiment using that extension, and it > will lead to less testing and bug reports regarding such an extension. > > This means that extensions will linger in about:config flag state longer, > and at the time that they're taken out of it, they will contain more bugs > and be less well tested, and only then will statistics become available how > widespread the support is in the first place. > > > > On Wed, Oct 30, 2013 at 3:10 PM, Benoit Jacob wrote: > >> >> Hi all, >> >> This is just a hopefully informative note about the status of vendor >> prefixes at Mozilla. >> >> We've just officially adopted API exposure guidelines that make it >> official that we don't want to have moz-prefixed stuff anymore, and >> instead will put experimental features behind flags in about:config. >> >> https://wiki.mozilla.org/WebAPI/ExposureGuidelines >> >> I believe that this just making official what has been Mozilla policy >> for a while now, and I believe that Chromium's policy in these matters >> is also similar. >> >> Regarding WebGL extensions, the switch from prefixes to flags has >> already been effective for a while (in particular for >> WEBGL_draw_buffers). At the moment we still support a few MOZ_ prefixed >> WebGL extension strings, but as of Gecko 27 (now in the Aurora channel, >> set for release in 12 weeks) we generate a deprecation warning when they >> are used. I believe that we'll remove support for them shortly, after >> web developers have had some time to notice this warning. >> >> Benoit >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Oct 30 10:54:15 2013 From: bja...@ (Benoit Jacob) Date: Wed, 30 Oct 2013 13:54:15 -0400 Subject: [Public WebGL] Mozilla and vendor prefixes In-Reply-To: References: <5271136E.20502@mozilla.com> Message-ID: <527147C7.8060606@mozilla.com> On 13-10-30 01:31 PM, Brandon Jones wrote: > First off, let me say that I too welcome a prefix-less future! Glad to > hear Mozilla is taking that route. > > As for Florian's very valid concerns about hiding extensions behind a > flag, I think that the burden is on the WebGL implementors and the > Working Group to ensure that extensions don't get stuck in draft limbo > for very long. Hiding behind a flag will hopefully mean less broken > apps if we realize that an extension needs to be changed. (Witness the > mess that was floating point texture filtering.) If we let extensions > stall in draft status, though, then they may as well have not been > implemented at all under this new policy. > > To that end we should take a serious look at extensions like > WEBGL_draw_buffers and EXT_frag_depth to see if it's appropriate to > move them to "Community approved" status. (Has anyone else implemented > them yet?) WEBGL_draw_buffers is implemented in Firefox 24 and I would support promoting it as soon as possible, as it is an extension that web developers have asked for a lot. Benoit > > > On Wed, Oct 30, 2013 at 8:10 AM, Florian B?sch > wrote: > > I welcome the switch away from prefixes, however, putting them > behind about:config flags has some significant downsides. > > The prefixes guarded against developers (not users) to try out > experimental features. As such they where useful in gauging the > availability of an extension, the behavior in face of actual use > and bug reports from users, and ultimately guide when is a good > time to remove a prefix. > > Putting it behind an about:config obscures the support for an > extension, it prevents users from trying an experiment using that > extension, and it will lead to less testing and bug reports > regarding such an extension. > > This means that extensions will linger in about:config flag state > longer, and at the time that they're taken out of it, they will > contain more bugs and be less well tested, and only then will > statistics become available how widespread the support is in the > first place. > > > > On Wed, Oct 30, 2013 at 3:10 PM, Benoit Jacob > wrote: > > > Hi all, > > This is just a hopefully informative note about the status of > vendor > prefixes at Mozilla. > > We've just officially adopted API exposure guidelines that make it > official that we don't want to have moz-prefixed stuff > anymore, and > instead will put experimental features behind flags in > about:config. > > https://wiki.mozilla.org/WebAPI/ExposureGuidelines > > I believe that this just making official what has been Mozilla > policy > for a while now, and I believe that Chromium's policy in these > matters > is also similar. > > Regarding WebGL extensions, the switch from prefixes to flags has > already been effective for a while (in particular for > WEBGL_draw_buffers). At the moment we still support a few MOZ_ > prefixed > WebGL extension strings, but as of Gecko 27 (now in the Aurora > channel, > set for release in 12 weeks) we generate a deprecation warning > when they > are used. I believe that we'll remove support for them > shortly, after > web developers have had some time to notice this warning. > > Benoit > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > . > To unsubscribe, send an email to majordomo...@ > with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Oct 30 13:12:21 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 30 Oct 2013 13:12:21 -0700 Subject: [Public WebGL] Mozilla and vendor prefixes In-Reply-To: <527147C7.8060606@mozilla.com> References: <5271136E.20502@mozilla.com> <527147C7.8060606@mozilla.com> Message-ID: On Wed, Oct 30, 2013 at 10:54 AM, Benoit Jacob wrote: > On 13-10-30 01:31 PM, Brandon Jones wrote: > > First off, let me say that I too welcome a prefix-less future! Glad to hear > Mozilla is taking that route. > > As for Florian's very valid concerns about hiding extensions behind a flag, > I think that the burden is on the WebGL implementors and the Working Group > to ensure that extensions don't get stuck in draft limbo for very long. > Hiding behind a flag will hopefully mean less broken apps if we realize that > an extension needs to be changed. (Witness the mess that was floating point > texture filtering.) If we let extensions stall in draft status, though, then > they may as well have not been implemented at all under this new policy. > > To that end we should take a serious look at extensions like > WEBGL_draw_buffers and EXT_frag_depth to see if it's appropriate to move > them to "Community approved" status. (Has anyone else implemented them yet?) > > > WEBGL_draw_buffers is implemented in Firefox 24 and I would support > promoting it as soon as possible, as it is an extension that web developers > have asked for a lot. That's great to hear. Could someone please start a new thread about moving that extension to community approved to get broader feedback? > Benoit > > > > > On Wed, Oct 30, 2013 at 8:10 AM, Florian B?sch wrote: >> >> I welcome the switch away from prefixes, however, putting them behind >> about:config flags has some significant downsides. >> >> The prefixes guarded against developers (not users) to try out >> experimental features. As such they where useful in gauging the availability >> of an extension, the behavior in face of actual use and bug reports from >> users, and ultimately guide when is a good time to remove a prefix. >> >> Putting it behind an about:config obscures the support for an extension, >> it prevents users from trying an experiment using that extension, and it >> will lead to less testing and bug reports regarding such an extension. >> >> This means that extensions will linger in about:config flag state longer, >> and at the time that they're taken out of it, they will contain more bugs >> and be less well tested, and only then will statistics become available how >> widespread the support is in the first place. >> >> >> >> On Wed, Oct 30, 2013 at 3:10 PM, Benoit Jacob wrote: >>> >>> >>> Hi all, >>> >>> This is just a hopefully informative note about the status of vendor >>> prefixes at Mozilla. >>> >>> We've just officially adopted API exposure guidelines that make it >>> official that we don't want to have moz-prefixed stuff anymore, and >>> instead will put experimental features behind flags in about:config. >>> >>> https://wiki.mozilla.org/WebAPI/ExposureGuidelines >>> >>> I believe that this just making official what has been Mozilla policy >>> for a while now, and I believe that Chromium's policy in these matters >>> is also similar. >>> >>> Regarding WebGL extensions, the switch from prefixes to flags has >>> already been effective for a while (in particular for >>> WEBGL_draw_buffers). At the moment we still support a few MOZ_ prefixed >>> WebGL extension strings, but as of Gecko 27 (now in the Aurora channel, >>> set for release in 12 weeks) we generate a deprecation warning when they >>> are used. I believe that we'll remove support for them shortly, after >>> web developers have had some time to notice this warning. >>> >>> Benoit >>> >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu Oct 31 05:18:54 2013 From: bja...@ (Benoit Jacob) Date: Thu, 31 Oct 2013 08:18:54 -0400 Subject: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? Message-ID: <52724AAE.40308@mozilla.com> Hi all, Is there any objection to promoting WEBGL_draw_buffers to Community Approved? http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ It is already shipping behind flags in both Chrome and Firefox. It is often pointed out by application developers as a very important extension to have. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Oct 31 11:10:31 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 31 Oct 2013 11:10:31 -0700 Subject: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? In-Reply-To: <52724AAE.40308@mozilla.com> References: <52724AAE.40308@mozilla.com> Message-ID: No objection. +1 to promoting it. -Ken On Thu, Oct 31, 2013 at 5:18 AM, Benoit Jacob wrote: > Hi all, > > Is there any objection to promoting WEBGL_draw_buffers to Community > Approved? > > http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ > > It is already shipping behind flags in both Chrome and Firefox. It is often > pointed out by application developers as a very important extension to have. > > Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Thu Oct 31 11:17:08 2013 From: baj...@ (Brandon Jones) Date: Thu, 31 Oct 2013 11:17:08 -0700 Subject: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? In-Reply-To: References: <52724AAE.40308@mozilla.com> Message-ID: No objection here either, especially considering that this functionality is part of the core WebGL 2 spec. --Brandon On Thu, Oct 31, 2013 at 11:10 AM, Kenneth Russell wrote: > > No objection. +1 to promoting it. > > -Ken > > > On Thu, Oct 31, 2013 at 5:18 AM, Benoit Jacob wrote: > > Hi all, > > > > Is there any objection to promoting WEBGL_draw_buffers to Community > > Approved? > > > > http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ > > > > It is already shipping behind flags in both Chrome and Firefox. It is > often > > pointed out by application developers as a very important extension to > have. > > > > Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Thu Oct 31 11:18:40 2013 From: zmo...@ (Zhenyao Mo) Date: Thu, 31 Oct 2013 11:18:40 -0700 Subject: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? In-Reply-To: References: <52724AAE.40308@mozilla.com> Message-ID: big +1 On Thu, Oct 31, 2013 at 11:10 AM, Kenneth Russell wrote: > > No objection. +1 to promoting it. > > -Ken > > > On Thu, Oct 31, 2013 at 5:18 AM, Benoit Jacob wrote: >> Hi all, >> >> Is there any objection to promoting WEBGL_draw_buffers to Community >> Approved? >> >> http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ >> >> It is already shipping behind flags in both Chrome and Firefox. It is often >> pointed out by application developers as a very important extension to have. >> >> Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Thu Oct 31 14:03:16 2013 From: jgi...@ (Jeff Gilbert) Date: Thu, 31 Oct 2013 14:03:16 -0700 (PDT) Subject: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? In-Reply-To: References: <52724AAE.40308@mozilla.com> Message-ID: <2055378723.5728133.1383253396262.JavaMail.zimbra@mozilla.com> Everyone seems to agree here. I put a pull request up at: https://github.com/KhronosGroup/WebGL/pull/409 (I'm pretty sure that's all it needs) I think we just want Dean's go-ahead before taking it. -Jeff ----- Original Message ----- From: "Zhenyao Mo" To: "Kenneth Russell" Cc: "Benoit Jacob" , "public webgl" Sent: Thursday, October 31, 2013 11:18:40 AM Subject: Re: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? big +1 On Thu, Oct 31, 2013 at 11:10 AM, Kenneth Russell wrote: > > No objection. +1 to promoting it. > > -Ken > > > On Thu, Oct 31, 2013 at 5:18 AM, Benoit Jacob wrote: >> Hi all, >> >> Is there any objection to promoting WEBGL_draw_buffers to Community >> Approved? >> >> http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ >> >> It is already shipping behind flags in both Chrome and Firefox. It is often >> pointed out by application developers as a very important extension to have. >> >> Benoit > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Oct 31 15:13:53 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 31 Oct 2013 15:13:53 -0700 Subject: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? In-Reply-To: <2055378723.5728133.1383253396262.JavaMail.zimbra@mozilla.com> References: <52724AAE.40308@mozilla.com> <2055378723.5728133.1383253396262.JavaMail.zimbra@mozilla.com> Message-ID: Public apology: I merged that pull request before reading this thread. Sorry Dean. On Thu, Oct 31, 2013 at 2:03 PM, Jeff Gilbert wrote: > Everyone seems to agree here. I put a pull request up at: > https://github.com/KhronosGroup/WebGL/pull/409 > (I'm pretty sure that's all it needs) > > I think we just want Dean's go-ahead before taking it. > > -Jeff > > ----- Original Message ----- > From: "Zhenyao Mo" > To: "Kenneth Russell" > Cc: "Benoit Jacob" , "public webgl" > Sent: Thursday, October 31, 2013 11:18:40 AM > Subject: Re: [Public WebGL] Promote WEBGL_draw_buffers to Community Approved? > > > big +1 > > On Thu, Oct 31, 2013 at 11:10 AM, Kenneth Russell wrote: >> >> No objection. +1 to promoting it. >> >> -Ken >> >> >> On Thu, Oct 31, 2013 at 5:18 AM, Benoit Jacob wrote: >>> Hi all, >>> >>> Is there any objection to promoting WEBGL_draw_buffers to Community >>> Approved? >>> >>> http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ >>> >>> It is already shipping behind flags in both Chrome and Firefox. It is often >>> pointed out by application developers as a very important extension to have. >>> >>> Benoit >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl -----------------------------------------------------------