From Dav...@ Tue May 2 18:44:07 2017 From: Dav...@ (David Catuhe) Date: Wed, 3 May 2017 01:44:07 +0000 Subject: [Public WebGL] Introducing Spector.js for Webgl Message-ID: Hey team! We've just announced the availability of a WebGL debugger: Spector.js :). While part of Babylon.js project, it could be used with any webgl engine and the extension works on Edge, Chrome, Firefox. The runtime can also be used directly on webgl browser on compatible phones. [https://github.com/BabylonJS/Spector.js/raw/master/documentation/pictures/title.png] To learn more, please have a look to the following resources: Website: http://spector.babylonjs.com / Intro video: https://www.youtube.com/watch?v=Dp2tL4FvRVk We hope this will help the WebGL community [cid:image002.png...@] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 14879 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 43600 bytes Desc: image003.jpg URL: From khr...@ Mon May 8 11:05:33 2017 From: khr...@ (Gregg Tavares) Date: Mon, 08 May 2017 18:05:33 +0000 Subject: [Public WebGL] there is no such thing as "experimental-webgl2" correct? Message-ID: I would like to know if it is true that there is no such thing as "experimental-webgl2". Is this correct? it is my understanding that browsers stopped using prefixes because apps get dependent on them -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai...@ Mon May 8 11:35:30 2017 From: kai...@ (Kai Ninomiya) Date: Mon, 08 May 2017 18:35:30 +0000 Subject: [Public WebGL] there is no such thing as "experimental-webgl2" correct? In-Reply-To: References: Message-ID: That should be correct. I think Firefox used to allow 'experimental-webgl2' a long time ago, but AFAICT both Firefox and Chrome no longer accept it. On Mon, May 8, 2017 at 11:06 AM Gregg Tavares wrote: > I would like to know if it is true that there is no such thing as > "experimental-webgl2". > > Is this correct? > > it is my understanding that browsers stopped using prefixes because apps > get dependent on them > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From tsh...@ Wed May 24 06:29:27 2017 From: tsh...@ (Tarek Sherif) Date: Wed, 24 May 2017 09:29:27 -0400 Subject: [Public WebGL] WebGL 2 EXT_disjoint_timer_query in Firefox Message-ID: I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 contexts in Firefox. It allows both WebGL 1 (e.g. ext.createQueryEXT) and WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed for this extension? The EXT_disjoint_timer_query spec doesn't mention the WebGL 2 usage, but does state: "This version of the disjoint_timer_query extension is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of the extension for how it is exposed on WebGL 2.0 contexts." Does that mean EXT_disjoint_timer_query should behave as specified in EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If so, it would seem that the WebGL 1-like functionality that Firefox exposes on that extension is incorrect. Either way, this all seems more confusing than it needs to be... Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsh...@ Wed May 24 08:19:03 2017 From: tsh...@ (Tarek Sherif) Date: Wed, 24 May 2017 11:19:03 -0400 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: Ah, I just realized I was only using the TIME_ELAPSED_EXT and GPU_DISJOINT_EXT enums on the extensions, which is why they appeared to be interchangeable. The presence of the original EXT_disjoint_timer_query on a WebGL 2 context does still strike me as odd, since the text from spec I quoted suggests that it shouldn't be. Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif wrote: > I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 > contexts in Firefox. It allows both WebGL 1 (e.g. ext.createQueryEXT) and > WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed for this > extension? The EXT_disjoint_timer_query spec doesn't mention the WebGL 2 > usage, but does state: "This version of the disjoint_timer_query extension > is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of the > extension for how it is exposed on WebGL 2.0 contexts." Does that mean > EXT_disjoint_timer_query should behave as specified in > EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If so, it > would seem that the WebGL 1-like functionality that Firefox exposes on that > extension is incorrect. > > Either way, this all seems more confusing than it needs to be... > > Tarek Sherif > http://tareksherif.net/ > https://www.biodigital.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kai...@ Wed May 24 10:36:27 2017 From: kai...@ (Kai Ninomiya) Date: Wed, 24 May 2017 17:36:27 +0000 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: IIRC the EXT_disjoint_timer_query extension is not supposed to be available at all for WebGL 2 contexts. Getting that extension should fail. It's possible we forgot to add a conformance test for this behavior, and it slipped by in Firefox. On Wed, May 24, 2017 at 8:19 AM Tarek Sherif wrote: > Ah, I just realized I was only using the TIME_ELAPSED_EXT and > GPU_DISJOINT_EXT enums on the extensions, which is why they appeared to be > interchangeable. The presence of the original EXT_disjoint_timer_query on a > WebGL 2 context does still strike me as odd, since the text from spec I > quoted suggests that it shouldn't be. > > Tarek Sherif > http://tareksherif.net/ > https://www.biodigital.com/ > > > On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif wrote: > >> I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 >> contexts in Firefox. It allows both WebGL 1 (e.g. ext.createQueryEXT) and >> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed for this >> extension? The EXT_disjoint_timer_query spec doesn't mention the WebGL 2 >> usage, but does state: "This version of the disjoint_timer_query extension >> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of the >> extension for how it is exposed on WebGL 2.0 contexts." Does that mean >> EXT_disjoint_timer_query should behave as specified in >> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If so, it >> would seem that the WebGL 1-like functionality that Firefox exposes on that >> extension is incorrect. >> >> Either way, this all seems more confusing than it needs to be... >> >> Tarek Sherif >> http://tareksherif.net/ >> https://www.biodigital.com/ >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4845 bytes Desc: S/MIME Cryptographic Signature URL: From kbr...@ Wed May 24 10:55:05 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 24 May 2017 10:55:05 -0700 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: That's correct, it's not supposed to be advertised. EXT_disjoint_timer_query is for WebGL 1.0, and _webgl2 for 2.0. The split was made fairly late in the WebGL 2.0 spec process, which is probably why it slipped by in Firefox. https://github.com/KhronosGroup/WebGL/pull/2405 strengthens the conformance test. Thanks for pointing this out. -Ken On Wed, May 24, 2017 at 10:36 AM, Kai Ninomiya wrote: > IIRC the EXT_disjoint_timer_query extension is not supposed to be > available at all for WebGL 2 contexts. Getting that extension should fail. > It's possible we forgot to add a conformance test for this behavior, and it > slipped by in Firefox. > > On Wed, May 24, 2017 at 8:19 AM Tarek Sherif wrote: > >> Ah, I just realized I was only using the TIME_ELAPSED_EXT and >> GPU_DISJOINT_EXT enums on the extensions, which is why they appeared to be >> interchangeable. The presence of the original EXT_disjoint_timer_query on a >> WebGL 2 context does still strike me as odd, since the text from spec I >> quoted suggests that it shouldn't be. >> >> Tarek Sherif >> http://tareksherif.net/ >> https://www.biodigital.com/ >> >> >> On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif wrote: >> >>> I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 >>> contexts in Firefox. It allows both WebGL 1 (e.g. ext.createQueryEXT) and >>> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed for this >>> extension? The EXT_disjoint_timer_query spec doesn't mention the WebGL 2 >>> usage, but does state: "This version of the disjoint_timer_query extension >>> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of the >>> extension for how it is exposed on WebGL 2.0 contexts." Does that mean >>> EXT_disjoint_timer_query should behave as specified in >>> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If so, it >>> would seem that the WebGL 1-like functionality that Firefox exposes on that >>> extension is incorrect. >>> >>> Either way, this all seems more confusing than it needs to be... >>> >>> Tarek Sherif >>> http://tareksherif.net/ >>> https://www.biodigital.com/ >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsh...@ Wed May 24 13:07:23 2017 From: tsh...@ (Tarek Sherif) Date: Wed, 24 May 2017 16:07:23 -0400 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: Here are some relevant Firefox bug tickets: https://bugzilla.mozilla.org/show_bug.cgi?id=1308057 https://bugzilla.mozilla.org/show_bug.cgi?id=1328882 Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ On Wed, May 24, 2017 at 1:55 PM, Kenneth Russell wrote: > That's correct, it's not supposed to be advertised. > EXT_disjoint_timer_query is for WebGL 1.0, and _webgl2 for 2.0. > > The split was made fairly late in the WebGL 2.0 spec process, which is > probably why it slipped by in Firefox. > > https://github.com/KhronosGroup/WebGL/pull/2405 strengthens the > conformance test. Thanks for pointing this out. > > -Ken > > > On Wed, May 24, 2017 at 10:36 AM, Kai Ninomiya wrote: > >> IIRC the EXT_disjoint_timer_query extension is not supposed to be >> available at all for WebGL 2 contexts. Getting that extension should fail. >> It's possible we forgot to add a conformance test for this behavior, and it >> slipped by in Firefox. >> >> On Wed, May 24, 2017 at 8:19 AM Tarek Sherif wrote: >> >>> Ah, I just realized I was only using the TIME_ELAPSED_EXT and >>> GPU_DISJOINT_EXT enums on the extensions, which is why they appeared to be >>> interchangeable. The presence of the original EXT_disjoint_timer_query on a >>> WebGL 2 context does still strike me as odd, since the text from spec I >>> quoted suggests that it shouldn't be. >>> >>> Tarek Sherif >>> http://tareksherif.net/ >>> https://www.biodigital.com/ >>> >>> >>> On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif wrote: >>> >>>> I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 >>>> contexts in Firefox. It allows both WebGL 1 (e.g. ext.createQueryEXT) and >>>> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed for this >>>> extension? The EXT_disjoint_timer_query spec doesn't mention the WebGL 2 >>>> usage, but does state: "This version of the disjoint_timer_query extension >>>> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of the >>>> extension for how it is exposed on WebGL 2.0 contexts." Does that mean >>>> EXT_disjoint_timer_query should behave as specified in >>>> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If so, >>>> it would seem that the WebGL 1-like functionality that Firefox exposes on >>>> that extension is incorrect. >>>> >>>> Either way, this all seems more confusing than it needs to be... >>>> >>>> Tarek Sherif >>>> http://tareksherif.net/ >>>> https://www.biodigital.com/ >>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed May 24 13:34:22 2017 From: jgi...@ (Jeff Gilbert) Date: Wed, 24 May 2017 13:34:22 -0700 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: I remember having objections to this. I'll try to hunt down the minutes for this, because I remember strongly disagreeing with this divergence. On Wed, May 24, 2017 at 1:07 PM, Tarek Sherif wrote: > Here are some relevant Firefox bug tickets: > https://bugzilla.mozilla.org/show_bug.cgi?id=1308057 > https://bugzilla.mozilla.org/show_bug.cgi?id=1328882 > > Tarek Sherif > http://tareksherif.net/ > https://www.biodigital.com/ > > > On Wed, May 24, 2017 at 1:55 PM, Kenneth Russell wrote: >> >> That's correct, it's not supposed to be advertised. >> EXT_disjoint_timer_query is for WebGL 1.0, and _webgl2 for 2.0. >> >> The split was made fairly late in the WebGL 2.0 spec process, which is >> probably why it slipped by in Firefox. >> >> https://github.com/KhronosGroup/WebGL/pull/2405 strengthens the >> conformance test. Thanks for pointing this out. >> >> -Ken >> >> >> On Wed, May 24, 2017 at 10:36 AM, Kai Ninomiya wrote: >>> >>> IIRC the EXT_disjoint_timer_query extension is not supposed to be >>> available at all for WebGL 2 contexts. Getting that extension should fail. >>> It's possible we forgot to add a conformance test for this behavior, and it >>> slipped by in Firefox. >>> >>> On Wed, May 24, 2017 at 8:19 AM Tarek Sherif wrote: >>>> >>>> Ah, I just realized I was only using the TIME_ELAPSED_EXT and >>>> GPU_DISJOINT_EXT enums on the extensions, which is why they appeared to be >>>> interchangeable. The presence of the original EXT_disjoint_timer_query on a >>>> WebGL 2 context does still strike me as odd, since the text from spec I >>>> quoted suggests that it shouldn't be. >>>> >>>> Tarek Sherif >>>> http://tareksherif.net/ >>>> https://www.biodigital.com/ >>>> >>>> >>>> On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif wrote: >>>>> >>>>> I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 >>>>> contexts in Firefox. It allows both WebGL 1 (e.g. ext.createQueryEXT) and >>>>> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed for this >>>>> extension? The EXT_disjoint_timer_query spec doesn't mention the WebGL 2 >>>>> usage, but does state: "This version of the disjoint_timer_query extension >>>>> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of the >>>>> extension for how it is exposed on WebGL 2.0 contexts." Does that mean >>>>> EXT_disjoint_timer_query should behave as specified in >>>>> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If so, it >>>>> would seem that the WebGL 1-like functionality that Firefox exposes on that >>>>> extension is incorrect. >>>>> >>>>> Either way, this all seems more confusing than it needs to be... >>>>> >>>>> Tarek Sherif >>>>> http://tareksherif.net/ >>>>> https://www.biodigital.com/ >>>>> >>>> >> > ----------------------------------------------------------- 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...@ Thu May 25 00:37:33 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 25 May 2017 09:37:33 +0200 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: WebGL 1 does not have the query functions, WebGL 2 does. The timer query extension defines constants to be used with the query functions, but since that function does not exist in WebGL 1, it is added to the extension object. Thus you have to make a choice, deliver the same extension that has different things in it depending on what context it came from, requiring the application programmer to test if the symbols are present, and if not test if they are present on the context itself, or have two extensions that're unambigously named which are two distinct objects with a well defined set of symbols. Neither choice is optimal as it rubs up against an impedance missmatch between how OpenGL ES does things, and how WebGL does things. On Wed, May 24, 2017 at 10:34 PM, Jeff Gilbert wrote: > > I remember having objections to this. I'll try to hunt down the > minutes for this, because I remember strongly disagreeing with this > divergence. > > On Wed, May 24, 2017 at 1:07 PM, Tarek Sherif wrote: > > Here are some relevant Firefox bug tickets: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1308057 > > https://bugzilla.mozilla.org/show_bug.cgi?id=1328882 > > > > Tarek Sherif > > http://tareksherif.net/ > > https://www.biodigital.com/ > > > > > > On Wed, May 24, 2017 at 1:55 PM, Kenneth Russell wrote: > >> > >> That's correct, it's not supposed to be advertised. > >> EXT_disjoint_timer_query is for WebGL 1.0, and _webgl2 for 2.0. > >> > >> The split was made fairly late in the WebGL 2.0 spec process, which is > >> probably why it slipped by in Firefox. > >> > >> https://github.com/KhronosGroup/WebGL/pull/2405 strengthens the > >> conformance test. Thanks for pointing this out. > >> > >> -Ken > >> > >> > >> On Wed, May 24, 2017 at 10:36 AM, Kai Ninomiya > wrote: > >>> > >>> IIRC the EXT_disjoint_timer_query extension is not supposed to be > >>> available at all for WebGL 2 contexts. Getting that extension should > fail. > >>> It's possible we forgot to add a conformance test for this behavior, > and it > >>> slipped by in Firefox. > >>> > >>> On Wed, May 24, 2017 at 8:19 AM Tarek Sherif > wrote: > >>>> > >>>> Ah, I just realized I was only using the TIME_ELAPSED_EXT and > >>>> GPU_DISJOINT_EXT enums on the extensions, which is why they appeared > to be > >>>> interchangeable. The presence of the original > EXT_disjoint_timer_query on a > >>>> WebGL 2 context does still strike me as odd, since the text from spec > I > >>>> quoted suggests that it shouldn't be. > >>>> > >>>> Tarek Sherif > >>>> http://tareksherif.net/ > >>>> https://www.biodigital.com/ > >>>> > >>>> > >>>> On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif > wrote: > >>>>> > >>>>> I'm confused by how EXT_disjoint_timer_query is behaving with WebGL 2 > >>>>> contexts in Firefox. It allows both WebGL 1 (e.g. > ext.createQueryEXT) and > >>>>> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed > for this > >>>>> extension? The EXT_disjoint_timer_query spec doesn't mention the > WebGL 2 > >>>>> usage, but does state: "This version of the disjoint_timer_query > extension > >>>>> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version of > the > >>>>> extension for how it is exposed on WebGL 2.0 contexts." Does that > mean > >>>>> EXT_disjoint_timer_query should behave as specified in > >>>>> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If > so, it > >>>>> would seem that the WebGL 1-like functionality that Firefox exposes > on that > >>>>> extension is incorrect. > >>>>> > >>>>> Either way, this all seems more confusing than it needs to be... > >>>>> > >>>>> Tarek Sherif > >>>>> http://tareksherif.net/ > >>>>> https://www.biodigital.com/ > >>>>> > >>>> > >> > > > > ----------------------------------------------------------- > 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 tsh...@ Thu May 25 05:44:26 2017 From: tsh...@ (Tarek Sherif) Date: Thu, 25 May 2017 08:44:26 -0400 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: TBH, the differences between the two versions of the extension strike me as too cosmetic to be worth this much trouble (though the _webgl2 version is cleaner). The problem with the Firefox implementation is that it diverges so completely from what's in the spec (and Mozilla's own documentation ). Further, this update seems to have made it possible to use WebGL 2 query objects with the WebGL 1-ish EXT_disjoint_timer_query, so code like the following works in Firefox: var gl = document.createElement("canvas").getContext("webgl2"); var ext = gl.getExtension("EXT_disjoint_timer_query"); var q = gl.createQuery(); ext.beginQueryEXT(ext.TIME_ELAPSED_EXT, q); ext.isQueryEXT(q); => true Again, not how the extension is specified, which makes it difficult to understand how it's supposed to work. Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ On Thu, May 25, 2017 at 3:37 AM, Florian B?sch wrote: > WebGL 1 does not have the query functions, WebGL 2 does. The timer query > extension defines constants to be used with the query functions, but since > that function does not exist in WebGL 1, it is added to the extension > object. Thus you have to make a choice, deliver the same extension that has > different things in it depending on what context it came from, requiring > the application programmer to test if the symbols are present, and if not > test if they are present on the context itself, or have two extensions > that're unambigously named which are two distinct objects with a well > defined set of symbols. Neither choice is optimal as it rubs up against an > impedance missmatch between how OpenGL ES does things, and how WebGL does > things. > > On Wed, May 24, 2017 at 10:34 PM, Jeff Gilbert > wrote: > >> >> I remember having objections to this. I'll try to hunt down the >> minutes for this, because I remember strongly disagreeing with this >> divergence. >> >> On Wed, May 24, 2017 at 1:07 PM, Tarek Sherif wrote: >> > Here are some relevant Firefox bug tickets: >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1308057 >> > https://bugzilla.mozilla.org/show_bug.cgi?id=1328882 >> > >> > Tarek Sherif >> > http://tareksherif.net/ >> > https://www.biodigital.com/ >> > >> > >> > On Wed, May 24, 2017 at 1:55 PM, Kenneth Russell >> wrote: >> >> >> >> That's correct, it's not supposed to be advertised. >> >> EXT_disjoint_timer_query is for WebGL 1.0, and _webgl2 for 2.0. >> >> >> >> The split was made fairly late in the WebGL 2.0 spec process, which is >> >> probably why it slipped by in Firefox. >> >> >> >> https://github.com/KhronosGroup/WebGL/pull/2405 strengthens the >> >> conformance test. Thanks for pointing this out. >> >> >> >> -Ken >> >> >> >> >> >> On Wed, May 24, 2017 at 10:36 AM, Kai Ninomiya >> wrote: >> >>> >> >>> IIRC the EXT_disjoint_timer_query extension is not supposed to be >> >>> available at all for WebGL 2 contexts. Getting that extension should >> fail. >> >>> It's possible we forgot to add a conformance test for this behavior, >> and it >> >>> slipped by in Firefox. >> >>> >> >>> On Wed, May 24, 2017 at 8:19 AM Tarek Sherif >> wrote: >> >>>> >> >>>> Ah, I just realized I was only using the TIME_ELAPSED_EXT and >> >>>> GPU_DISJOINT_EXT enums on the extensions, which is why they appeared >> to be >> >>>> interchangeable. The presence of the original >> EXT_disjoint_timer_query on a >> >>>> WebGL 2 context does still strike me as odd, since the text from >> spec I >> >>>> quoted suggests that it shouldn't be. >> >>>> >> >>>> Tarek Sherif >> >>>> http://tareksherif.net/ >> >>>> https://www.biodigital.com/ >> >>>> >> >>>> >> >>>> On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif >> wrote: >> >>>>> >> >>>>> I'm confused by how EXT_disjoint_timer_query is behaving with WebGL >> 2 >> >>>>> contexts in Firefox. It allows both WebGL 1 (e.g. >> ext.createQueryEXT) and >> >>>>> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed >> for this >> >>>>> extension? The EXT_disjoint_timer_query spec doesn't mention the >> WebGL 2 >> >>>>> usage, but does state: "This version of the disjoint_timer_query >> extension >> >>>>> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version >> of the >> >>>>> extension for how it is exposed on WebGL 2.0 contexts." Does that >> mean >> >>>>> EXT_disjoint_timer_query should behave as specified in >> >>>>> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If >> so, it >> >>>>> would seem that the WebGL 1-like functionality that Firefox exposes >> on that >> >>>>> extension is incorrect. >> >>>>> >> >>>>> Either way, this all seems more confusing than it needs to be... >> >>>>> >> >>>>> Tarek Sherif >> >>>>> http://tareksherif.net/ >> >>>>> https://www.biodigital.com/ >> >>>>> >> >>>> >> >> >> > >> >> ----------------------------------------------------------- >> 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 chr...@ Fri May 26 04:51:54 2017 From: chr...@ (Christophe Riccio) Date: Fri, 26 May 2017 13:51:54 +0200 Subject: [Public WebGL] Promote WEBGL_compressed_texture_s3tc_srgb to community approved In-Reply-To: References: Message-ID: Hi, Any update on this? We would like to ship linear rendering with WebGL but this extension is still not community approved. Chrome is implementing this extension as draft and it works well for us. Thanks, Christophe On Sat, Jan 14, 2017 at 10:58 PM, Kenneth Russell wrote: > Google supports moving this extension to community approved. Appreciate > Unity pointing out its need, and pushing for its support. > > -Ken > > > > On Sat, Jan 14, 2017 at 8:55 AM, Christophe Riccio < > christophe.riccio...@> wrote: > >> Yes what Mark said. :) >> >> On Sat, Jan 14, 2017 at 2:34 PM, Mark Callow wrote: >> >>> >>> On Jan 14, 2017, at 22:15, Florian B?sch wrote: >>> >>> On Sat, Jan 14, 2017 at 1:11 PM, Christophe Riccio < >>> christophe.riccio...@> wrote: >>> >>>> (storing color in linear directly) >>>> >>> sRGB stores nonlinear color. You write linear into gl_FragColor, but >>> stored is nonlinear. You just don't do the conversion. Performance impact >>> of a gamma conversion prior to writing to gl_FragColor is neglible. What >>> isn't neglible is the effects of blending, which you don't mention. >>> Blending in nonlinear space produces incorrect results. However the >>> conversion with the sRGB format is done inside the blending stage, and >>> therefore blending is done in linear space and only after blending it's >>> serialized to nonlinear space. >>> >>> >>> I think Christophe knows all that. His comment, which admittedly made me >>> pause for a moment too, refers to the loss of quality that occurs when you >>> have to store linear data in your texture, i.e. what happens if only >>> WEBGL_compressed_texture_s3tc is available. >>> >>> Regards >>> >>> -Mark >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue May 30 15:20:49 2017 From: jgi...@ (Jeff Gilbert) Date: Tue, 30 May 2017 15:20:49 -0700 Subject: [Public WebGL] Promote WEBGL_compressed_texture_s3tc_srgb to community approved In-Reply-To: References: Message-ID: Mozilla supports promoting this to Community Approved. On Fri, May 26, 2017 at 4:51 AM, Christophe Riccio wrote: > Hi, > > Any update on this? We would like to ship linear rendering with WebGL but > this extension is still not community approved. > Chrome is implementing this extension as draft and it works well for us. > > Thanks, > Christophe > > On Sat, Jan 14, 2017 at 10:58 PM, Kenneth Russell wrote: >> >> Google supports moving this extension to community approved. Appreciate >> Unity pointing out its need, and pushing for its support. >> >> -Ken >> >> >> >> On Sat, Jan 14, 2017 at 8:55 AM, Christophe Riccio >> wrote: >>> >>> Yes what Mark said. :) >>> >>> On Sat, Jan 14, 2017 at 2:34 PM, Mark Callow wrote: >>>> >>>> >>>> On Jan 14, 2017, at 22:15, Florian B?sch wrote: >>>> >>>> On Sat, Jan 14, 2017 at 1:11 PM, Christophe Riccio >>>> wrote: >>>>> >>>>> (storing color in linear directly) >>>> >>>> sRGB stores nonlinear color. You write linear into gl_FragColor, but >>>> stored is nonlinear. You just don't do the conversion. Performance impact of >>>> a gamma conversion prior to writing to gl_FragColor is neglible. What isn't >>>> neglible is the effects of blending, which you don't mention. Blending in >>>> nonlinear space produces incorrect results. However the conversion with the >>>> sRGB format is done inside the blending stage, and therefore blending is >>>> done in linear space and only after blending it's serialized to nonlinear >>>> space. >>>> >>>> >>>> I think Christophe knows all that. His comment, which admittedly made me >>>> pause for a moment too, refers to the loss of quality that occurs when you >>>> have to store linear data in your texture, i.e. what happens if only >>>> WEBGL_compressed_texture_s3tc is available. >>>> >>>> Regards >>>> >>>> -Mark >>>> >>> >> > ----------------------------------------------------------- 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 chr...@ Wed May 31 00:48:47 2017 From: chr...@ (Christophe Riccio) Date: Wed, 31 May 2017 09:48:47 +0200 Subject: [Public WebGL] Promote WEBGL_compressed_texture_s3tc_srgb to community approved In-Reply-To: References: Message-ID: What is the next step to make this happen? For us not having this extension supported by a web browser means decompressing most textures at runtime which is not great :/ On Wed, May 31, 2017 at 12:20 AM, Jeff Gilbert wrote: > Mozilla supports promoting this to Community Approved. > > On Fri, May 26, 2017 at 4:51 AM, Christophe Riccio > wrote: > > Hi, > > > > Any update on this? We would like to ship linear rendering with WebGL but > > this extension is still not community approved. > > Chrome is implementing this extension as draft and it works well for us. > > > > Thanks, > > Christophe > > > > On Sat, Jan 14, 2017 at 10:58 PM, Kenneth Russell > wrote: > >> > >> Google supports moving this extension to community approved. Appreciate > >> Unity pointing out its need, and pushing for its support. > >> > >> -Ken > >> > >> > >> > >> On Sat, Jan 14, 2017 at 8:55 AM, Christophe Riccio > >> wrote: > >>> > >>> Yes what Mark said. :) > >>> > >>> On Sat, Jan 14, 2017 at 2:34 PM, Mark Callow > wrote: > >>>> > >>>> > >>>> On Jan 14, 2017, at 22:15, Florian B?sch wrote: > >>>> > >>>> On Sat, Jan 14, 2017 at 1:11 PM, Christophe Riccio > >>>> wrote: > >>>>> > >>>>> (storing color in linear directly) > >>>> > >>>> sRGB stores nonlinear color. You write linear into gl_FragColor, but > >>>> stored is nonlinear. You just don't do the conversion. Performance > impact of > >>>> a gamma conversion prior to writing to gl_FragColor is neglible. What > isn't > >>>> neglible is the effects of blending, which you don't mention. > Blending in > >>>> nonlinear space produces incorrect results. However the conversion > with the > >>>> sRGB format is done inside the blending stage, and therefore blending > is > >>>> done in linear space and only after blending it's serialized to > nonlinear > >>>> space. > >>>> > >>>> > >>>> I think Christophe knows all that. His comment, which admittedly made > me > >>>> pause for a moment too, refers to the loss of quality that occurs > when you > >>>> have to store linear data in your texture, i.e. what happens if only > >>>> WEBGL_compressed_texture_s3tc is available. > >>>> > >>>> Regards > >>>> > >>>> -Mark > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed May 31 18:59:57 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 31 May 2017 18:59:57 -0700 Subject: [Public WebGL] Promote WEBGL_compressed_texture_s3tc_srgb to community approved In-Reply-To: References: Message-ID: Nothing else needs to be done. Thanks Christophe for pushing this and Jeff for providing the needed second vote from a WebGL implementer. Promoted to community approved in https://github.com/KhronosGroup/WebGL/pull/2411 . Will be exposed in Chrome by default in http://crbug.com/728465 . On Wed, May 31, 2017 at 12:48 AM, Christophe Riccio < christophe.riccio...@> wrote: > What is the next step to make this happen? > > For us not having this extension supported by a web browser means > decompressing most textures at runtime which is not great :/ > > On Wed, May 31, 2017 at 12:20 AM, Jeff Gilbert > wrote: > >> Mozilla supports promoting this to Community Approved. >> >> On Fri, May 26, 2017 at 4:51 AM, Christophe Riccio >> wrote: >> > Hi, >> > >> > Any update on this? We would like to ship linear rendering with WebGL >> but >> > this extension is still not community approved. >> > Chrome is implementing this extension as draft and it works well for us. >> > >> > Thanks, >> > Christophe >> > >> > On Sat, Jan 14, 2017 at 10:58 PM, Kenneth Russell >> wrote: >> >> >> >> Google supports moving this extension to community approved. Appreciate >> >> Unity pointing out its need, and pushing for its support. >> >> >> >> -Ken >> >> >> >> >> >> >> >> On Sat, Jan 14, 2017 at 8:55 AM, Christophe Riccio >> >> wrote: >> >>> >> >>> Yes what Mark said. :) >> >>> >> >>> On Sat, Jan 14, 2017 at 2:34 PM, Mark Callow >> wrote: >> >>>> >> >>>> >> >>>> On Jan 14, 2017, at 22:15, Florian B?sch wrote: >> >>>> >> >>>> On Sat, Jan 14, 2017 at 1:11 PM, Christophe Riccio >> >>>> wrote: >> >>>>> >> >>>>> (storing color in linear directly) >> >>>> >> >>>> sRGB stores nonlinear color. You write linear into gl_FragColor, but >> >>>> stored is nonlinear. You just don't do the conversion. Performance >> impact of >> >>>> a gamma conversion prior to writing to gl_FragColor is neglible. >> What isn't >> >>>> neglible is the effects of blending, which you don't mention. >> Blending in >> >>>> nonlinear space produces incorrect results. However the conversion >> with the >> >>>> sRGB format is done inside the blending stage, and therefore >> blending is >> >>>> done in linear space and only after blending it's serialized to >> nonlinear >> >>>> space. >> >>>> >> >>>> >> >>>> I think Christophe knows all that. His comment, which admittedly >> made me >> >>>> pause for a moment too, refers to the loss of quality that occurs >> when you >> >>>> have to store linear data in your texture, i.e. what happens if only >> >>>> WEBGL_compressed_texture_s3tc is available. >> >>>> >> >>>> Regards >> >>>> >> >>>> -Mark >> >>>> >> >>> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed May 31 19:29:51 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 31 May 2017 19:29:51 -0700 Subject: [Public WebGL] Re: WebGL 2 EXT_disjoint_timer_query in Firefox In-Reply-To: References: Message-ID: The reason for the divergence in the extension specs was because I couldn't figure out a way to write Web IDL that made the WebGLQueryEXT objects (for WebGL 1.0) into simple aliases for WebGLQuery on the WebGL 2.0 context. If someone can suggest a better way to spec this, we'd be happy to make Chrome behave the same way as Firefox and get rid of the EXT_disjoint_timer_query_webgl2 extension entirely. -Ken On Thu, May 25, 2017 at 5:44 AM, Tarek Sherif wrote: > TBH, the differences between the two versions of the extension strike me > as too cosmetic to be worth this much trouble (though the _webgl2 version > is cleaner). The problem with the Firefox implementation is that it > diverges so completely from what's in the spec (and Mozilla's own > documentation > ). > Further, this update > seems to have made > it possible to use WebGL 2 query objects with the WebGL 1-ish > EXT_disjoint_timer_query, so code like the following works in Firefox: > var gl = document.createElement("canvas").getContext("webgl2"); > var ext = gl.getExtension("EXT_disjoint_timer_query"); > var q = gl.createQuery(); > ext.beginQueryEXT(ext.TIME_ELAPSED_EXT, q); > ext.isQueryEXT(q); > => true > > Again, not how the extension is specified, which makes it difficult to > understand how it's supposed to work. > > > Tarek Sherif > http://tareksherif.net/ > https://www.biodigital.com/ > > > On Thu, May 25, 2017 at 3:37 AM, Florian B?sch wrote: > >> WebGL 1 does not have the query functions, WebGL 2 does. The timer query >> extension defines constants to be used with the query functions, but since >> that function does not exist in WebGL 1, it is added to the extension >> object. Thus you have to make a choice, deliver the same extension that has >> different things in it depending on what context it came from, requiring >> the application programmer to test if the symbols are present, and if not >> test if they are present on the context itself, or have two extensions >> that're unambigously named which are two distinct objects with a well >> defined set of symbols. Neither choice is optimal as it rubs up against an >> impedance missmatch between how OpenGL ES does things, and how WebGL does >> things. >> >> On Wed, May 24, 2017 at 10:34 PM, Jeff Gilbert >> wrote: >> >>> >>> I remember having objections to this. I'll try to hunt down the >>> minutes for this, because I remember strongly disagreeing with this >>> divergence. >>> >>> On Wed, May 24, 2017 at 1:07 PM, Tarek Sherif wrote: >>> > Here are some relevant Firefox bug tickets: >>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1308057 >>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1328882 >>> > >>> > Tarek Sherif >>> > http://tareksherif.net/ >>> > https://www.biodigital.com/ >>> > >>> > >>> > On Wed, May 24, 2017 at 1:55 PM, Kenneth Russell >>> wrote: >>> >> >>> >> That's correct, it's not supposed to be advertised. >>> >> EXT_disjoint_timer_query is for WebGL 1.0, and _webgl2 for 2.0. >>> >> >>> >> The split was made fairly late in the WebGL 2.0 spec process, which is >>> >> probably why it slipped by in Firefox. >>> >> >>> >> https://github.com/KhronosGroup/WebGL/pull/2405 strengthens the >>> >> conformance test. Thanks for pointing this out. >>> >> >>> >> -Ken >>> >> >>> >> >>> >> On Wed, May 24, 2017 at 10:36 AM, Kai Ninomiya >>> wrote: >>> >>> >>> >>> IIRC the EXT_disjoint_timer_query extension is not supposed to be >>> >>> available at all for WebGL 2 contexts. Getting that extension should >>> fail. >>> >>> It's possible we forgot to add a conformance test for this behavior, >>> and it >>> >>> slipped by in Firefox. >>> >>> >>> >>> On Wed, May 24, 2017 at 8:19 AM Tarek Sherif >>> wrote: >>> >>>> >>> >>>> Ah, I just realized I was only using the TIME_ELAPSED_EXT and >>> >>>> GPU_DISJOINT_EXT enums on the extensions, which is why they >>> appeared to be >>> >>>> interchangeable. The presence of the original >>> EXT_disjoint_timer_query on a >>> >>>> WebGL 2 context does still strike me as odd, since the text from >>> spec I >>> >>>> quoted suggests that it shouldn't be. >>> >>>> >>> >>>> Tarek Sherif >>> >>>> http://tareksherif.net/ >>> >>>> https://www.biodigital.com/ >>> >>>> >>> >>>> >>> >>>> On Wed, May 24, 2017 at 9:29 AM, Tarek Sherif >>> wrote: >>> >>>>> >>> >>>>> I'm confused by how EXT_disjoint_timer_query is behaving with >>> WebGL 2 >>> >>>>> contexts in Firefox. It allows both WebGL 1 (e.g. >>> ext.createQueryEXT) and >>> >>>>> WebGL 2 (gl.createQuery) usage. Is the WebGL 2 usage is guaranteed >>> for this >>> >>>>> extension? The EXT_disjoint_timer_query spec doesn't mention the >>> WebGL 2 >>> >>>>> usage, but does state: "This version of the disjoint_timer_query >>> extension >>> >>>>> is exposed only on on WebGL 1.0 contexts. See the _webgl2 version >>> of the >>> >>>>> extension for how it is exposed on WebGL 2.0 contexts." Does that >>> mean >>> >>>>> EXT_disjoint_timer_query should behave as specified in >>> >>>>> EXT_disjoint_timer_query_webgl2 when using a WebGL 2 context? If >>> so, it >>> >>>>> would seem that the WebGL 1-like functionality that Firefox >>> exposes on that >>> >>>>> extension is incorrect. >>> >>>>> >>> >>>>> Either way, this all seems more confusing than it needs to be... >>> >>>>> >>> >>>>> Tarek Sherif >>> >>>>> http://tareksherif.net/ >>> >>>>> https://www.biodigital.com/ >>> >>>>> >>> >>>> >>> >> >>> > >>> >>> ----------------------------------------------------------- >>> 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: