From pya...@ Mon Feb 2 13:48:22 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 2 Feb 2015 22:48:22 +0100 Subject: [Public WebGL] Re: retrograde webgl support levels In-Reply-To: References: Message-ID: Excellent thank you Jamie for digging this info up. On Mon, Feb 2, 2015 at 10:36 PM, Jamie Madill wrote: > Hi Florian & everyone, > > This is an intentional change that affects D3D9 only. On D3D11 our varying > limits are significantly relaxed. > > There was actually a bug, and we were reporting one more varying that we > could support, if the user would draw with point sprites enabled. See this > ANGLE commit: > > https://chromium-review.googlesource.com/221062 > > This was a long-standing bug uncovered by additional testing added by > Austin Kinross. > > > On Sat, Jan 31, 2015 at 4:01 AM, Florian B?sch wrote: > >> MAX_VARYING_VECTORS drop warning: A a dip in support levels from 10 to 9 >> by 4.6% (see http://codeflow.org/pictures/max-varying-vectors.jpeg also >> attached). >> >> This change is only present in Google Chrome on Windows. OSX, Linux, >> ChromeOS and Mobiles are not affected. IE and Firefox are also not affected. >> >> The dip in support coincides with the Google Chrome version that also >> added EXT_sRGB support, which happened about a week ago. It can be expected >> that the full impact will unfold next month and be in the range of around >> 20%. >> >> As with previous drops of this nature I'm issuing a warning because: >> >> - There are not many varying vectors to use, and 9 varying vectors is >> the second lowest value observed. This makes it likely that applications >> will break because of this. >> - The varying vector level of 10 reached a 99% level in October 2014, >> and so this minimum support level has some historical support. >> - The change is abrupt and vendor/OS isolated. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Feb 2 17:27:33 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 2 Feb 2015 17:27:33 -0800 Subject: [Public WebGL] Re: extensions status In-Reply-To: References: Message-ID: On Fri, Jan 30, 2015 at 11:08 PM, Florian B?sch wrote: > On Sat, Jan 31, 2015 at 12:10 AM, Kenneth Russell wrote: >> >> No intent to implement these. I don't remember all of the issues we >> ran into, but when we investigated adding support I recall multiple >> issues in ANGLE that made us abandon the effort. > > Excellent, thank you. I propose to reject these extensions: > https://github.com/KhronosGroup/WebGL/pull/846 > > They will not land in ANGLE (and so support would be difficult/impossible in > Chrome/Firefox) > Google will not implement them > Firefox has withdrawn their initial implementation (I interprete this as > tacit approval of mozilla to reject these extensions) I'd like to hear Mozilla's explicit feedback on this before rejecting these extensions. > Microsoft has not stated their position but is unlikely to follow where > Chrome and Firefox do not go > Apple has not stated their position, but is unlikely to follow where Chrome > and Firefox do not go (and they also use ANGLE) > > >> >> On the other hand we >> will absolutely implement EXT_color_buffer_float for WebGL 2.0. > > That's understood. ----------------------------------------------------------- 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...@ Mon Feb 2 17:28:00 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 2 Feb 2015 17:28:00 -0800 Subject: [Public WebGL] OES_fbo_render_mipmap In-Reply-To: References: Message-ID: On Fri, Jan 30, 2015 at 11:21 PM, Florian B?sch wrote: > Proposing to move OES_fbo_render_mipmap to draft so that vendors can start > experimenting it whenver they're ready to do so. > > There is no IDL for it that we can disagree about. > There is no WebGL specific behavioral change to disagree about (it's a > mirroring extension) > Because it is a mirroring extension it barely has any text in it to disagree > about. > The functional change it introduces is very small, and so it's unlikely > there'll be implementation difficulties (but unless we move to draft we > won't find out) > It has an example stated on the extension which is nearly a unit test and > provides a good documentation of what the behavioral change means even > without consulting the underlying ES extension. > > I have assigned Extension #28 to it and prepared a suitable pull request: > https://github.com/KhronosGroup/WebGL/pull/847 > > Please voice your objections to the move to draft now if you have any. This sounds good to me. Others? ----------------------------------------------------------- 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...@ Tue Feb 3 17:24:44 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 3 Feb 2015 17:24:44 -0800 Subject: [Public WebGL] OES_fbo_render_mipmap In-Reply-To: References: Message-ID: Sounds good to me. On Mon, Feb 2, 2015 at 5:28 PM, Kenneth Russell wrote: > > On Fri, Jan 30, 2015 at 11:21 PM, Florian B?sch wrote: > > Proposing to move OES_fbo_render_mipmap to draft so that vendors can > start > > experimenting it whenver they're ready to do so. > > > > There is no IDL for it that we can disagree about. > > There is no WebGL specific behavioral change to disagree about (it's a > > mirroring extension) > > Because it is a mirroring extension it barely has any text in it to > disagree > > about. > > The functional change it introduces is very small, and so it's unlikely > > there'll be implementation difficulties (but unless we move to draft we > > won't find out) > > It has an example stated on the extension which is nearly a unit test and > > provides a good documentation of what the behavioral change means even > > without consulting the underlying ES extension. > > > > I have assigned Extension #28 to it and prepared a suitable pull request: > > https://github.com/KhronosGroup/WebGL/pull/847 > > > > Please voice your objections to the move to draft now if you have any. > > This sounds good to me. Others? > > ----------------------------------------------------------- > 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...@ Wed Feb 4 06:51:55 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 4 Feb 2015 15:51:55 +0100 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: Ken, if you could merge the proposal we can talk about moving it to rejected. On Tue, Jan 27, 2015 at 1:56 AM, Kenneth Russell wrote: > The https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/ > extension already allows applications to allocate framebuffer objects > with a depth-texture attachment having 24 bits of precision. How > urgent is it to support renderbuffers with the analogous format? > > We're focused on getting WebGL 2.0 prototypes and conformance tests > out the door and I think that exposing this extension will be a > distraction. Adding a new extension to WebGL implementations is a > non-trivial exercise due to the large number of platforms and browsers > involved. > > -Ken > > > > On Mon, Jan 26, 2015 at 1:38 PM, Florian B?sch wrote: > > I propose to add the extension OES_depth24 to WebGL for these reasons: > > > > It's really the companion extension to depth textures since they enjoy > about > > the same level of support (and depth textures support 24-bit depths) > > The frontbuffer on WebGL is already almost always 24-bit > > Framebuffer objects can only choose a 16-bit depth renderbuffer (and so > are > > at a disadvantage) > > It is well supported on mobiles (around 92%) > > It has been core functionality on desktops since OpenGL 3.1 > > It's defined on desktops since ARB_framebuffer_object (which is a > > prerequisite to FBOs) > > It's supported by Direct3D 9 (D24X8) > > Considerable time will pass until WebGL 2.0 can be as widely supported. > > > > A pull request has been prepared for review: > > https://github.com/KhronosGroup/WebGL/pull/831 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 4 11:17:36 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 4 Feb 2015 11:17:36 -0800 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: OK, merged mainly to move it to the rejected state for documentation purposes. On Wed, Feb 4, 2015 at 6:51 AM, Florian B?sch wrote: > Ken, if you could merge the proposal we can talk about moving it to > rejected. > > On Tue, Jan 27, 2015 at 1:56 AM, Kenneth Russell wrote: >> >> The https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/ >> extension already allows applications to allocate framebuffer objects >> with a depth-texture attachment having 24 bits of precision. How >> urgent is it to support renderbuffers with the analogous format? >> >> We're focused on getting WebGL 2.0 prototypes and conformance tests >> out the door and I think that exposing this extension will be a >> distraction. Adding a new extension to WebGL implementations is a >> non-trivial exercise due to the large number of platforms and browsers >> involved. >> >> -Ken >> >> >> >> On Mon, Jan 26, 2015 at 1:38 PM, Florian B?sch wrote: >> > I propose to add the extension OES_depth24 to WebGL for these reasons: >> > >> > It's really the companion extension to depth textures since they enjoy >> > about >> > the same level of support (and depth textures support 24-bit depths) >> > The frontbuffer on WebGL is already almost always 24-bit >> > Framebuffer objects can only choose a 16-bit depth renderbuffer (and so >> > are >> > at a disadvantage) >> > It is well supported on mobiles (around 92%) >> > It has been core functionality on desktops since OpenGL 3.1 >> > It's defined on desktops since ARB_framebuffer_object (which is a >> > prerequisite to FBOs) >> > It's supported by Direct3D 9 (D24X8) >> > Considerable time will pass until WebGL 2.0 can be as widely supported. >> > >> > A pull request has been prepared for review: >> > https://github.com/KhronosGroup/WebGL/pull/831 > > ----------------------------------------------------------- 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 Feb 4 11:32:04 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 4 Feb 2015 20:32:04 +0100 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: Excellent, thank you. So is there consensus that guaranteed 24-bit depth precision can be achieved with a depth texture and that is a suitable alternative to a 24-bit renderbuffer? On Wed, Feb 4, 2015 at 8:17 PM, Kenneth Russell wrote: > OK, merged mainly to move it to the rejected state for documentation > purposes. > > > On Wed, Feb 4, 2015 at 6:51 AM, Florian B?sch wrote: > > Ken, if you could merge the proposal we can talk about moving it to > > rejected. > > > > On Tue, Jan 27, 2015 at 1:56 AM, Kenneth Russell wrote: > >> > >> The > https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/ > >> extension already allows applications to allocate framebuffer objects > >> with a depth-texture attachment having 24 bits of precision. How > >> urgent is it to support renderbuffers with the analogous format? > >> > >> We're focused on getting WebGL 2.0 prototypes and conformance tests > >> out the door and I think that exposing this extension will be a > >> distraction. Adding a new extension to WebGL implementations is a > >> non-trivial exercise due to the large number of platforms and browsers > >> involved. > >> > >> -Ken > >> > >> > >> > >> On Mon, Jan 26, 2015 at 1:38 PM, Florian B?sch > wrote: > >> > I propose to add the extension OES_depth24 to WebGL for these reasons: > >> > > >> > It's really the companion extension to depth textures since they enjoy > >> > about > >> > the same level of support (and depth textures support 24-bit depths) > >> > The frontbuffer on WebGL is already almost always 24-bit > >> > Framebuffer objects can only choose a 16-bit depth renderbuffer (and > so > >> > are > >> > at a disadvantage) > >> > It is well supported on mobiles (around 92%) > >> > It has been core functionality on desktops since OpenGL 3.1 > >> > It's defined on desktops since ARB_framebuffer_object (which is a > >> > prerequisite to FBOs) > >> > It's supported by Direct3D 9 (D24X8) > >> > Considerable time will pass until WebGL 2.0 can be as widely > supported. > >> > > >> > A pull request has been prepared for review: > >> > https://github.com/KhronosGroup/WebGL/pull/831 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 4 11:38:22 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 4 Feb 2015 11:38:22 -0800 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: I think this is a reasonable workaround and would prefer to reject OES_depth24 to keep ourselves focused. On Wed, Feb 4, 2015 at 11:32 AM, Florian B?sch wrote: > Excellent, thank you. So is there consensus that guaranteed 24-bit depth > precision can be achieved with a depth texture and that is a suitable > alternative to a 24-bit renderbuffer? > > On Wed, Feb 4, 2015 at 8:17 PM, Kenneth Russell wrote: >> >> OK, merged mainly to move it to the rejected state for documentation >> purposes. >> >> >> On Wed, Feb 4, 2015 at 6:51 AM, Florian B?sch wrote: >> > Ken, if you could merge the proposal we can talk about moving it to >> > rejected. >> > >> > On Tue, Jan 27, 2015 at 1:56 AM, Kenneth Russell wrote: >> >> >> >> The >> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/ >> >> extension already allows applications to allocate framebuffer objects >> >> with a depth-texture attachment having 24 bits of precision. How >> >> urgent is it to support renderbuffers with the analogous format? >> >> >> >> We're focused on getting WebGL 2.0 prototypes and conformance tests >> >> out the door and I think that exposing this extension will be a >> >> distraction. Adding a new extension to WebGL implementations is a >> >> non-trivial exercise due to the large number of platforms and browsers >> >> involved. >> >> >> >> -Ken >> >> >> >> >> >> >> >> On Mon, Jan 26, 2015 at 1:38 PM, Florian B?sch >> >> wrote: >> >> > I propose to add the extension OES_depth24 to WebGL for these >> >> > reasons: >> >> > >> >> > It's really the companion extension to depth textures since they >> >> > enjoy >> >> > about >> >> > the same level of support (and depth textures support 24-bit depths) >> >> > The frontbuffer on WebGL is already almost always 24-bit >> >> > Framebuffer objects can only choose a 16-bit depth renderbuffer (and >> >> > so >> >> > are >> >> > at a disadvantage) >> >> > It is well supported on mobiles (around 92%) >> >> > It has been core functionality on desktops since OpenGL 3.1 >> >> > It's defined on desktops since ARB_framebuffer_object (which is a >> >> > prerequisite to FBOs) >> >> > It's supported by Direct3D 9 (D24X8) >> >> > Considerable time will pass until WebGL 2.0 can be as widely >> >> > supported. >> >> > >> >> > A pull request has been prepared for review: >> >> > https://github.com/KhronosGroup/WebGL/pull/831 >> > >> > > > ----------------------------------------------------------- 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 rog...@ Wed Feb 4 16:01:23 2015 From: rog...@ (Roger Fong) Date: Wed, 4 Feb 2015 16:01:23 -0800 Subject: [Public WebGL] Querying for read buffer format Message-ID: Hello again folks, I have (another) potentially stupid question, which thus may potentially be easy to answer. I'm working on some code to cover texture format validation in WebGL2 and I'm focusing right now on CopyTexImage2D. It seems easy to validate the format, internal format, and type combination if I know all 3. However, for CopyTexImage2D I need to get format and type from table 3.15 in the GLES3 spec. Page 152 of https://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.3.pdf My question is, how do I determine my read buffer color format? I was expecting there to be enums associated with the 4 items in that column of the table and a matching query but that doesn't seem to be the case. What am I missing here? Also is this the right place to ask questions about implementation? Thanks, Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 4 16:22:25 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 4 Feb 2015 16:22:25 -0800 Subject: [Public WebGL] Querying for read buffer format In-Reply-To: References: Message-ID: On Wed, Feb 4, 2015 at 4:01 PM, Roger Fong wrote: > Hello again folks, > > I have (another) potentially stupid question, which thus may potentially be > easy to answer. > > I'm working on some code to cover texture format validation in WebGL2 and > I'm focusing right now on CopyTexImage2D. > > It seems easy to validate the format, internal format, and type combination > if I know all 3. However, for CopyTexImage2D I need to get format and type > from table 3.15 in the GLES3 spec. > Page 152 of > https://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.3.pdf > > My question is, how do I determine my read buffer color format? Hi Roger, I think the paragraph beginning with "Otherwise the effective internal format is determined by the row in table 3.17 or table 3.18..." defines the rules for the "default" frame buffer -- that allocated by the WebGL implementation itself. Typically this will just be a texture attached to a framebuffer which is inaccessible to the WebGL application. Either way, it ought to be possible to make enough queries of the RGBA channels' sizes that the effective internal format can be inferred. Does that answer your question? > I was expecting there to be enums associated with the 4 items in that column > of the table and a matching query but that doesn't seem to be the case. What > am I missing here? > > Also is this the right place to ask questions about implementation? Yes, certainly. -Ken > Thanks, > Roger ----------------------------------------------------------- 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 Feb 4 23:11:27 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 5 Feb 2015 08:11:27 +0100 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: Proposing to reject OES_depth24, reason noted in the change revision: https://github.com/KhronosGroup/WebGL/pull/851 Last chance for anybody to object to canning this one. On Wed, Feb 4, 2015 at 8:38 PM, Kenneth Russell wrote: > I think this is a reasonable workaround and would prefer to reject > OES_depth24 to keep ourselves focused. > > > On Wed, Feb 4, 2015 at 11:32 AM, Florian B?sch wrote: > > Excellent, thank you. So is there consensus that guaranteed 24-bit depth > > precision can be achieved with a depth texture and that is a suitable > > alternative to a 24-bit renderbuffer? > > > > On Wed, Feb 4, 2015 at 8:17 PM, Kenneth Russell wrote: > >> > >> OK, merged mainly to move it to the rejected state for documentation > >> purposes. > >> > >> > >> On Wed, Feb 4, 2015 at 6:51 AM, Florian B?sch wrote: > >> > Ken, if you could merge the proposal we can talk about moving it to > >> > rejected. > >> > > >> > On Tue, Jan 27, 2015 at 1:56 AM, Kenneth Russell > wrote: > >> >> > >> >> The > >> >> > https://www.khronos.org/registry/webgl/extensions/WEBGL_depth_texture/ > >> >> extension already allows applications to allocate framebuffer objects > >> >> with a depth-texture attachment having 24 bits of precision. How > >> >> urgent is it to support renderbuffers with the analogous format? > >> >> > >> >> We're focused on getting WebGL 2.0 prototypes and conformance tests > >> >> out the door and I think that exposing this extension will be a > >> >> distraction. Adding a new extension to WebGL implementations is a > >> >> non-trivial exercise due to the large number of platforms and > browsers > >> >> involved. > >> >> > >> >> -Ken > >> >> > >> >> > >> >> > >> >> On Mon, Jan 26, 2015 at 1:38 PM, Florian B?sch > >> >> wrote: > >> >> > I propose to add the extension OES_depth24 to WebGL for these > >> >> > reasons: > >> >> > > >> >> > It's really the companion extension to depth textures since they > >> >> > enjoy > >> >> > about > >> >> > the same level of support (and depth textures support 24-bit > depths) > >> >> > The frontbuffer on WebGL is already almost always 24-bit > >> >> > Framebuffer objects can only choose a 16-bit depth renderbuffer > (and > >> >> > so > >> >> > are > >> >> > at a disadvantage) > >> >> > It is well supported on mobiles (around 92%) > >> >> > It has been core functionality on desktops since OpenGL 3.1 > >> >> > It's defined on desktops since ARB_framebuffer_object (which is a > >> >> > prerequisite to FBOs) > >> >> > It's supported by Direct3D 9 (D24X8) > >> >> > Considerable time will pass until WebGL 2.0 can be as widely > >> >> > supported. > >> >> > > >> >> > A pull request has been prepared for review: > >> >> > https://github.com/KhronosGroup/WebGL/pull/831 > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 4 23:15:09 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 5 Feb 2015 08:15:09 +0100 Subject: [Public WebGL] OES_fbo_render_mipmap In-Reply-To: References: Message-ID: Tickets for this extension have been created: Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1129354 Chrome: https://code.google.com/p/chromium/issues/detail?id=455150 IE: https://connect.microsoft.com/IE/feedback/details/1114887 Webkit: https://bugs.webkit.org/show_bug.cgi?id=141242 ANGLE: https://code.google.com/p/angleproject/issues/detail?id=905 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 4 23:59:38 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 5 Feb 2015 08:59:38 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: WEBGL_compressed_texture_es3 has moved to draft: https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_es3/ Tickets have been created: Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1129803 Chrome: https://code.google.com/p/chromium/issues/detail?id=455568 Webkit: https://bugs.webkit.org/show_bug.cgi?id=141285 IE: https://connect.microsoft.com/IE/feedback/details/1116140 ANGLE: https://code.google.com/p/angleproject/issues/detail?id=908 Questions on missing error definitions and texturing functions have been attached to the extension text. The ES 3.0.4 specification allows for compressedTexImage3D and > compressedTexSubImage3D which are missing from this specification, should > it be added? WebGL 1.0 of course doesn't have tex[sub]Image3D. But it's possible that at some point we'd introduce an extension for it (the extension hasn't been formally proposed, but previously discussed unfavorably). I would propose not to define the tex[Sub]Image3D functions in this extension (i.e. leave that as it is) and if we would define the 3D texture extension for WebGL 1.0, we'd note its interaction with this extension (i.e. we'd have to add WEBGL_texture_3D because that one would also contain the symbols compressedTexImage3D and compressedTexSubImage3D). That's a bit messy of course, but it's likey we won't introduce 3D textures for WebGL 1.0 anyway, so the risk is probably small. The ES 3.0.4 specification defines the errors INVALID_OPERATION, should it > be added? > Anybody know the answer to that one? > The ES 3.0.4 specification defines the errors INVALID_VALUE for other > cases than compressed size missmatch, should these be added? Anybody know the answer to that one? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rog...@ Thu Feb 5 10:47:02 2015 From: rog...@ (Roger Fong) Date: Thu, 5 Feb 2015 10:47:02 -0800 Subject: [Public WebGL] Querying for read buffer format In-Reply-To: References: Message-ID: Yup! I didn't draw the connection that the read buffer was WebGL implementation dependent. Thanks! Roger On Wed, Feb 4, 2015 at 4:22 PM, Kenneth Russell wrote: > On Wed, Feb 4, 2015 at 4:01 PM, Roger Fong wrote: > > Hello again folks, > > > > I have (another) potentially stupid question, which thus may potentially > be > > easy to answer. > > > > I'm working on some code to cover texture format validation in WebGL2 and > > I'm focusing right now on CopyTexImage2D. > > > > It seems easy to validate the format, internal format, and type > combination > > if I know all 3. However, for CopyTexImage2D I need to get format and > type > > from table 3.15 in the GLES3 spec. > > Page 152 of > > https://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.3.pdf > > > > My question is, how do I determine my read buffer color format? > > Hi Roger, > > I think the paragraph beginning with "Otherwise the effective internal > format is determined by the row in table 3.17 or table 3.18..." > defines the rules for the "default" frame buffer -- that allocated by > the WebGL implementation itself. Typically this will just be a texture > attached to a framebuffer which is inaccessible to the WebGL > application. Either way, it ought to be possible to make enough > queries of the RGBA channels' sizes that the effective internal format > can be inferred. Does that answer your question? > > > > I was expecting there to be enums associated with the 4 items in that > column > > of the table and a matching query but that doesn't seem to be the case. > What > > am I missing here? > > > > Also is this the right place to ask questions about implementation? > > Yes, certainly. > > -Ken > > > > Thanks, > > Roger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Feb 5 18:51:17 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 5 Feb 2015 18:51:17 -0800 Subject: [Public WebGL] OES_fbo_render_mipmap In-Reply-To: References: Message-ID: Thanks Florian for pushing on this. On Wed, Feb 4, 2015 at 11:15 PM, Florian B?sch wrote: > Tickets for this extension have been created: > > Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1129354 > Chrome: https://code.google.com/p/chromium/issues/detail?id=455150 > IE: https://connect.microsoft.com/IE/feedback/details/1114887 > Webkit: https://bugs.webkit.org/show_bug.cgi?id=141242 > ANGLE: https://code.google.com/p/angleproject/issues/detail?id=905 ----------------------------------------------------------- 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 Feb 5 19:00:54 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 5 Feb 2015 19:00:54 -0800 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Wed, Feb 4, 2015 at 11:59 PM, Florian B?sch wrote: > WEBGL_compressed_texture_es3 has moved to draft: > https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_es3/ > > Tickets have been created: > > Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1129803 > Chrome: https://code.google.com/p/chromium/issues/detail?id=455568 > Webkit: https://bugs.webkit.org/show_bug.cgi?id=141285 > IE: https://connect.microsoft.com/IE/feedback/details/1116140 > ANGLE: https://code.google.com/p/angleproject/issues/detail?id=908 > > Questions on missing error definitions and texturing functions have been > attached to the extension text. > >> The ES 3.0.4 specification allows for compressedTexImage3D and >> compressedTexSubImage3D which are missing from this specification, should it >> be added? > > > WebGL 1.0 of course doesn't have tex[sub]Image3D. But it's possible that at > some point we'd introduce an extension for it (the extension hasn't been > formally proposed, but previously discussed unfavorably). I would propose > not to define the tex[Sub]Image3D functions in this extension (i.e. leave > that as it is) and if we would define the 3D texture extension for WebGL > 1.0, we'd note its interaction with this extension (i.e. we'd have to add > WEBGL_texture_3D because that one would also contain the symbols > compressedTexImage3D and compressedTexSubImage3D). That's a bit messy of > course, but it's likey we won't introduce 3D textures for WebGL 1.0 anyway, > so the risk is probably small. > >> The ES 3.0.4 specification defines the errors INVALID_OPERATION, should it >> be added? > > Anybody know the answer to that one? It looks like the other WebGL extensions defining compressed textures use INVALID_VALUE for this size check. I assume the conformance tests are already verifying this. I'm in favor of minimizing the churn of both the specs and tests in this area, so would suggest it be left as is. >> The ES 3.0.4 specification defines the errors INVALID_VALUE for other >> cases than compressed size missmatch, should these be added? > > Anybody know the answer to that one? I'm not sure what portion of the spec you're referring to. Please feel free to submit pull requests containing any clarifications you suggest and they can be discussed there. Thanks. -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 pya...@ Thu Feb 5 23:30:43 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 08:30:43 +0100 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float Message-ID: *Overview* The proposal to reject WEBGL_color_buffer_float and EXT_color_buffer_half_float is pending: https://github.com/KhronosGroup/WebGL/pull/846 The task is to decide if These extensions should be rejected. This is not an easy decision because these extensions are community approved. However the approval is based on a technicality raised by Mozilla (see history). *Justification* Community approved extensions can be rejected as the extension development process states. A *community approved* extension can only be rejected in extraordinary > circumstances. An extension has to move through the extension process, as the extension development process states: Every extension should advance to *Khronos ratified*. If an extension cannot advance it can be rejected, as the extension development process states: If an extension cannot advance through the extension process it can be > *rejected*. It is customary not to propose ratification unless several vendors have exposed implementations (in fact this is a semi-formal standard for community approval as well). If there is no intent to implement these extensions, as is stated by Google (see history), then these extensions cannot move to ratified. If they cannot move to ratified, then they have to be rejected. I posit that these community approved extensions are probably impossible to ratify, and that they should therefore be rejected. *History* These extensions where moved to community approved November 24th 2014 based on a pull request by Jeff Gilbert: https://www.khronos.org/webgl/public-mailing-list/archives/1411/msg00088.html Previous discussion to move these extensions out of draft was initiated by Dan Glastonbury July 23rd 2014: https://www.khronos.org/webgl/public-mailing-list/archives/1407/msg00050.html On July 23rd Kenneth Russel notes: https://www.khronos.org/webgl/public-mailing-list/archives/1407/msg00051.html Unfortunately, both spec and implementation problems were encountered > while trying to implement WEBGL_color_buffer_float against OpenGL ES > 2.0 (ANGLE, in particular). On January 31st 2015 Kenneth Russel reaffirms that there is no intent by Google to implement these extensions: https://www.khronos.org/webgl/public-mailing-list/archives/1501/msg00136.html Mozilla has retracted their implementation of these extensions and as of January 2015, they where no longer available in Firefox. Feedback from Apple, Microsoft and Mozilla on these extensions is outstanding. Calls for feedback where made: - January 14th 2015: https://www.khronos.org/webgl/public-mailing-list/archives/1501/msg00050.html - January 24th 2015: https://www.khronos.org/webgl/public-mailing-list/archives/1501/msg00068.html - January 27th 2015: https://www.khronos.org/webgl/public-mailing-list/archives/1501/msg00124.html *Suggested course of action* I propose that objections to the proposal to reject these extensions is registered by February 20th 2015 latest (2 weeks from now), and that if no objections are raised these extensions are rejected fortwith. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 00:53:59 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 09:53:59 +0100 Subject: [Public WebGL] Re: retrograde webgl support levels In-Reply-To: References: Message-ID: Progress on webgl support is flagging on windows. Late 2014 and early 2015 where good times for WebGL overall, reaching new all time highs with currently 86.1%. This is largely thanks to rapidly advancing support in the past months by Internet Explorer, iOS and OSX safari. Even traditional sorrow spots like Android Tablets are showing promising signs to recovery. Inside that progress however the picture is more mixed, windows in particular has a problem across all browser vendors. On Windows the situation presents itself as follows: - Chrome: A high of 97.1% established in December 2013 has not been surpassed since (currently 92.8%). In particular a local peak of 95.3% in August 2014 (just before a bogus blacklist entry got inadvertently released) has also not been surpassed since. The post recovery curve is now flat since November 2014. - Firefox: A high of 83% established 2014 has not been surpassed since (currently 81.1%). After a rapid dip in september/october/november 2014 it has started to recover, but the curve is now flat again. - Internet Explorer: After a quick start into high levels of WebGL support during October 2013 at 0% to November 2014 at 79.4%, a high was reached in 83.5% in January and has not been surpassed since. The curve for activation has also flattened out since November 2014. I can only speculate as to the reasons of these developments, but I suspect it would be a combination of these factors: - Internet Explorer is still struggling to expediently replace older versions. Although that situation has improved, the peak to peak distance of IE versions is: 7->8 = 28 months, 8->9 = 18 months, 9->10 = 10 months, 10 -> 11 = 14 months, and so this does contribute to the flagging advance in WebGL support by Internet Explorer. - Driver/Hardware issues are preventing support from closing the remaining gap as well. At current rates (which might not be indicative to future activation rates), support on Windows for WebGL will not advance beyond 90% in a meaningful way for a very long time. As is usual, the last mile is usually the hardest, and so I'd *encourage everyone to look into ways to close that last 10% gap.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 01:45:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 10:45:21 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Fri, Feb 6, 2015 at 4:00 AM, Kenneth Russell wrote: > >> The ES 3.0.4 specification defines the errors INVALID_OPERATION, should > it > >> be added? > > > > Anybody know the answer to that one? > > It looks like the other WebGL extensions defining compressed textures > use INVALID_VALUE for this size check. I assume the conformance tests > are already verifying this. I'm in favor of minimizing the churn of > both the specs and tests in this area, so would suggest it be left as > is. INVALID_OPERATION is issued by compressedTexImage2D if: - the format does not match the internal format - If additional restrictions specified by the compression format specification apply and aren't satisfied INVALID_OPERATION is issued by compressedTexSubImage2D if: - xoffset or yoffset are not zero - width and height don't match the dimension of the texture level (is relaxed for specific formats which are easily modified) I'm not sure what portion of the spec you're referring to. Please feel > free to submit pull requests containing any clarifications you suggest > and they can be discussed there. Thanks. > INVALID_VALUE is issued in addition to dimension mismatch when: - The encoding of the compressed texture doesn't match the format specification -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Fri Feb 6 06:36:03 2015 From: ash...@ (Ashley Gullen) Date: Fri, 6 Feb 2015 14:36:03 +0000 Subject: [Public WebGL] Re: retrograde webgl support levels In-Reply-To: References: Message-ID: I think the main problem is the last <10% are cases where there is a poor quality graphics driver for old hardware/OS combos which the vendor no longer maintains driver updates for so will probably never be fixed. This then ties the driver update to the hardware upgrade cycle. If that kind of machine is only upgraded/replaced in 5 year's time, then it will remain blacklisted for the entirety of that duration. I think the only solution to cover that kind of system is a software renderer, which I think Chrome/Windows (SwiftShader) and IE11 (WARP? [citation needed]) have. But that only works OK-ish with a great CPU, and I doubt great CPUs correlate with old blacklisted systems. Might just have to wait it out. On 6 February 2015 at 08:53, Florian B?sch wrote: > Progress on webgl support is flagging on windows. Late 2014 and early 2015 > where good times for WebGL overall, reaching new all time highs with > currently 86.1%. This is largely thanks to rapidly advancing support in the > past months by Internet Explorer, iOS and OSX safari. Even traditional > sorrow spots like Android Tablets are showing promising signs to recovery. > Inside that progress however the picture is more mixed, windows in > particular has a problem across all browser vendors. > > On Windows the situation presents itself as follows: > > - Chrome: A high of 97.1% established in December 2013 has not been > surpassed since (currently 92.8%). In particular a local peak of 95.3% in > August 2014 (just before a bogus blacklist entry got inadvertently > released) has also not been surpassed since. The post recovery curve is now > flat since November 2014. > - Firefox: A high of 83% established 2014 has not been surpassed since > (currently 81.1%). After a rapid dip in september/october/november 2014 it > has started to recover, but the curve is now flat again. > - Internet Explorer: After a quick start into high levels of WebGL > support during October 2013 at 0% to November 2014 at 79.4%, a high was > reached in 83.5% in January and has not been surpassed since. The curve for > activation has also flattened out since November 2014. > > I can only speculate as to the reasons of these developments, but I > suspect it would be a combination of these factors: > > - Internet Explorer is still struggling to expediently replace older > versions. Although that situation has improved, the peak to peak distance > of IE versions is: 7->8 = 28 months, 8->9 = 18 months, 9->10 = 10 months, > 10 -> 11 = 14 months, and so this does contribute to the flagging advance > in WebGL support by Internet Explorer. > - Driver/Hardware issues are preventing support from closing the > remaining gap as well. > > At current rates (which might not be indicative to future activation > rates), support on Windows for WebGL will not advance beyond 90% in a > meaningful way for a very long time. As is usual, the last mile is usually > the hardest, and so I'd *encourage everyone to look into ways to close > that last 10% gap.* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Feb 6 09:33:11 2015 From: din...@ (Dean Jackson) Date: Sat, 7 Feb 2015 04:33:11 +1100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: Message-ID: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> > On 6 Feb 2015, at 6:30 pm, Florian B?sch wrote: > > Feedback from Apple, Microsoft and Mozilla on these extensions is outstanding. Calls for feedback where made: I agree these extensions should be rejected. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Feb 6 10:59:22 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 6 Feb 2015 10:59:22 -0800 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: Wait, what? We currently expose these in Firefox, and don't presently have a plan to disable them. I strongly disagree with rejecting these at this time. On Fri, Feb 6, 2015 at 9:33 AM, Dean Jackson wrote: > > On 6 Feb 2015, at 6:30 pm, Florian B?sch wrote: > > Feedback from Apple, Microsoft and Mozilla on these extensions is > outstanding. Calls for feedback where made: > > > I agree these extensions should be rejected. > > Dean > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Feb 6 11:02:24 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 6 Feb 2015 11:02:24 -0800 Subject: [Public WebGL] Re: extensions status In-Reply-To: References: Message-ID: We expose both of these, where supported. We even expose WEBGL_color_buffer_float on ANGLE presently. We have not withdrawn our implementation, and I am curious how this idea came about. On Mon, Feb 2, 2015 at 5:27 PM, Kenneth Russell wrote: > On Fri, Jan 30, 2015 at 11:08 PM, Florian B?sch wrote: > > On Sat, Jan 31, 2015 at 12:10 AM, Kenneth Russell > wrote: > >> > >> No intent to implement these. I don't remember all of the issues we > >> ran into, but when we investigated adding support I recall multiple > >> issues in ANGLE that made us abandon the effort. > > > > Excellent, thank you. I propose to reject these extensions: > > https://github.com/KhronosGroup/WebGL/pull/846 > > > > They will not land in ANGLE (and so support would be > difficult/impossible in > > Chrome/Firefox) > > Google will not implement them > > Firefox has withdrawn their initial implementation (I interprete this as > > tacit approval of mozilla to reject these extensions) > > I'd like to hear Mozilla's explicit feedback on this before rejecting > these extensions. > > > > > Microsoft has not stated their position but is unlikely to follow where > > Chrome and Firefox do not go > > Apple has not stated their position, but is unlikely to follow where > Chrome > > and Firefox do not go (and they also use ANGLE) > > > > > >> > >> On the other hand we > >> will absolutely implement EXT_color_buffer_float for WebGL 2.0. > > > > That's understood. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Feb 6 11:25:41 2015 From: din...@ (Dean Jackson) Date: Sat, 07 Feb 2015 06:25:41 +1100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: <15C53FD9-AFEA-40C9-82B0-52CE2DC2DD8A@apple.com> > On 7 Feb 2015, at 5:59 am, Jeff Gilbert wrote: > > Wait, what? We currently expose these in Firefox, and don't presently have a plan to disable them. Did Florian make a mistake? "Mozilla has retracted their implementation of these extensions and as of January 2015, they where no longer available in Firefox." Dean > > I strongly disagree with rejecting these at this time. > > On Fri, Feb 6, 2015 at 9:33 AM, Dean Jackson > wrote: > >> On 6 Feb 2015, at 6:30 pm, Florian B?sch > wrote: >> >> Feedback from Apple, Microsoft and Mozilla on these extensions is outstanding. Calls for feedback where made: > > I agree these extensions should be rejected. > > Dean > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 11:26:39 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 20:26:39 +0100 Subject: [Public WebGL] Re: extensions status In-Reply-To: References: Message-ID: On Fri, Feb 6, 2015 at 8:02 PM, Jeff Gilbert wrote: > We expose both of these, where supported. We even expose > WEBGL_color_buffer_float on ANGLE presently. > > We have not withdrawn our implementation, and I am curious how this idea > came about. > If you consult http://webglstats.com/ you will see that starting May 2014 both WEBGL_color_buffer_float and EXT_color_buffer_half_float started to pick up support to a peak of 2.2% in August 2014 and then dropped off again to 0.3% in November 2014. Filtering out just for firefox the peak is 12% and then a dropoff to 2%. This kind of pattern isn't usually associated with an enabled extension that's being shipped. It's therefore logical to assume you've withdrawn your implementation. Going over the yesterdays data of 343'000 page views with webgl active, these are the counts of extensions I'm seeing: 9 GLI_frame_terminator 38 EXT_draw_buffers 66 MOZ_WEBGL_compressed_texture_pvrtc 95 WEBKIT_WEBGL_compressed_textures 119 WEBGL_EXT_lose_context 131 WEBGL_compressed_texture_pvrtc 237 MOZ_WEBGL_compressed_texture_atc 264 MOZ_EXT_texture_filter_anisotropic *1249 EXT_color_buffer_half_float* *2066 WEBGL_color_buffer_float* 2637 WEBKIT_lose_context 5569 WEBGL_compressed_texture_atc 6352 WEBKIT_WEBGL_compressed_texture_atc 15393 WEBGL_compressed_texture_etc1 16172 WEBKIT_WEBGL_compressed_texture_pvrtc 39581 MOZ_WEBGL_depth_texture 44609 MOZ_WEBGL_compressed_texture_s3tc 45359 MOZ_WEBGL_lose_context 137482 EXT_sRGB 140207 WEBGL_draw_buffers 210612 WEBKIT_WEBGL_compressed_texture_s3tc 219723 WEBKIT_WEBGL_depth_texture 227804 WEBGL_debug_shaders 231276 EXT_frag_depth 232536 WEBKIT_WEBGL_lose_context 237269 EXT_blend_minmax 242892 EXT_shader_texture_lod 252007 WEBKIT_EXT_texture_filter_anisotropic 261836 WEBGL_debug_renderer_info 278454 WEBGL_depth_texture 285853 WEBGL_compressed_texture_s3tc 289406 OES_texture_half_float_linear 292821 OES_texture_half_float 296296 OES_texture_float_linear 297705 EXT_texture_filter_anisotropic 298624 ANGLE_instanced_arrays 303222 OES_vertex_array_object 308638 WEBGL_lose_context 331996 OES_element_index_uint 333089 OES_texture_float 337132 OES_standard_derivatives The reasons for rejecting these extensions has been laid out in the other thread, please move the discussion on these specific extensions over there and register your objection if you'd like to object to a rejection. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 11:27:58 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 20:27:58 +0100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: On Fri, Feb 6, 2015 at 7:59 PM, Jeff Gilbert wrote: > Wait, what? We currently expose these in Firefox, and don't presently have > a plan to disable them. > > I strongly disagree with rejecting these at this time. > Your objection should address the problem that these extensions cannot be ratified. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Feb 6 11:35:13 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 6 Feb 2015 11:35:13 -0800 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: The WG should not categorically reject extensions which it is merely unwilling to ratify. If it's community approved, I fail to see why it needs to either be ratified or rejected. On Fri, Feb 6, 2015 at 11:27 AM, Florian B?sch wrote: > On Fri, Feb 6, 2015 at 7:59 PM, Jeff Gilbert wrote: > >> Wait, what? We currently expose these in Firefox, and don't presently >> have a plan to disable them. >> >> I strongly disagree with rejecting these at this time. >> > Your objection should address the problem that these extensions cannot be > ratified. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Feb 6 11:41:30 2015 From: din...@ (Dean Jackson) Date: Sat, 07 Feb 2015 06:41:30 +1100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: > On 7 Feb 2015, at 6:35 am, Jeff Gilbert wrote: > > The WG should not categorically reject extensions which it is merely unwilling to ratify. If it's community approved, I fail to see why it needs to either be ratified or rejected. Ignoring the specifics of these particular extensions, I think it is a bad idea to have extensions that only a subset of vendors implement. Actually, I think extensions are a bad idea in general, but at least ratification is a suggestion that all vendors should implement the feature. If we know in advance that a feature won't be implemented by everyone, as long as there are valid reasons, it shouldn't be on Khronos.org - it should be in the vendor's developer docs. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 11:41:44 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 20:41:44 +0100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert wrote: > The WG should not categorically reject extensions which it is merely > unwilling to ratify. If it's community approved, I fail to see why it needs > to either be ratified or rejected. > That's a debate for another thread on extension development policy. Assuming these two working facts: 1. Every extension should be ratified 2. These extensions cannot be ratified because implementations from other vendors will not emerge. Do you wish to add anything to this observation to justify the objection to the rejection other than "we already implemented it"? Circling back for a second to the community approved status of these extensions, they're community approved on a technicality because OES_texture_float references them, and if they would be in draft, that would make it awkward to support them. Technical difficulties in implementation where noted by Kenneth Russel long before they where moved to community approved, and it's my opinion that they shouldn't have been moved to community approved while technical difficulties aren't resolved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 11:47:24 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 20:47:24 +0100 Subject: [Public WebGL] extension development process Message-ID: I have introduced the rejected status to the extension registry, added wording explaining when an extension can be rejected and clarified the process of extension advancement. Below are the added wordings: Every extension should advance to Khronos ratified. If an extension cannot > advance through the extension process it can be rejected. Rejected extensions should never be implemented. An extension enters > rejected status because consensus on it could not be reached at the > proposal stage or technical difficulties arise during implementation at the > draft stage. A community approved extension can only be rejected in > extraordinary circumstances. A Khronos ratified extension cannot be > rejected. This is of course open for debate, but I find it a good idea. Can we form a consensus on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Feb 6 12:48:34 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 6 Feb 2015 12:48:34 -0800 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Fri, Feb 6, 2015 at 1:45 AM, Florian B?sch wrote: > On Fri, Feb 6, 2015 at 4:00 AM, Kenneth Russell wrote: >> >> >> The ES 3.0.4 specification defines the errors INVALID_OPERATION, should >> >> it >> >> be added? >> > >> > Anybody know the answer to that one? >> >> It looks like the other WebGL extensions defining compressed textures >> use INVALID_VALUE for this size check. I assume the conformance tests >> are already verifying this. I'm in favor of minimizing the churn of >> both the specs and tests in this area, so would suggest it be left as >> is. > > > INVALID_OPERATION is issued by compressedTexImage2D if: > > the format does not match the internal format > If additional restrictions specified by the compression format specification > apply and aren't satisfied > > INVALID_OPERATION is issued by compressedTexSubImage2D if: > > xoffset or yoffset are not zero > width and height don't match the dimension of the texture level (is relaxed > for specific formats which are easily modified) >> I'm not sure what portion of the spec you're referring to. Please feel >> free to submit pull requests containing any clarifications you suggest >> and they can be discussed there. Thanks. > > > INVALID_VALUE is issued in addition to dimension mismatch when: > > The encoding of the compressed texture doesn't match the format > specification I'm not understanding what you're proposing be changed here -- don't have time right now to go through these specs in detail. Please just submit pull requests for whatever you are proposing so we can be very precise about what's being discussed. Thanks. ----------------------------------------------------------- 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 rog...@ Fri Feb 6 12:52:57 2015 From: rog...@ (Roger Fong) Date: Fri, 6 Feb 2015 12:52:57 -0800 Subject: [Public WebGL] TexSubImage2D and error checking Message-ID: Hello again folks, I have a question about TexSubImage2D and more specifically about the implications of this test: https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/textures/tex-image-with-invalid-data.html For starters, there is a setup() function in this test, but stepping into the code, it never ever gets called. This seems like a problem, as the test still seems to expect that texSubImage2D calls should fail, not because there is no bound texture to write over, but because of invalid data issues. Does this imply that texSubImage2D should fail due to invalid data types even before checking for whether or not a texture is actually bound? Or is the test just faulty? Thanks! Roger -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Feb 6 12:59:53 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 6 Feb 2015 12:59:53 -0800 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: On Fri, Feb 6, 2015 at 11:41 AM, Florian B?sch wrote: > On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert wrote: >> >> The WG should not categorically reject extensions which it is merely >> unwilling to ratify. If it's community approved, I fail to see why it needs >> to either be ratified or rejected. > > That's a debate for another thread on extension development policy. Assuming > these two working facts: > > Every extension should be ratified > These extensions cannot be ratified because implementations from other > vendors will not emerge. > > Do you wish to add anything to this observation to justify the objection to > the rejection other than "we already implemented it"? > > Circling back for a second to the community approved status of these > extensions, they're community approved on a technicality because > OES_texture_float references them, and if they would be in draft, that would > make it awkward to support them. Technical difficulties in implementation > where noted by Kenneth Russel long before they where moved to community > approved, and it's my opinion that they shouldn't have been moved to > community approved while technical difficulties aren't resolved. I don't want to fuel a long debate on this topic but since Mozilla pressed to move these extensions out of draft because they felt they were implementable, I prefer to leave them indeterminately in the community approved state. ----------------------------------------------------------- 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 Feb 6 13:00:22 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 6 Feb 2015 13:00:22 -0800 Subject: [Public WebGL] extension development process In-Reply-To: References: Message-ID: On Fri, Feb 6, 2015 at 11:47 AM, Florian B?sch wrote: > I have introduced the rejected status to the extension registry, added > wording explaining when an extension can be rejected and clarified the > process of extension advancement. Below are the added wordings: > >> Every extension should advance to Khronos ratified. If an extension cannot >> advance through the extension process it can be rejected. > > >> Rejected extensions should never be implemented. An extension enters >> rejected status because consensus on it could not be reached at the proposal >> stage or technical difficulties arise during implementation at the draft >> stage. A community approved extension can only be rejected in extraordinary >> circumstances. A Khronos ratified extension cannot be rejected. > > > This is of course open for debate, but I find it a good idea. Can we form a > consensus on this? This sounds fine. ----------------------------------------------------------- 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...@ Fri Feb 6 13:12:48 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 22:12:48 +0100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: Like I say that's another thread if it's ok to have perpetual community approved extensions only implemented by a single vendor. I will note though that even the one vendor who does "implement" it, only exposes it to 2% of its install base. I'm definitely not happy with a single vendor low single digit extension eating up space in the registry providing the illusion of a functionality being "addressed", when in fact, it isn't. On Fri, Feb 6, 2015 at 9:59 PM, Kenneth Russell wrote: > On Fri, Feb 6, 2015 at 11:41 AM, Florian B?sch wrote: > > On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert > wrote: > >> > >> The WG should not categorically reject extensions which it is merely > >> unwilling to ratify. If it's community approved, I fail to see why it > needs > >> to either be ratified or rejected. > > > > That's a debate for another thread on extension development policy. > Assuming > > these two working facts: > > > > Every extension should be ratified > > These extensions cannot be ratified because implementations from other > > vendors will not emerge. > > > > Do you wish to add anything to this observation to justify the objection > to > > the rejection other than "we already implemented it"? > > > > Circling back for a second to the community approved status of these > > extensions, they're community approved on a technicality because > > OES_texture_float references them, and if they would be in draft, that > would > > make it awkward to support them. Technical difficulties in implementation > > where noted by Kenneth Russel long before they where moved to community > > approved, and it's my opinion that they shouldn't have been moved to > > community approved while technical difficulties aren't resolved. > > I don't want to fuel a long debate on this topic but since Mozilla > pressed to move these extensions out of draft because they felt they > were implementable, I prefer to leave them indeterminately in the > community approved state. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 13:32:40 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 6 Feb 2015 22:32:40 +0100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: Look at it like this: These extensions will never solve the problem they're designed to solve. They will not solve it because they're largely unimplementable (as is evidenced by the refusal of at least one vendor to implement them on technical grounds, and by the low activation rate of another vendor). These extensions should not have moved beyond the proposal and draft stages because clearly consensus on them was not reached, and technical issues where not addressed. But because they're now in community approved status, they cannot be reworked to make them adequate tools to solve the problem. And because they're in the registry, no other extension can be introduced that would actually address the same problem. I'm very unhappy about limbo extensions like this. I think they're bad form, and they're bad for WebGL as a whole. On Fri, Feb 6, 2015 at 10:12 PM, Florian B?sch wrote: > Like I say that's another thread if it's ok to have perpetual community > approved extensions only implemented by a single vendor. > > I will note though that even the one vendor who does "implement" it, only > exposes it to 2% of its install base. I'm definitely not happy with a > single vendor low single digit extension eating up space in the registry > providing the illusion of a functionality being "addressed", when in fact, > it isn't. > > On Fri, Feb 6, 2015 at 9:59 PM, Kenneth Russell wrote: > >> On Fri, Feb 6, 2015 at 11:41 AM, Florian B?sch wrote: >> > On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert >> wrote: >> >> >> >> The WG should not categorically reject extensions which it is merely >> >> unwilling to ratify. If it's community approved, I fail to see why it >> needs >> >> to either be ratified or rejected. >> > >> > That's a debate for another thread on extension development policy. >> Assuming >> > these two working facts: >> > >> > Every extension should be ratified >> > These extensions cannot be ratified because implementations from other >> > vendors will not emerge. >> > >> > Do you wish to add anything to this observation to justify the >> objection to >> > the rejection other than "we already implemented it"? >> > >> > Circling back for a second to the community approved status of these >> > extensions, they're community approved on a technicality because >> > OES_texture_float references them, and if they would be in draft, that >> would >> > make it awkward to support them. Technical difficulties in >> implementation >> > where noted by Kenneth Russel long before they where moved to community >> > approved, and it's my opinion that they shouldn't have been moved to >> > community approved while technical difficulties aren't resolved. >> >> I don't want to fuel a long debate on this topic but since Mozilla >> pressed to move these extensions out of draft because they felt they >> were implementable, I prefer to leave them indeterminately in the >> community approved state. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Feb 6 14:15:56 2015 From: din...@ (Dean Jackson) Date: Sat, 07 Feb 2015 09:15:56 +1100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> Message-ID: <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> > On 7 Feb 2015, at 8:32 am, Florian B?sch wrote: > > Look at it like this: > > These extensions will never solve the problem they're designed to solve. They will not solve it because they're largely unimplementable (as is evidenced by the refusal of at least one vendor to implement them on technical grounds, and by the low activation rate of another vendor). These extensions should not have moved beyond the proposal and draft stages because clearly consensus on them was not reached, and technical issues where not addressed. But because they're now in community approved status, they cannot be reworked to make them adequate tools to solve the problem. And because they're in the registry, no other extension can be introduced that would actually address the same problem. > > I'm very unhappy about limbo extensions like this. I think they're bad form, and they're bad for WebGL as a whole. I don't feel as strongly as Florian, but if Mozilla is the only implementor that plans to support them, then I don't see how these could be considered community approved. Mozilla can continue to support them proprietarily. Dean > > On Fri, Feb 6, 2015 at 10:12 PM, Florian B?sch > wrote: > Like I say that's another thread if it's ok to have perpetual community approved extensions only implemented by a single vendor. > > I will note though that even the one vendor who does "implement" it, only exposes it to 2% of its install base. I'm definitely not happy with a single vendor low single digit extension eating up space in the registry providing the illusion of a functionality being "addressed", when in fact, it isn't. > > On Fri, Feb 6, 2015 at 9:59 PM, Kenneth Russell > wrote: > On Fri, Feb 6, 2015 at 11:41 AM, Florian B?sch > wrote: > > On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert > wrote: > >> > >> The WG should not categorically reject extensions which it is merely > >> unwilling to ratify. If it's community approved, I fail to see why it needs > >> to either be ratified or rejected. > > > > That's a debate for another thread on extension development policy. Assuming > > these two working facts: > > > > Every extension should be ratified > > These extensions cannot be ratified because implementations from other > > vendors will not emerge. > > > > Do you wish to add anything to this observation to justify the objection to > > the rejection other than "we already implemented it"? > > > > Circling back for a second to the community approved status of these > > extensions, they're community approved on a technicality because > > OES_texture_float references them, and if they would be in draft, that would > > make it awkward to support them. Technical difficulties in implementation > > where noted by Kenneth Russel long before they where moved to community > > approved, and it's my opinion that they shouldn't have been moved to > > community approved while technical difficulties aren't resolved. > > I don't want to fuel a long debate on this topic but since Mozilla > pressed to move these extensions out of draft because they felt they > were implementable, I prefer to leave them indeterminately in the > community approved state. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Feb 6 15:41:35 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 6 Feb 2015 15:41:35 -0800 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> Message-ID: It's important to realize that it's only Mozilla who explicitly exposes the extension. At least Chrome (and I believe others) implicitly support the extension, otherwise they cannot support rendering into floating-point FBs. This is the text from OES_texture_float: "Implementations supporting float rendering via this extension will implicitly enable the WEBGL_color_buffer_float extension and follow its requirements." Technically speaking, a spec-compliant implementation cannot expose OES_texture_float, allow render-to-RGBA32F, and not support the WEBGL_color_buffer_float extension. That is, Chrome (for instance) already implicitly claims support for all the restrictions of WEBGL_color_buffer_float if they support OES_texture_float and allow render-to-RGBA32F. As the spec stands today, Chrome is either out-of-spec in its implicit support of WEBGL_color_buffer_float as invoked by OES_texture_float, or WEBGL_color_buffer_float can be exposed today with no technical issues. To be clear, as the specs stand today, WebGL implementations may either: * Allow render-to-float32 when WEBGL_color_buffer_float is explicitly activated * Allow render-to-float32 when WEBGL_color_buffer_float is implicitly activated by OES_texture_float * Not allow render-to-float32. That is spec-as-written today. WEBGL_color_buffer_float is alive and well, but many implementations are not explicitly claiming support for it. If we reject these extensions, by spec, we'll need to stop allowing render-to-float, or get new extensions. I posit that we don't actually need new extensions, unless there's a technical reason that puts us all out-of-spec in our support for WEBGL_color_buffer_float, whether explicit or implicit. If there is a technical reason for this, we should rewrite the extension(s) until it's technically and spec-wise feasible to support render-to-float. On Fri, Feb 6, 2015 at 2:15 PM, Dean Jackson wrote: > > On 7 Feb 2015, at 8:32 am, Florian B?sch wrote: > > Look at it like this: > > These extensions will never solve the problem they're designed to solve. > They will not solve it because they're largely unimplementable (as is > evidenced by the refusal of at least one vendor to implement them on > technical grounds, and by the low activation rate of another vendor). These > extensions should not have moved beyond the proposal and draft stages > because clearly consensus on them was not reached, and technical issues > where not addressed. But because they're now in community approved status, > they cannot be reworked to make them adequate tools to solve the problem. > And because they're in the registry, no other extension can be introduced > that would actually address the same problem. > > I'm very unhappy about limbo extensions like this. I think they're bad > form, and they're bad for WebGL as a whole. > > > I don't feel as strongly as Florian, but if Mozilla is the only > implementor that plans to support them, then I don't see how these could be > considered community approved. Mozilla can continue to support them > proprietarily. > > Dean > > > On Fri, Feb 6, 2015 at 10:12 PM, Florian B?sch wrote: > >> Like I say that's another thread if it's ok to have perpetual community >> approved extensions only implemented by a single vendor. >> >> I will note though that even the one vendor who does "implement" it, only >> exposes it to 2% of its install base. I'm definitely not happy with a >> single vendor low single digit extension eating up space in the registry >> providing the illusion of a functionality being "addressed", when in fact, >> it isn't. >> >> On Fri, Feb 6, 2015 at 9:59 PM, Kenneth Russell wrote: >> >>> On Fri, Feb 6, 2015 at 11:41 AM, Florian B?sch wrote: >>> > On Fri, Feb 6, 2015 at 8:35 PM, Jeff Gilbert >>> wrote: >>> >> >>> >> The WG should not categorically reject extensions which it is merely >>> >> unwilling to ratify. If it's community approved, I fail to see why it >>> needs >>> >> to either be ratified or rejected. >>> > >>> > That's a debate for another thread on extension development policy. >>> Assuming >>> > these two working facts: >>> > >>> > Every extension should be ratified >>> > These extensions cannot be ratified because implementations from other >>> > vendors will not emerge. >>> > >>> > Do you wish to add anything to this observation to justify the >>> objection to >>> > the rejection other than "we already implemented it"? >>> > >>> > Circling back for a second to the community approved status of these >>> > extensions, they're community approved on a technicality because >>> > OES_texture_float references them, and if they would be in draft, that >>> would >>> > make it awkward to support them. Technical difficulties in >>> implementation >>> > where noted by Kenneth Russel long before they where moved to community >>> > approved, and it's my opinion that they shouldn't have been moved to >>> > community approved while technical difficulties aren't resolved. >>> >>> I don't want to fuel a long debate on this topic but since Mozilla >>> pressed to move these extensions out of draft because they felt they >>> were implementable, I prefer to leave them indeterminately in the >>> community approved state. >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Feb 6 17:03:01 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 6 Feb 2015 17:03:01 -0800 Subject: [Public WebGL] extension development process In-Reply-To: References: Message-ID: Sounds good to me, as long as we're all in agreement that "If an extension cannot advance through the extension process it can be rejected." uses "can" and not "will". On Fri, Feb 6, 2015 at 1:00 PM, Kenneth Russell wrote: > > On Fri, Feb 6, 2015 at 11:47 AM, Florian B?sch wrote: > > I have introduced the rejected status to the extension registry, added > > wording explaining when an extension can be rejected and clarified the > > process of extension advancement. Below are the added wordings: > > > >> Every extension should advance to Khronos ratified. If an extension > cannot > >> advance through the extension process it can be rejected. > > > > > >> Rejected extensions should never be implemented. An extension enters > >> rejected status because consensus on it could not be reached at the > proposal > >> stage or technical difficulties arise during implementation at the draft > >> stage. A community approved extension can only be rejected in > extraordinary > >> circumstances. A Khronos ratified extension cannot be rejected. > > > > > > This is of course open for debate, but I find it a good idea. Can we > form a > > consensus on this? > > This sounds fine. > > ----------------------------------------------------------- > 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...@ Fri Feb 6 17:50:16 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 6 Feb 2015 17:50:16 -0800 Subject: [Public WebGL] TexSubImage2D and error checking In-Reply-To: References: Message-ID: Roger, thanks very much for pointing out this issue. The test is definitely buggy. The tests which check that an INVALID_OPERATION error is generated are passing by luck. They are supposed to pass because of argument validation, but instead they're passing because no texture is bound, which also generates an INVALID_OPERATION error. The tests aren't supposed to verify the behavior if two errors might be generated, only one. This is an embarrassingly longstanding bug. I've just merged a pull request which fixes this in the top-of-tree https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/tex-image-with-invalid-data.html . Can you confirm that this test works on your implementation now? If so, we can merge this fix back to the earlier conformance suites. Note that the exception-throwing tests should probably be working on all implementations. The type conversions are conceptually supposed to be done during the call, before the implementation of texImage2D or texSubImage2D is reached. In fact, some of those tests should probably be run both with a texture bound and without. -Ken On Fri, Feb 6, 2015 at 12:52 PM, Roger Fong wrote: > Hello again folks, > > I have a question about TexSubImage2D and more specifically about the > implications of this test: > https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/textures/tex-image-with-invalid-data.html > > For starters, there is a setup() function in this test, but stepping into > the code, it never ever gets called. > This seems like a problem, as the test still seems to expect that > texSubImage2D calls should fail, not because there is no bound texture to > write over, but because of invalid data issues. > > Does this imply that texSubImage2D should fail due to invalid data types > even before checking for whether or not a texture is actually bound? Or is > the test just faulty? > > Thanks! > Roger ----------------------------------------------------------- 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 khr...@ Fri Feb 6 20:49:52 2015 From: khr...@ (Mark Callow) Date: Fri, 6 Feb 2015 20:49:52 -0800 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> Message-ID: <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> > On Feb 6, 2015, at 3:41 PM, Jeff Gilbert wrote: > ... > > Technically speaking, a spec-compliant implementation cannot expose OES_texture_float, allow render-to-RGBA32F, and not support the WEBGL_color_buffer_float extension. That is, Chrome (for instance) already implicitly claims support for all the restrictions of WEBGL_color_buffer_float if they support OES_texture_float and allow render-to-RGBA32F. > > As the spec stands today, Chrome is either out-of-spec in its implicit support of WEBGL_color_buffer_float as invoked by OES_texture_float, or WEBGL_color_buffer_float can be exposed today with no technical issues. > > To be clear, as the specs stand today, WebGL implementations may either: > * Allow render-to-float32 when WEBGL_color_buffer_float is explicitly activated > * Allow render-to-float32 when WEBGL_color_buffer_float is implicitly activated by OES_texture_float > * Not allow render-to-float32. > > That is spec-as-written today. This is absolutely true. If implementations of OES_texture_float that implicitly allow float rendering were not following what is written in WEBGL_color_buffer_float they would be clamping fragment shader outputs and clear colors. Relaxing these clamps for float buffers and explicitly stating that rendering to RGBA32F is allowed are the only things that the extension does. The extension is not supportable on mobile because no OpenGL ES 2 GPU supports 32-bit float rendering. But we have examples of other extensions with limited to no support on mobile. It is implementable by and has essentially been implemented by all desktop browsers. As for ratification, ratification is primarily about IP cross licensing and IP protection. On the native side there are extensions such as EXT_color_buffer_float that Khronos cannot ratify because the members don?t own the necessary IP. However almost all IHVs will support this extension, having licensed the necessary IP from its owner. The WebGL extension that wraps EXT_color_buffer_float doesn?t really contain any IP, so it may be possible for Khronos to ratify that. It is unclear. What is clear is that failure to ratify is insufficient reason to reject an extension. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Fri Feb 6 21:36:57 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Feb 2015 06:36:57 +0100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> Message-ID: Please move extension development policy debate into the extension development process thread. WEBGL_color_buffer_float and EXT_color_buffer_half_float are a problem. - One vendor objects to them on technical grounds (Google, Kenneth could you please elaborate what the issue is?) - Another vendor (Mozilla) who says they implement these extensions, doesn't actually implement them (mostly). Jeff, could you please explain how it comes about that these extensions are only available on 2% of your install base, and that support for them took a nosedive after November 2014? - These extensions cannot be ratified, which is a stated reason that they can be rejected in the extension development process guidelines. If you object to this reason, please move your objection over to the extension development process. - These extensions cannot be modified to make suitable for other vendors, because they're in community approved status. So it's pretty clear to me, and hopefully anybody else, that "community approved" is not what these extensions are, anything but, actually. Therefore there is only 4 unpalatable choices open: - Reject these extensions (as proposed) - Move them back to draft - Leave them hanging in limbo (also proposed as a resolution to rejection) The opposition has made it impossible to reject these extensions, and the status of these extensions has made it impossible to have them do anything useful or be ratified. The only course of action left is: 1. Move them back to draft 2. Take in input from vendors with technical objections and rework them until that's solved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 22:03:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Feb 2015 07:03:21 +0100 Subject: [Public WebGL] draft WEBGL_color_buffer_float and EXT_color_buffer_half_float Message-ID: Objections to the rejection of these extensions by Mozilla make it impossible to reject them: https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00021.html Objections to the technical definitions of these extensions by Google make it impossible to ratify the extensions or have comprehensive multi-vendor coverage of them: https://www.khronos.org/webgl/public-mailing-list/archives/1407/msg00051.html https://www.khronos.org/webgl/public-mailing-list/archives/1501/msg00136.html Additionally the vendor that claims to implement them (Mozilla), only has them activated on 2% of their install base. This is after a precipitous dropoff from 12% earlier for that vendor. It seems likely that even the championing vendor (Mozilla) has technical difficulties with these extensions. It is therefore reasonable to move these extensions back to draft so they can be worked over until such a time that they can stand up to multi-vendor consensus. A suitable pull request has been created: https://github.com/KhronosGroup/WebGL/pull/855 Please register your objections to fixing these extensions here now. Please be aware that if you simultaneously object to rejection and object to fixing the extensions, that this will make it very difficult for other vendors and the WebGL community as a whole, and it will prompt a debate on *much stricter* requirements on community approval. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 22:13:17 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Feb 2015 07:13:17 +0100 Subject: [Public WebGL] Re: extension development process In-Reply-To: References: Message-ID: Frank and Dean, could we get it on the record here that you're in agreement of this wording? On Fri, Feb 6, 2015 at 8:47 PM, Florian B?sch wrote: > I have introduced the rejected status to the extension registry, added > wording explaining when an extension can be rejected and clarified the > process of extension advancement. Below are the added wordings: > > Every extension should advance to Khronos ratified. If an extension cannot >> advance through the extension process it can be rejected. > > > Rejected extensions should never be implemented. An extension enters >> rejected status because consensus on it could not be reached at the >> proposal stage or technical difficulties arise during implementation at the >> draft stage. A community approved extension can only be rejected in >> extraordinary circumstances. A Khronos ratified extension cannot be >> rejected. > > > This is of course open for debate, but I find it a good idea. Can we form > a consensus on this? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 6 23:29:40 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Feb 2015 08:29:40 +0100 Subject: [Public WebGL] Re: rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> Message-ID: I believe it's established that consensus on rejection cannot be reached. Therefore I've started the alterntive proposal of moving these extensions back to draft: https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html The proposal to rejection is suspended until the alternate proposal is resolved. A failure to find a satisfactory resolution to these extensions will circle back to this rejection proposal. On Sat, Feb 7, 2015 at 6:36 AM, Florian B?sch wrote: > Please move extension development policy debate into the extension > development process thread. > > WEBGL_color_buffer_float and EXT_color_buffer_half_float are a problem. > > - One vendor objects to them on technical grounds (Google, Kenneth > could you please elaborate what the issue is?) > - Another vendor (Mozilla) who says they implement these extensions, > doesn't actually implement them (mostly). Jeff, could you please explain > how it comes about that these extensions are only available on 2% of your > install base, and that support for them took a nosedive after November 2014? > - These extensions cannot be ratified, which is a stated reason that > they can be rejected in the extension development process guidelines. If > you object to this reason, please move your objection over to the extension > development process. > - These extensions cannot be modified to make suitable for other > vendors, because they're in community approved status. > > So it's pretty clear to me, and hopefully anybody else, that "community > approved" is not what these extensions are, anything but, actually. > Therefore there is only 4 unpalatable choices open: > > - Reject these extensions (as proposed) > - Move them back to draft > - Leave them hanging in limbo (also proposed as a resolution to > rejection) > > The opposition has made it impossible to reject these extensions, and the > status of these extensions has made it impossible to have them do anything > useful or be ratified. The only course of action left is: > > 1. Move them back to draft > 2. Take in input from vendors with technical objections and rework > them until that's solved. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Sat Feb 7 03:15:19 2015 From: din...@ (Dean Jackson) Date: Sat, 07 Feb 2015 22:15:19 +1100 Subject: [Public WebGL] Re: extension development process In-Reply-To: References: Message-ID: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> > On 7 Feb 2015, at 5:13 pm, Florian B?sch wrote: > > Frank and Dean, could we get it on the record here that you're in agreement of this wording? Agreed. Dean > > On Fri, Feb 6, 2015 at 8:47 PM, Florian B?sch > wrote: > I have introduced the rejected status to the extension registry, added wording explaining when an extension can be rejected and clarified the process of extension advancement. Below are the added wordings: > > Every extension should advance to Khronos ratified. If an extension cannot advance through the extension process it can be rejected. > > Rejected extensions should never be implemented. An extension enters rejected status because consensus on it could not be reached at the proposal stage or technical difficulties arise during implementation at the draft stage. A community approved extension can only be rejected in extraordinary circumstances. A Khronos ratified extension cannot be rejected. > > This is of course open for debate, but I find it a good idea. Can we form a consensus on this? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Feb 7 10:58:47 2015 From: khr...@ (Mark Callow) Date: Sat, 7 Feb 2015 10:58:47 -0800 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> Message-ID: <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> > On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: > > I believe it's established that consensus on rejection cannot be reached. Therefore I've started the alterntive proposal of moving these extensions back to draft: https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html > > The proposal to rejection is suspended until the alternate proposal is resolved. A failure to find a satisfactory resolution to these extensions will circle back to this rejection proposal. > These extensions are referenced by the ratified extensions OES_texture_float and OES_texture_half_float. *Any* implementation supporting rendering to float or half_float via these extensions (including Chrome) is implicitly enabling WEBGL_color_buffer_float or EXT_color_buffer_half_float respectively. For the sake of argument let?s say we could change the ratified extensions and remove the references to the extensions you are so hot to reject. Then according to the remaining specifications, implementations should clamp clear colors and fragment shader outputs, making floating-point color buffers virtually useless. Nobody wants to go back to that situation. So these extensions cannot be rejected or returned to draft. If there truly are technical issues then Ken will have to detail them. I would far rather he concentrate on WebGL 2 than spend time digging into Chrome development history. Since these extensions are based on an existing native extension and are clearly implementable on desktop OpenGL and D3D, I suspect the issues are more to do with them not wanting to spend time making an officlal ANGLE extension equivalent to WEBGL_color_buffer_float rather than anything truly technical. Clearly they have a way to enable the functionality as they are currently doing so implicitly. > These extensions cannot be ratified, I didn?t say that. Did somebody else? I said the possibility was unclear. We can only truly find out by submitting them to the Khronos promoters. > which is a stated reason that they can be rejected in the extension development process guidelines. If you object to this reason, please move your objection over to the extension development process. The key word here is ?can?. Your revision to the guidelines does not say ?will?. If it did, I would have objected as would Jeff. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sat Feb 7 11:12:30 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Feb 2015 20:12:30 +0100 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: These extensions are not ready, neither for community approval, nor for ratification. They cannot be ready, because one vendor, whom we've polled now to render his technical objection has stated that he has objections. Another vendor who purports to champion these extensions, is also not implementing them, for reasons unknown (but also polled). That a ratified extension refers to these extensions does not provide more credence to them being community ratified, it only serves to compounds the magnitude of error committed. A situation where extensions are promoted to "community ratified" based on a technicality, resulting in a registry containing extensions vendors are unwilling to implement is not tenable. This constitutes an extraordinary situation. I'm not eager to reject these extensions. I'm in fact in full recognition of the need for these extensions. But by shoddily pushing them along as has happened, without consensus at any stage, doesn't only harm WebGL and renders the registry a bad joke, it actively prevents these extensions from performing the job they're designed to perform. That is what I'm extremely eager to prevent. And that is why I'm pushing, quite hard, to get this rectified before it becomes a bad example to follow. On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow wrote: > > On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: > > I believe it's established that consensus on rejection cannot be reached. > Therefore I've started the alterntive proposal of moving these extensions > back to draft: > https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html > > The proposal to rejection is suspended until the alternate proposal is > resolved. A failure to find a satisfactory resolution to these extensions > will circle back to this rejection proposal. > > > These extensions are referenced by the ratified extensions > OES_texture_float and OES_texture_half_float. *Any* implementation > supporting rendering to float or half_float via these extensions > (including Chrome) is implicitly enabling WEBGL_color_buffer_float or > EXT_color_buffer_half_float respectively. > > For the sake of argument let?s say we could change the ratified extensions > and remove the references to the extensions you are so hot to reject. Then > according to the remaining specifications, implementations should clamp > clear colors and fragment shader outputs, making floating-point color > buffers virtually useless. Nobody wants to go back to that situation. So > these extensions cannot be rejected or returned to draft. > > If there truly are technical issues then Ken will have to detail them. I > would far rather he concentrate on WebGL 2 than spend time digging into > Chrome development history. Since these extensions are based on an > existing native extension and are clearly implementable on desktop OpenGL > and D3D, I suspect the issues are more to do with them not wanting to spend > time making an officlal ANGLE extension equivalent to > WEBGL_color_buffer_float rather than anything truly technical. Clearly they > have a way to enable the functionality as they are currently doing so > implicitly. > > > - These extensions cannot be ratified, > > I didn?t say that. Did somebody else? I said the possibility was unclear. > We can only truly find out by submitting them to the Khronos promoters. > > > - which is a stated reason that they can be rejected in the extension > development process guidelines. If you object to this reason, please move > your objection over to the extension development process. > > The key word here is ?can?. Your revision to the guidelines does not say > ?will?. If it did, I would have objected as would Jeff. > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Feb 7 11:23:22 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Feb 2015 20:23:22 +0100 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: I want these extensions to be implemented, badly. In order to be implemented, they have to be *implementable*. If they're not implementable, they have no business having made it to community approved. If they cannot be fixed, they're useless. If they're useless, they have no business being in the active registry. Hence, both my proposal to reject them, and my proposal to move them back to draft. It's not too late to correct a mistake. Obstruction to clearing these extensions up one way or another serves no purpose other than compounding that mistake. On Sat, Feb 7, 2015 at 8:12 PM, Florian B?sch wrote: > These extensions are not ready, neither for community approval, nor for > ratification. They cannot be ready, because one vendor, whom we've polled > now to render his technical objection has stated that he has objections. > Another vendor who purports to champion these extensions, is also not > implementing them, for reasons unknown (but also polled). > > That a ratified extension refers to these extensions does not provide more > credence to them being community ratified, it only serves to compounds the > magnitude of error committed. > > A situation where extensions are promoted to "community ratified" based on > a technicality, resulting in a registry containing extensions vendors are > unwilling to implement is not tenable. This constitutes an extraordinary > situation. > > I'm not eager to reject these extensions. I'm in fact in full recognition > of the need for these extensions. But by shoddily pushing them along as has > happened, without consensus at any stage, doesn't only harm WebGL and > renders the registry a bad joke, it actively prevents these extensions from > performing the job they're designed to perform. That is what I'm extremely > eager to prevent. And that is why I'm pushing, quite hard, to get this > rectified before it becomes a bad example to follow. > > On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow wrote: > >> >> On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: >> >> I believe it's established that consensus on rejection cannot be reached. >> Therefore I've started the alterntive proposal of moving these extensions >> back to draft: >> https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html >> >> The proposal to rejection is suspended until the alternate proposal is >> resolved. A failure to find a satisfactory resolution to these extensions >> will circle back to this rejection proposal. >> >> >> These extensions are referenced by the ratified extensions >> OES_texture_float and OES_texture_half_float. *Any* implementation >> supporting rendering to float or half_float via these extensions >> (including Chrome) is implicitly enabling WEBGL_color_buffer_float or >> EXT_color_buffer_half_float respectively. >> >> For the sake of argument let?s say we could change the ratified >> extensions and remove the references to the extensions you are so hot to >> reject. Then according to the remaining specifications, implementations >> should clamp clear colors and fragment shader outputs, making >> floating-point color buffers virtually useless. Nobody wants to go back to >> that situation. So these extensions cannot be rejected or returned to draft. >> >> If there truly are technical issues then Ken will have to detail them. I >> would far rather he concentrate on WebGL 2 than spend time digging into >> Chrome development history. Since these extensions are based on an >> existing native extension and are clearly implementable on desktop OpenGL >> and D3D, I suspect the issues are more to do with them not wanting to spend >> time making an officlal ANGLE extension equivalent to >> WEBGL_color_buffer_float rather than anything truly technical. Clearly they >> have a way to enable the functionality as they are currently doing so >> implicitly. >> >> >> - These extensions cannot be ratified, >> >> I didn?t say that. Did somebody else? I said the possibility was unclear. >> We can only truly find out by submitting them to the Khronos promoters. >> >> >> - which is a stated reason that they can be rejected in the extension >> development process guidelines. If you object to this reason, please move >> your objection over to the extension development process. >> >> The key word here is ?can?. Your revision to the guidelines does not say >> ?will?. If it did, I would have objected as would Jeff. >> >> Regards >> >> -Mark >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rog...@ Sat Feb 7 15:19:25 2015 From: rog...@ (Roger Fong) Date: Sat, 7 Feb 2015 15:19:25 -0800 Subject: [Public WebGL] TexSubImage2D and error checking In-Reply-To: References: Message-ID: Yup, test indeed passes on our implementation! Thanks! Roger On Fri, Feb 6, 2015 at 5:50 PM, Kenneth Russell wrote: > Roger, thanks very much for pointing out this issue. > > The test is definitely buggy. The tests which check that an > INVALID_OPERATION error is generated are passing by luck. They are > supposed to pass because of argument validation, but instead they're > passing because no texture is bound, which also generates an > INVALID_OPERATION error. The tests aren't supposed to verify the > behavior if two errors might be generated, only one. This is an > embarrassingly longstanding bug. > > I've just merged a pull request which fixes this in the top-of-tree > > https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/tex-image-with-invalid-data.html > . Can you confirm that this test works on your implementation now? If > so, we can merge this fix back to the earlier conformance suites. > > Note that the exception-throwing tests should probably be working on > all implementations. The type conversions are conceptually supposed to > be done during the call, before the implementation of texImage2D or > texSubImage2D is reached. In fact, some of those tests should probably > be run both with a texture bound and without. > > -Ken > > > > On Fri, Feb 6, 2015 at 12:52 PM, Roger Fong > wrote: > > Hello again folks, > > > > I have a question about TexSubImage2D and more specifically about the > > implications of this test: > > > https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/textures/tex-image-with-invalid-data.html > > > > For starters, there is a setup() function in this test, but stepping into > > the code, it never ever gets called. > > This seems like a problem, as the test still seems to expect that > > texSubImage2D calls should fail, not because there is no bound texture to > > write over, but because of invalid data issues. > > > > Does this imply that texSubImage2D should fail due to invalid data types > > even before checking for whether or not a texture is actually bound? Or > is > > the test just faulty? > > > > Thanks! > > Roger > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Feb 9 12:59:32 2015 From: jgi...@ (Jeff Gilbert) Date: Mon, 9 Feb 2015 12:59:32 -0800 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: Here's the deal with the Firefox numbers: Currently, Release is 35, Beta is 36, and Nightly is 38.[1] In Firefox 33, we landed a fix[2] which moves the color_buffer extensions behind a draft extensions pref, because they were still in Draft status at the time. 33 became Beta on 2014-09-02, and then Release on 2014-10-14. Looking at the data for Firefox+OSX, you can see a large activation rate for WEBGL_color_buffer_float declines sharply in October and November 2014, in line with this fix hitting the Release channel. In Firefox 36, we landed a fix[3] which moves the color_buffer extensions out from behind Draft, as they were promoted to Community Approved. In addition, we landed another fix[4] which enables WEBGL_color_buffer_float support on ANGLE. (I am currently working on a patch to support EXT_color_buffer_half_float on ANGLE) This means that you will see near-zero activation for this extension on Windows before 36. 36 is on Beta right now, and it will move to Release on 2015-02-24. The data for Firefox+OSX+WEBGL_color_buffer_float appears to be showing a small uptick already, but it's likely within the noise floor. However, you can definitely see Firefox+Windows activation for WEBGL_color_buffer_float coming on line, though it's still sitting at 2%. If it's possible to isolate Firefox 36+ from your data, how does the activation rate look there? I'm going to do my own investigation on the correctness of our implementation in the mean time, to be sure we're exposing it properly. [1]: https://wiki.mozilla.org/RapidRelease/Calendar [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1023553 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1105535 [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1102667 On Sat, Feb 7, 2015 at 11:23 AM, Florian B?sch wrote: > I want these extensions to be implemented, badly. In order to be > implemented, they have to be *implementable*. If they're not > implementable, they have no business having made it to community approved. > If they cannot be fixed, they're useless. If they're useless, they have no > business being in the active registry. Hence, both my proposal to reject > them, and my proposal to move them back to draft. It's not too late to > correct a mistake. Obstruction to clearing these extensions up one way or > another serves no purpose other than compounding that mistake. > > On Sat, Feb 7, 2015 at 8:12 PM, Florian B?sch wrote: > >> These extensions are not ready, neither for community approval, nor for >> ratification. They cannot be ready, because one vendor, whom we've polled >> now to render his technical objection has stated that he has objections. >> Another vendor who purports to champion these extensions, is also not >> implementing them, for reasons unknown (but also polled). >> >> That a ratified extension refers to these extensions does not provide >> more credence to them being community ratified, it only serves to compounds >> the magnitude of error committed. >> >> A situation where extensions are promoted to "community ratified" based >> on a technicality, resulting in a registry containing extensions vendors >> are unwilling to implement is not tenable. This constitutes an >> extraordinary situation. >> >> I'm not eager to reject these extensions. I'm in fact in full recognition >> of the need for these extensions. But by shoddily pushing them along as has >> happened, without consensus at any stage, doesn't only harm WebGL and >> renders the registry a bad joke, it actively prevents these extensions from >> performing the job they're designed to perform. That is what I'm extremely >> eager to prevent. And that is why I'm pushing, quite hard, to get this >> rectified before it becomes a bad example to follow. >> >> On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow wrote: >> >>> >>> On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: >>> >>> I believe it's established that consensus on rejection cannot be >>> reached. Therefore I've started the alterntive proposal of moving these >>> extensions back to draft: >>> https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html >>> >>> The proposal to rejection is suspended until the alternate proposal is >>> resolved. A failure to find a satisfactory resolution to these extensions >>> will circle back to this rejection proposal. >>> >>> >>> These extensions are referenced by the ratified extensions >>> OES_texture_float and OES_texture_half_float. *Any* implementation >>> supporting rendering to float or half_float via these extensions >>> (including Chrome) is implicitly enabling WEBGL_color_buffer_float or >>> EXT_color_buffer_half_float respectively. >>> >>> For the sake of argument let?s say we could change the ratified >>> extensions and remove the references to the extensions you are so hot to >>> reject. Then according to the remaining specifications, implementations >>> should clamp clear colors and fragment shader outputs, making >>> floating-point color buffers virtually useless. Nobody wants to go back to >>> that situation. So these extensions cannot be rejected or returned to draft. >>> >>> If there truly are technical issues then Ken will have to detail them. I >>> would far rather he concentrate on WebGL 2 than spend time digging into >>> Chrome development history. Since these extensions are based on an >>> existing native extension and are clearly implementable on desktop OpenGL >>> and D3D, I suspect the issues are more to do with them not wanting to spend >>> time making an officlal ANGLE extension equivalent to >>> WEBGL_color_buffer_float rather than anything truly technical. Clearly they >>> have a way to enable the functionality as they are currently doing so >>> implicitly. >>> >>> >>> - These extensions cannot be ratified, >>> >>> I didn?t say that. Did somebody else? I said the possibility was >>> unclear. We can only truly find out by submitting them to the Khronos >>> promoters. >>> >>> >>> - which is a stated reason that they can be rejected in the >>> extension development process guidelines. If you object to this reason, >>> please move your objection over to the extension development process. >>> >>> The key word here is ?can?. Your revision to the guidelines does not say >>> ?will?. If it did, I would have objected as would Jeff. >>> >>> Regards >>> >>> -Mark >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fra...@ Mon Feb 9 17:47:57 2015 From: Fra...@ (Frank Olivier) Date: Tue, 10 Feb 2015 01:47:57 +0000 Subject: [Public WebGL] RE: extension development process In-Reply-To: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: "Rejected extensions should never be implemented. " I would advocate for slightly different wording, with the same intent: - Vendors should avoid implementing rejected extensions. - Vendors may implement experimental extensions to obtain technical feedback and to submit them to the ratification process. "An extension enters rejected status because consensus on it could not be reached at the proposal stage or technical difficulties arise during implementation at the draft stage. A community approved extension can only be rejected in extraordinary circumstances. A Khronos ratified extension cannot be rejected." Agree with this wording. Thanks Frank From: Dean Jackson [mailto:dino...@] Sent: Saturday, February 7, 2015 3:15 AM To: Florian B?sch Cc: public webgl; Frank Olivier Subject: Re: extension development process On 7 Feb 2015, at 5:13 pm, Florian B?sch > wrote: Frank and Dean, could we get it on the record here that you're in agreement of this wording? Agreed. Dean On Fri, Feb 6, 2015 at 8:47 PM, Florian B?sch > wrote: I have introduced the rejected status to the extension registry, added wording explaining when an extension can be rejected and clarified the process of extension advancement. Below are the added wordings: Every extension should advance to Khronos ratified. If an extension cannot advance through the extension process it can be rejected. Rejected extensions should never be implemented. An extension enters rejected status because consensus on it could not be reached at the proposal stage or technical difficulties arise during implementation at the draft stage. A community approved extension can only be rejected in extraordinary circumstances. A Khronos ratified extension cannot be rejected. This is of course open for debate, but I find it a good idea. Can we form a consensus on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Feb 9 20:01:17 2015 From: jgi...@ (Jeff Gilbert) Date: Mon, 9 Feb 2015 20:01:17 -0800 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: I did some testing, and is seems that WEBGL_color_buffer_float is implementable on ANGLE. (I haven't tested EXT_color_buffer_half_float, but it seems like it should correspondingly be workable) I didn't test all blending combinations, but basic clamped and unclamped tests work fine. The only change needed in (Firefox's old copy of) ANGLE is removing the call-time clamping on glBlendColor. Functionally, removing this seems to work fine, but Shannon (CC'd) would be a better person to answer whether this is spec-compliant D3D, or if I'm getting lucky with my driver. On Mon, Feb 9, 2015 at 12:59 PM, Jeff Gilbert wrote: > Here's the deal with the Firefox numbers: > > Currently, Release is 35, Beta is 36, and Nightly is 38.[1] > > In Firefox 33, we landed a fix[2] which moves the color_buffer extensions > behind a draft extensions pref, because they were still in Draft status at > the time. 33 became Beta on 2014-09-02, and then Release on 2014-10-14. > Looking at the data for Firefox+OSX, you can see a large activation rate > for WEBGL_color_buffer_float declines sharply in October and November 2014, > in line with this fix hitting the Release channel. > > In Firefox 36, we landed a fix[3] which moves the color_buffer extensions > out from behind Draft, as they were promoted to Community Approved. In > addition, we landed another fix[4] which enables WEBGL_color_buffer_float > support on ANGLE. (I am currently working on a patch to support > EXT_color_buffer_half_float on ANGLE) This means that you will see > near-zero activation for this extension on Windows before 36. 36 is on Beta > right now, and it will move to Release on 2015-02-24. The data for > Firefox+OSX+WEBGL_color_buffer_float appears to be showing a small uptick > already, but it's likely within the noise floor. However, you can > definitely see Firefox+Windows activation for WEBGL_color_buffer_float > coming on line, though it's still sitting at 2%. > > If it's possible to isolate Firefox 36+ from your data, how does the > activation rate look there? > > I'm going to do my own investigation on the correctness of our > implementation in the mean time, to be sure we're exposing it properly. > > [1]: https://wiki.mozilla.org/RapidRelease/Calendar > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1023553 > [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1105535 > [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1102667 > > On Sat, Feb 7, 2015 at 11:23 AM, Florian B?sch wrote: > >> I want these extensions to be implemented, badly. In order to be >> implemented, they have to be *implementable*. If they're not >> implementable, they have no business having made it to community approved. >> If they cannot be fixed, they're useless. If they're useless, they have no >> business being in the active registry. Hence, both my proposal to reject >> them, and my proposal to move them back to draft. It's not too late to >> correct a mistake. Obstruction to clearing these extensions up one way or >> another serves no purpose other than compounding that mistake. >> >> On Sat, Feb 7, 2015 at 8:12 PM, Florian B?sch wrote: >> >>> These extensions are not ready, neither for community approval, nor for >>> ratification. They cannot be ready, because one vendor, whom we've polled >>> now to render his technical objection has stated that he has objections. >>> Another vendor who purports to champion these extensions, is also not >>> implementing them, for reasons unknown (but also polled). >>> >>> That a ratified extension refers to these extensions does not provide >>> more credence to them being community ratified, it only serves to compounds >>> the magnitude of error committed. >>> >>> A situation where extensions are promoted to "community ratified" based >>> on a technicality, resulting in a registry containing extensions vendors >>> are unwilling to implement is not tenable. This constitutes an >>> extraordinary situation. >>> >>> I'm not eager to reject these extensions. I'm in fact in full >>> recognition of the need for these extensions. But by shoddily pushing them >>> along as has happened, without consensus at any stage, doesn't only harm >>> WebGL and renders the registry a bad joke, it actively prevents these >>> extensions from performing the job they're designed to perform. That is >>> what I'm extremely eager to prevent. And that is why I'm pushing, quite >>> hard, to get this rectified before it becomes a bad example to follow. >>> >>> On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow wrote: >>> >>>> >>>> On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: >>>> >>>> I believe it's established that consensus on rejection cannot be >>>> reached. Therefore I've started the alterntive proposal of moving these >>>> extensions back to draft: >>>> https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html >>>> >>>> The proposal to rejection is suspended until the alternate proposal is >>>> resolved. A failure to find a satisfactory resolution to these extensions >>>> will circle back to this rejection proposal. >>>> >>>> >>>> These extensions are referenced by the ratified extensions >>>> OES_texture_float and OES_texture_half_float. *Any* implementation >>>> supporting rendering to float or half_float via these extensions >>>> (including Chrome) is implicitly enabling WEBGL_color_buffer_float or >>>> EXT_color_buffer_half_float respectively. >>>> >>>> For the sake of argument let?s say we could change the ratified >>>> extensions and remove the references to the extensions you are so hot to >>>> reject. Then according to the remaining specifications, implementations >>>> should clamp clear colors and fragment shader outputs, making >>>> floating-point color buffers virtually useless. Nobody wants to go back to >>>> that situation. So these extensions cannot be rejected or returned to draft. >>>> >>>> If there truly are technical issues then Ken will have to detail them. >>>> I would far rather he concentrate on WebGL 2 than spend time digging into >>>> Chrome development history. Since these extensions are based on an >>>> existing native extension and are clearly implementable on desktop OpenGL >>>> and D3D, I suspect the issues are more to do with them not wanting to spend >>>> time making an officlal ANGLE extension equivalent to >>>> WEBGL_color_buffer_float rather than anything truly technical. Clearly they >>>> have a way to enable the functionality as they are currently doing so >>>> implicitly. >>>> >>>> >>>> - These extensions cannot be ratified, >>>> >>>> I didn?t say that. Did somebody else? I said the possibility was >>>> unclear. We can only truly find out by submitting them to the Khronos >>>> promoters. >>>> >>>> >>>> - which is a stated reason that they can be rejected in the >>>> extension development process guidelines. If you object to this reason, >>>> please move your objection over to the extension development process. >>>> >>>> The key word here is ?can?. Your revision to the guidelines does not >>>> say ?will?. If it did, I would have objected as would Jeff. >>>> >>>> Regards >>>> >>>> -Mark >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Feb 10 06:09:32 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 10 Feb 2015 14:09:32 +0000 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: Hi Frank, On Tue, Feb 10, 2015 at 1:47 AM, Frank Olivier wrote: > "Rejected extensions should never be implemented. " > > I would advocate for slightly different wording, with the same intent: > > - Vendors should avoid implementing rejected extensions. Since the wording about "proposed" extensions is pretty strong in the extension registry ("they should not be implemented, even under a vendor prefix") I think the wording should be even stronger about rejected extensions. > - Vendors may implement experimental extensions to obtain technical feedback > and to submit them to the ratification process. This second one should already be covered by the existing wording in the extension registry "Draft extensions may be implemented under a vendor prefix for experimentation purposes". Let me know if this seems insufficient. -Ken > "An extension enters rejected status because consensus on it could not be > reached at the proposal stage or technical difficulties arise during > implementation at the draft stage. A community approved extension can only > be rejected in extraordinary circumstances. A Khronos ratified extension > cannot be rejected." > > Agree with this wording. > > > > Thanks > > Frank > > > > From: Dean Jackson [mailto:dino...@] > Sent: Saturday, February 7, 2015 3:15 AM > To: Florian B?sch > Cc: public webgl; Frank Olivier > Subject: Re: extension development process > > > > > > On 7 Feb 2015, at 5:13 pm, Florian B?sch wrote: > > > > Frank and Dean, could we get it on the record here that you're in agreement > of this wording? > > > > Agreed. > > > > Dean > > > > > > On Fri, Feb 6, 2015 at 8:47 PM, Florian B?sch wrote: > > I have introduced the rejected status to the extension registry, added > wording explaining when an extension can be rejected and clarified the > process of extension advancement. Below are the added wordings: > > Every extension should advance to Khronos ratified. If an extension cannot > advance through the extension process it can be rejected. > > > > Rejected extensions should never be implemented. An extension enters > rejected status because consensus on it could not be reached at the proposal > stage or technical difficulties arise during implementation at the draft > stage. A community approved extension can only be rejected in extraordinary > circumstances. A Khronos ratified extension cannot be rejected. > > > > This is of course open for debate, but I find it a good idea. Can we form a > consensus on this? > > > > ----------------------------------------------------------- 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 Feb 10 06:57:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 10 Feb 2015 15:57:21 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: I understand the point Frank is making. After all we can't force a vendor not to implement an extension, no matter what its registry status is. A vendor might implement an extension, and then propose it, or never propose it all. So here's the deal. Any vendor, at any time could start introducing extensions out of the blue, without proposing them, or taking care to get them trough the extension process. The term "fait accompli extension" would probably fit. However I'd implore that such behavior is actually counter productive. If one vendor starts doing that, the other vendors will end up doing it as well. Before long, we'd end up with a multitude of slightly incompatible extensions covering the same functionality. Using the extended functionality would become very difficult for users, and other than having played another nuclear game of chicken nothing would've been accomplished. So I would propose an alternative resolution to this conundrum: 1. Khronos board members if they wish to retain their seat on the board need to adhere to the rules of the board, which includes the extension policy 2. The extension policy for what may or may not be implemented is further tightened and clarified, not weakened. 3. A section is added that would allow for a vendor to implement an extension not intended for any kind of standards process at that time as long as they properly prefix it That way we can keep the standards registry useful and a green pasture for everybody to enjoy, with strong protections in place to keep it that way. But we can also have vendors implement any extension they wish, long as they are willing to abide by the rules of the prefix game for vendor only extensions. On Tue, Feb 10, 2015 at 3:09 PM, Kenneth Russell wrote: > Hi Frank, > > On Tue, Feb 10, 2015 at 1:47 AM, Frank Olivier > wrote: > > "Rejected extensions should never be implemented. " > > > > I would advocate for slightly different wording, with the same intent: > > > > - Vendors should avoid implementing rejected extensions. > > Since the wording about "proposed" extensions is pretty strong in the > extension registry ("they should not be implemented, even under a > vendor prefix") I think the wording should be even stronger about > rejected extensions. > > > - Vendors may implement experimental extensions to obtain technical > feedback > > and to submit them to the ratification process. > > This second one should already be covered by the existing wording in > the extension registry "Draft extensions may be implemented under a > vendor prefix for experimentation purposes". Let me know if this seems > insufficient. > > -Ken > > > > "An extension enters rejected status because consensus on it could not be > > reached at the proposal stage or technical difficulties arise during > > implementation at the draft stage. A community approved extension can > only > > be rejected in extraordinary circumstances. A Khronos ratified extension > > cannot be rejected." > > > > Agree with this wording. > > > > > > > > Thanks > > > > Frank > > > > > > > > From: Dean Jackson [mailto:dino...@] > > Sent: Saturday, February 7, 2015 3:15 AM > > To: Florian B?sch > > Cc: public webgl; Frank Olivier > > Subject: Re: extension development process > > > > > > > > > > > > On 7 Feb 2015, at 5:13 pm, Florian B?sch wrote: > > > > > > > > Frank and Dean, could we get it on the record here that you're in > agreement > > of this wording? > > > > > > > > Agreed. > > > > > > > > Dean > > > > > > > > > > > > On Fri, Feb 6, 2015 at 8:47 PM, Florian B?sch wrote: > > > > I have introduced the rejected status to the extension registry, added > > wording explaining when an extension can be rejected and clarified the > > process of extension advancement. Below are the added wordings: > > > > Every extension should advance to Khronos ratified. If an extension > cannot > > advance through the extension process it can be rejected. > > > > > > > > Rejected extensions should never be implemented. An extension enters > > rejected status because consensus on it could not be reached at the > proposal > > stage or technical difficulties arise during implementation at the draft > > stage. A community approved extension can only be rejected in > extraordinary > > circumstances. A Khronos ratified extension cannot be rejected. > > > > > > > > This is of course open for debate, but I find it a good idea. Can we > form a > > consensus on this? > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Feb 10 07:05:18 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 10 Feb 2015 15:05:18 +0000 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: Jeff, thanks for the clarification. If you create patches to ANGLE that enable these extensions to be exposed on Firefox on Windows, please submit changelists for them. Also, if you find that the conformance tests for these WebGL extensions are lacking, please, submit pull requests enhancing the tests. I support Mozilla's efforts to properly implement these extensions in Firefox on top of WebGL 1.0, and don't support moving these extensions to rejected status. Mozilla followed all of the rules when requesting these extensions be moved from draft to community approved status, and I think it's both unnecessary and unfair to reject them and require Mozilla to undo their work. If it turns out that because of Mozilla's work it's trivial to expose these extensions in other WebGL implementations, we'll consider doing so in Chrome. -Ken On Tue, Feb 10, 2015 at 4:01 AM, Jeff Gilbert wrote: > I did some testing, and is seems that WEBGL_color_buffer_float is > implementable on ANGLE. (I haven't tested EXT_color_buffer_half_float, but > it seems like it should correspondingly be workable) I didn't test all > blending combinations, but basic clamped and unclamped tests work fine. The > only change needed in (Firefox's old copy of) ANGLE is removing the > call-time clamping on glBlendColor. > > Functionally, removing this seems to work fine, but Shannon (CC'd) would be > a better person to answer whether this is spec-compliant D3D, or if I'm > getting lucky with my driver. > > On Mon, Feb 9, 2015 at 12:59 PM, Jeff Gilbert wrote: >> >> Here's the deal with the Firefox numbers: >> >> Currently, Release is 35, Beta is 36, and Nightly is 38.[1] >> >> In Firefox 33, we landed a fix[2] which moves the color_buffer extensions >> behind a draft extensions pref, because they were still in Draft status at >> the time. 33 became Beta on 2014-09-02, and then Release on 2014-10-14. >> Looking at the data for Firefox+OSX, you can see a large activation rate for >> WEBGL_color_buffer_float declines sharply in October and November 2014, in >> line with this fix hitting the Release channel. >> >> In Firefox 36, we landed a fix[3] which moves the color_buffer extensions >> out from behind Draft, as they were promoted to Community Approved. In >> addition, we landed another fix[4] which enables WEBGL_color_buffer_float >> support on ANGLE. (I am currently working on a patch to support >> EXT_color_buffer_half_float on ANGLE) This means that you will see near-zero >> activation for this extension on Windows before 36. 36 is on Beta right now, >> and it will move to Release on 2015-02-24. The data for >> Firefox+OSX+WEBGL_color_buffer_float appears to be showing a small uptick >> already, but it's likely within the noise floor. However, you can definitely >> see Firefox+Windows activation for WEBGL_color_buffer_float coming on line, >> though it's still sitting at 2%. >> >> If it's possible to isolate Firefox 36+ from your data, how does the >> activation rate look there? >> >> I'm going to do my own investigation on the correctness of our >> implementation in the mean time, to be sure we're exposing it properly. >> >> [1]: https://wiki.mozilla.org/RapidRelease/Calendar >> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1023553 >> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1105535 >> [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1102667 >> >> On Sat, Feb 7, 2015 at 11:23 AM, Florian B?sch wrote: >>> >>> I want these extensions to be implemented, badly. In order to be >>> implemented, they have to be implementable. If they're not implementable, >>> they have no business having made it to community approved. If they cannot >>> be fixed, they're useless. If they're useless, they have no business being >>> in the active registry. Hence, both my proposal to reject them, and my >>> proposal to move them back to draft. It's not too late to correct a mistake. >>> Obstruction to clearing these extensions up one way or another serves no >>> purpose other than compounding that mistake. >>> >>> On Sat, Feb 7, 2015 at 8:12 PM, Florian B?sch wrote: >>>> >>>> These extensions are not ready, neither for community approval, nor for >>>> ratification. They cannot be ready, because one vendor, whom we've polled >>>> now to render his technical objection has stated that he has objections. >>>> Another vendor who purports to champion these extensions, is also not >>>> implementing them, for reasons unknown (but also polled). >>>> >>>> That a ratified extension refers to these extensions does not provide >>>> more credence to them being community ratified, it only serves to compounds >>>> the magnitude of error committed. >>>> >>>> A situation where extensions are promoted to "community ratified" based >>>> on a technicality, resulting in a registry containing extensions vendors are >>>> unwilling to implement is not tenable. This constitutes an extraordinary >>>> situation. >>>> >>>> I'm not eager to reject these extensions. I'm in fact in full >>>> recognition of the need for these extensions. But by shoddily pushing them >>>> along as has happened, without consensus at any stage, doesn't only harm >>>> WebGL and renders the registry a bad joke, it actively prevents these >>>> extensions from performing the job they're designed to perform. That is what >>>> I'm extremely eager to prevent. And that is why I'm pushing, quite hard, to >>>> get this rectified before it becomes a bad example to follow. >>>> >>>> On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow wrote: >>>>> >>>>> >>>>> On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: >>>>> >>>>> I believe it's established that consensus on rejection cannot be >>>>> reached. Therefore I've started the alterntive proposal of moving these >>>>> extensions back to draft: >>>>> https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html >>>>> >>>>> The proposal to rejection is suspended until the alternate proposal is >>>>> resolved. A failure to find a satisfactory resolution to these extensions >>>>> will circle back to this rejection proposal. >>>>> >>>>> >>>>> These extensions are referenced by the ratified extensions >>>>> OES_texture_float and OES_texture_half_float. *Any* implementation >>>>> supporting rendering to float or half_float via these extensions >>>>> (including Chrome) is implicitly enabling WEBGL_color_buffer_float or >>>>> EXT_color_buffer_half_float respectively. >>>>> >>>>> For the sake of argument let?s say we could change the ratified >>>>> extensions and remove the references to the extensions you are so hot to >>>>> reject. Then according to the remaining specifications, implementations >>>>> should clamp clear colors and fragment shader outputs, making floating-point >>>>> color buffers virtually useless. Nobody wants to go back to that situation. >>>>> So these extensions cannot be rejected or returned to draft. >>>>> >>>>> If there truly are technical issues then Ken will have to detail them. >>>>> I would far rather he concentrate on WebGL 2 than spend time digging into >>>>> Chrome development history. Since these extensions are based on an existing >>>>> native extension and are clearly implementable on desktop OpenGL and D3D, I >>>>> suspect the issues are more to do with them not wanting to spend time making >>>>> an officlal ANGLE extension equivalent to WEBGL_color_buffer_float rather >>>>> than anything truly technical. Clearly they have a way to enable the >>>>> functionality as they are currently doing so implicitly. >>>>> >>>>> These extensions cannot be ratified, >>>>> >>>>> I didn?t say that. Did somebody else? I said the possibility was >>>>> unclear. We can only truly find out by submitting them to the Khronos >>>>> promoters. >>>>> >>>>> which is a stated reason that they can be rejected in the extension >>>>> development process guidelines. If you object to this reason, please move >>>>> your objection over to the extension development process. >>>>> >>>>> The key word here is ?can?. Your revision to the guidelines does not >>>>> say ?will?. If it did, I would have objected as would Jeff. >>>>> >>>>> 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 pya...@ Tue Feb 10 07:10:25 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 10 Feb 2015 16:10:25 +0100 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: On Tue, Feb 10, 2015 at 4:05 PM, Kenneth Russell wrote: > If it turns out that because of Mozilla's work it's trivial to expose > these extensions in other WebGL implementations, we'll consider doing > so in Chrome. > That's excellent news. I will withdraw both proposals (for moving back to draft or rejection) if this turns out to be the case. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Feb 10 13:02:46 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 10 Feb 2015 13:02:46 -0800 Subject: [Public WebGL] rejecting WEBGL_color_buffer_float and EXT_color_buffer_half_float In-Reply-To: References: <16C15D76-A306-4264-B07F-6F92C7708B45@apple.com> <7EC1E63C-5FB2-4C59-8CDD-A3D7EED34A84@apple.com> <886D7475-16D3-4A2B-B4D2-1C4D619693BD@callow.im> <1BB74D03-CDD5-4D29-9027-4169ABAC6EC1@callow.im> Message-ID: I would like to emphasize that an implementation which implicitly enables an incomplete implementation of WEBGL_color_buffer_float is out-of-spec, and should not actually be exposing such behavior. It is in the interest of all members of the WG to get WEBGL_color_buffer_float (or an analogue) implemented properly, since spec-compliant render-to-float is not allowed otherwise. On Tue, Feb 10, 2015 at 7:05 AM, Kenneth Russell wrote: > Jeff, thanks for the clarification. > > If you create patches to ANGLE that enable these extensions to be > exposed on Firefox on Windows, please submit changelists for them. > Also, if you find that the conformance tests for these WebGL > extensions are lacking, please, submit pull requests enhancing the > tests. > > I support Mozilla's efforts to properly implement these extensions in > Firefox on top of WebGL 1.0, and don't support moving these extensions > to rejected status. Mozilla followed all of the rules when requesting > these extensions be moved from draft to community approved status, and > I think it's both unnecessary and unfair to reject them and require > Mozilla to undo their work. > > If it turns out that because of Mozilla's work it's trivial to expose > these extensions in other WebGL implementations, we'll consider doing > so in Chrome. > > -Ken > > > On Tue, Feb 10, 2015 at 4:01 AM, Jeff Gilbert > wrote: > > I did some testing, and is seems that WEBGL_color_buffer_float is > > implementable on ANGLE. (I haven't tested EXT_color_buffer_half_float, > but > > it seems like it should correspondingly be workable) I didn't test all > > blending combinations, but basic clamped and unclamped tests work fine. > The > > only change needed in (Firefox's old copy of) ANGLE is removing the > > call-time clamping on glBlendColor. > > > > Functionally, removing this seems to work fine, but Shannon (CC'd) would > be > > a better person to answer whether this is spec-compliant D3D, or if I'm > > getting lucky with my driver. > > > > On Mon, Feb 9, 2015 at 12:59 PM, Jeff Gilbert > wrote: > >> > >> Here's the deal with the Firefox numbers: > >> > >> Currently, Release is 35, Beta is 36, and Nightly is 38.[1] > >> > >> In Firefox 33, we landed a fix[2] which moves the color_buffer > extensions > >> behind a draft extensions pref, because they were still in Draft status > at > >> the time. 33 became Beta on 2014-09-02, and then Release on 2014-10-14. > >> Looking at the data for Firefox+OSX, you can see a large activation > rate for > >> WEBGL_color_buffer_float declines sharply in October and November 2014, > in > >> line with this fix hitting the Release channel. > >> > >> In Firefox 36, we landed a fix[3] which moves the color_buffer > extensions > >> out from behind Draft, as they were promoted to Community Approved. In > >> addition, we landed another fix[4] which enables > WEBGL_color_buffer_float > >> support on ANGLE. (I am currently working on a patch to support > >> EXT_color_buffer_half_float on ANGLE) This means that you will see > near-zero > >> activation for this extension on Windows before 36. 36 is on Beta right > now, > >> and it will move to Release on 2015-02-24. The data for > >> Firefox+OSX+WEBGL_color_buffer_float appears to be showing a small > uptick > >> already, but it's likely within the noise floor. However, you can > definitely > >> see Firefox+Windows activation for WEBGL_color_buffer_float coming on > line, > >> though it's still sitting at 2%. > >> > >> If it's possible to isolate Firefox 36+ from your data, how does the > >> activation rate look there? > >> > >> I'm going to do my own investigation on the correctness of our > >> implementation in the mean time, to be sure we're exposing it properly. > >> > >> [1]: https://wiki.mozilla.org/RapidRelease/Calendar > >> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1023553 > >> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1105535 > >> [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1102667 > >> > >> On Sat, Feb 7, 2015 at 11:23 AM, Florian B?sch > wrote: > >>> > >>> I want these extensions to be implemented, badly. In order to be > >>> implemented, they have to be implementable. If they're not > implementable, > >>> they have no business having made it to community approved. If they > cannot > >>> be fixed, they're useless. If they're useless, they have no business > being > >>> in the active registry. Hence, both my proposal to reject them, and my > >>> proposal to move them back to draft. It's not too late to correct a > mistake. > >>> Obstruction to clearing these extensions up one way or another serves > no > >>> purpose other than compounding that mistake. > >>> > >>> On Sat, Feb 7, 2015 at 8:12 PM, Florian B?sch > wrote: > >>>> > >>>> These extensions are not ready, neither for community approval, nor > for > >>>> ratification. They cannot be ready, because one vendor, whom we've > polled > >>>> now to render his technical objection has stated that he has > objections. > >>>> Another vendor who purports to champion these extensions, is also not > >>>> implementing them, for reasons unknown (but also polled). > >>>> > >>>> That a ratified extension refers to these extensions does not provide > >>>> more credence to them being community ratified, it only serves to > compounds > >>>> the magnitude of error committed. > >>>> > >>>> A situation where extensions are promoted to "community ratified" > based > >>>> on a technicality, resulting in a registry containing extensions > vendors are > >>>> unwilling to implement is not tenable. This constitutes an > extraordinary > >>>> situation. > >>>> > >>>> I'm not eager to reject these extensions. I'm in fact in full > >>>> recognition of the need for these extensions. But by shoddily pushing > them > >>>> along as has happened, without consensus at any stage, doesn't only > harm > >>>> WebGL and renders the registry a bad joke, it actively prevents these > >>>> extensions from performing the job they're designed to perform. That > is what > >>>> I'm extremely eager to prevent. And that is why I'm pushing, quite > hard, to > >>>> get this rectified before it becomes a bad example to follow. > >>>> > >>>> On Sat, Feb 7, 2015 at 7:58 PM, Mark Callow > wrote: > >>>>> > >>>>> > >>>>> On Feb 6, 2015, at 11:29 PM, Florian B?sch wrote: > >>>>> > >>>>> I believe it's established that consensus on rejection cannot be > >>>>> reached. Therefore I've started the alterntive proposal of moving > these > >>>>> extensions back to draft: > >>>>> > https://www.khronos.org/webgl/public-mailing-list/archives/1502/msg00042.html > >>>>> > >>>>> The proposal to rejection is suspended until the alternate proposal > is > >>>>> resolved. A failure to find a satisfactory resolution to these > extensions > >>>>> will circle back to this rejection proposal. > >>>>> > >>>>> > >>>>> These extensions are referenced by the ratified extensions > >>>>> OES_texture_float and OES_texture_half_float. *Any* implementation > >>>>> supporting rendering to float or half_float via these extensions > >>>>> (including Chrome) is implicitly enabling WEBGL_color_buffer_float or > >>>>> EXT_color_buffer_half_float respectively. > >>>>> > >>>>> For the sake of argument let?s say we could change the ratified > >>>>> extensions and remove the references to the extensions you are so > hot to > >>>>> reject. Then according to the remaining specifications, > implementations > >>>>> should clamp clear colors and fragment shader outputs, making > floating-point > >>>>> color buffers virtually useless. Nobody wants to go back to that > situation. > >>>>> So these extensions cannot be rejected or returned to draft. > >>>>> > >>>>> If there truly are technical issues then Ken will have to detail > them. > >>>>> I would far rather he concentrate on WebGL 2 than spend time digging > into > >>>>> Chrome development history. Since these extensions are based on an > existing > >>>>> native extension and are clearly implementable on desktop OpenGL and > D3D, I > >>>>> suspect the issues are more to do with them not wanting to spend > time making > >>>>> an officlal ANGLE extension equivalent to WEBGL_color_buffer_float > rather > >>>>> than anything truly technical. Clearly they have a way to enable the > >>>>> functionality as they are currently doing so implicitly. > >>>>> > >>>>> These extensions cannot be ratified, > >>>>> > >>>>> I didn?t say that. Did somebody else? I said the possibility was > >>>>> unclear. We can only truly find out by submitting them to the Khronos > >>>>> promoters. > >>>>> > >>>>> which is a stated reason that they can be rejected in the extension > >>>>> development process guidelines. If you object to this reason, please > move > >>>>> your objection over to the extension development process. > >>>>> > >>>>> The key word here is ?can?. Your revision to the guidelines does not > >>>>> say ?will?. If it did, I would have objected as would Jeff. > >>>>> > >>>>> Regards > >>>>> > >>>>> -Mark > >>>>> > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fra...@ Tue Feb 10 18:08:49 2015 From: Fra...@ (Frank Olivier) Date: Wed, 11 Feb 2015 02:08:49 +0000 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: Thanks Florian, Ken. I agree that ?fait accompli extensions? usually have counterproductive side effects; I think we all want to avoid introducing situations where the open web comes to rely on a single-vendor extension (of any sort, whether it be in HTML or CSS or network protocols, or in any other web platform feature) to function. (We?ve had to deal with some pain here: http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx) We like the idea of a ratified extension list; this will help ensure that vendors have a clear list of extensions to ship, and developers have a clear interoperable list of functionality to use. As you said, we can't force a vendor not to implement an extension, no matter what its registry status is; no standards body has been able to reliably and adequately perform this feat. I agree with you that it would be useful to allow for a vendor to implement an extension not intended for any kind of standards process at that time as long as they properly prefix it. I believe such a mechanism would be useful especially in HTML runtime environments that is *not* the open web. (Silly example: A browser might expose some prefixed WebGL extension (exposed to the browser add-on runtime environment only) that allows the add-on developer to render 3D graphics into the browser frame.) Thanks Frank From: Florian B?sch [mailto:pyalot...@] Sent: Tuesday, February 10, 2015 6:57 AM To: Kenneth Russell Cc: Frank Olivier; Dean Jackson; public webgl Subject: Re: [Public WebGL] RE: extension development process I understand the point Frank is making. After all we can't force a vendor not to implement an extension, no matter what its registry status is. A vendor might implement an extension, and then propose it, or never propose it all. So here's the deal. Any vendor, at any time could start introducing extensions out of the blue, without proposing them, or taking care to get them trough the extension process. The term "fait accompli extension" would probably fit. However I'd implore that such behavior is actually counter productive. If one vendor starts doing that, the other vendors will end up doing it as well. Before long, we'd end up with a multitude of slightly incompatible extensions covering the same functionality. Using the extended functionality would become very difficult for users, and other than having played another nuclear game of chicken nothing would've been accomplished. So I would propose an alternative resolution to this conundrum: 1. Khronos board members if they wish to retain their seat on the board need to adhere to the rules of the board, which includes the extension policy 2. The extension policy for what may or may not be implemented is further tightened and clarified, not weakened. 3. A section is added that would allow for a vendor to implement an extension not intended for any kind of standards process at that time as long as they properly prefix it That way we can keep the standards registry useful and a green pasture for everybody to enjoy, with strong protections in place to keep it that way. But we can also have vendors implement any extension they wish, long as they are willing to abide by the rules of the prefix game for vendor only extensions. On Tue, Feb 10, 2015 at 3:09 PM, Kenneth Russell > wrote: Hi Frank, On Tue, Feb 10, 2015 at 1:47 AM, Frank Olivier > wrote: > "Rejected extensions should never be implemented. " > > I would advocate for slightly different wording, with the same intent: > > - Vendors should avoid implementing rejected extensions. Since the wording about "proposed" extensions is pretty strong in the extension registry ("they should not be implemented, even under a vendor prefix") I think the wording should be even stronger about rejected extensions. > - Vendors may implement experimental extensions to obtain technical feedback > and to submit them to the ratification process. This second one should already be covered by the existing wording in the extension registry "Draft extensions may be implemented under a vendor prefix for experimentation purposes". Let me know if this seems insufficient. -Ken > "An extension enters rejected status because consensus on it could not be > reached at the proposal stage or technical difficulties arise during > implementation at the draft stage. A community approved extension can only > be rejected in extraordinary circumstances. A Khronos ratified extension > cannot be rejected." > > Agree with this wording. > > > > Thanks > > Frank > > > > From: Dean Jackson [mailto:dino...@] > Sent: Saturday, February 7, 2015 3:15 AM > To: Florian B?sch > Cc: public webgl; Frank Olivier > Subject: Re: extension development process > > > > > > On 7 Feb 2015, at 5:13 pm, Florian B?sch > wrote: > > > > Frank and Dean, could we get it on the record here that you're in agreement > of this wording? > > > > Agreed. > > > > Dean > > > > > > On Fri, Feb 6, 2015 at 8:47 PM, Florian B?sch > wrote: > > I have introduced the rejected status to the extension registry, added > wording explaining when an extension can be rejected and clarified the > process of extension advancement. Below are the added wordings: > > Every extension should advance to Khronos ratified. If an extension cannot > advance through the extension process it can be rejected. > > > > Rejected extensions should never be implemented. An extension enters > rejected status because consensus on it could not be reached at the proposal > stage or technical difficulties arise during implementation at the draft > stage. A community approved extension can only be rejected in extraordinary > circumstances. A Khronos ratified extension cannot be rejected. > > > > This is of course open for debate, but I find it a good idea. Can we form a > consensus on this? > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Feb 10 23:50:55 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 08:50:55 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier wrote: > > I agree with you that it would be useful to allow for a vendor to > implement an extension not intended for any kind of standards process at > that time as long as they properly prefix it. I believe such a mechanism > would be useful especially in HTML runtime environments that is **not** > the open web. (Silly example: A browser might expose some prefixed WebGL > extension (exposed to the browser add-on runtime environment only) that > allows the add-on developer to render 3D graphics into the browser frame.) > In traditional GL the vendor prefix usually serves this function. However in WebGL we've already used the vendor prefix slightly differently (for draft extensions on track to be standardized). I'd suggest tacking on an additional prefix for extensions a vendor does not wish to standardize at that time, something like: NONSTANDARD_MS_your_extension. Would this be a satisfactory convention for everybody? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 11 03:13:05 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 11 Feb 2015 11:13:05 +0000 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: I think the WebGL extension registry should document all extensions, even those which might not be intended for a standards track. It's not a burden to write a little documentation for new extensions, and gives other implementers the opportunity to provide some compatibility. It's also not a big burden to leave an extension in draft status for some time while its utility is being proven. There was a long discussion about vendor prefixes for WebGL extensions some time ago, with the conclusion that draft extensions should preferably be exposed behind some sort of run-time flag, not enabled by default, and also not use vendor prefixes. I've updated the extension registry in https://github.com/KhronosGroup/WebGL/pull/861 to indicate this. -Ken On Wed, Feb 11, 2015 at 7:50 AM, Florian B?sch wrote: > On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier > wrote: >> >> I agree with you that it would be useful to allow for a vendor to >> implement an extension not intended for any kind of standards process at >> that time as long as they properly prefix it. I believe such a mechanism >> would be useful especially in HTML runtime environments that is *not* the >> open web. (Silly example: A browser might expose some prefixed WebGL >> extension (exposed to the browser add-on runtime environment only) that >> allows the add-on developer to render 3D graphics into the browser frame.) > > > In traditional GL the vendor prefix usually serves this function. However in > WebGL we've already used the vendor prefix slightly differently (for draft > extensions on track to be standardized). > > I'd suggest tacking on an additional prefix for extensions a vendor does not > wish to standardize at that time, something like: > NONSTANDARD_MS_your_extension. > > Would this be a satisfactory convention for everybody? ----------------------------------------------------------- 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 Feb 11 03:23:37 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 12:23:37 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: That doesn't address the issue I see. Without a way for a vendor to expose nonstandard extensions to the public, they're required to submit it to proposal, get it to draft and push it trough to community approved before they can expose it to the public. In turn this means that any single vendor can demand that their extension is elevated practically straight to community approved without consensus at the proposal stage, without alternative implementations at the draft stage and without community approval at the community approved stage. Effectively your suggestion amounts to that proposal, draft and community approved are "standards exempt". I do think that proposal, draft and community approved are standards track states. On Wed, Feb 11, 2015 at 12:13 PM, Kenneth Russell wrote: > I think the WebGL extension registry should document all extensions, > even those which might not be intended for a standards track. It's not > a burden to write a little documentation for new extensions, and gives > other implementers the opportunity to provide some compatibility. It's > also not a big burden to leave an extension in draft status for some > time while its utility is being proven. > > There was a long discussion about vendor prefixes for WebGL extensions > some time ago, with the conclusion that draft extensions should > preferably be exposed behind some sort of run-time flag, not enabled > by default, and also not use vendor prefixes. I've updated the > extension registry in https://github.com/KhronosGroup/WebGL/pull/861 > to indicate this. > > -Ken > > > On Wed, Feb 11, 2015 at 7:50 AM, Florian B?sch wrote: > > On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier < > Frank.Olivier...@> > > wrote: > >> > >> I agree with you that it would be useful to allow for a vendor to > >> implement an extension not intended for any kind of standards process at > >> that time as long as they properly prefix it. I believe such a mechanism > >> would be useful especially in HTML runtime environments that is *not* > the > >> open web. (Silly example: A browser might expose some prefixed WebGL > >> extension (exposed to the browser add-on runtime environment only) that > >> allows the add-on developer to render 3D graphics into the browser > frame.) > > > > > > In traditional GL the vendor prefix usually serves this function. > However in > > WebGL we've already used the vendor prefix slightly differently (for > draft > > extensions on track to be standardized). > > > > I'd suggest tacking on an additional prefix for extensions a vendor does > not > > wish to standardize at that time, something like: > > NONSTANDARD_MS_your_extension. > > > > Would this be a satisfactory convention for everybody? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 11 03:35:09 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 12:35:09 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> Message-ID: Besides there's no reason the registry couldn't list NONSTANDARD_* extensions under a category "Non Standard Extensions". On Wed, Feb 11, 2015 at 12:23 PM, Florian B?sch wrote: > That doesn't address the issue I see. Without a way for a vendor to expose > nonstandard extensions to the public, they're required to submit it to > proposal, get it to draft and push it trough to community approved before > they can expose it to the public. In turn this means that any single vendor > can demand that their extension is elevated practically straight to > community approved without consensus at the proposal stage, without > alternative implementations at the draft stage and without community > approval at the community approved stage. > > Effectively your suggestion amounts to that proposal, draft and community > approved are "standards exempt". I do think that proposal, draft and > community approved are standards track states. > > On Wed, Feb 11, 2015 at 12:13 PM, Kenneth Russell wrote: > >> I think the WebGL extension registry should document all extensions, >> even those which might not be intended for a standards track. It's not >> a burden to write a little documentation for new extensions, and gives >> other implementers the opportunity to provide some compatibility. It's >> also not a big burden to leave an extension in draft status for some >> time while its utility is being proven. >> >> There was a long discussion about vendor prefixes for WebGL extensions >> some time ago, with the conclusion that draft extensions should >> preferably be exposed behind some sort of run-time flag, not enabled >> by default, and also not use vendor prefixes. I've updated the >> extension registry in https://github.com/KhronosGroup/WebGL/pull/861 >> to indicate this. >> >> -Ken >> >> >> On Wed, Feb 11, 2015 at 7:50 AM, Florian B?sch wrote: >> > On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier < >> Frank.Olivier...@> >> > wrote: >> >> >> >> I agree with you that it would be useful to allow for a vendor to >> >> implement an extension not intended for any kind of standards process >> at >> >> that time as long as they properly prefix it. I believe such a >> mechanism >> >> would be useful especially in HTML runtime environments that is *not* >> the >> >> open web. (Silly example: A browser might expose some prefixed WebGL >> >> extension (exposed to the browser add-on runtime environment only) that >> >> allows the add-on developer to render 3D graphics into the browser >> frame.) >> > >> > >> > In traditional GL the vendor prefix usually serves this function. >> However in >> > WebGL we've already used the vendor prefix slightly differently (for >> draft >> > extensions on track to be standardized). >> > >> > I'd suggest tacking on an additional prefix for extensions a vendor >> does not >> > wish to standardize at that time, something like: >> > NONSTANDARD_MS_your_extension. >> > >> > Would this be a satisfactory convention for everybody? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Wed Feb 11 03:48:21 2015 From: oet...@ (Olli Etuaho) Date: Wed, 11 Feb 2015 11:48:21 +0000 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> , Message-ID: <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Yep, the extension registry also says that "Every extension should advance to Khronos ratified". It would be good to add a separate track for non-standard extensions that are not meant to be exposed to the public web if some vendor is interested in implementing such extensions. But I'd defer adding such a track until there's an actual use case for it. -Olli ________________________________ From: owners-public_webgl...@ on behalf of Florian B?sch Sent: Wednesday, February 11, 2015 1:35 PM To: Kenneth Russell Cc: Frank Olivier; Dean Jackson; public webgl Subject: Re: [Public WebGL] RE: extension development process Besides there's no reason the registry couldn't list NONSTANDARD_* extensions under a category "Non Standard Extensions". On Wed, Feb 11, 2015 at 12:23 PM, Florian B?sch > wrote: That doesn't address the issue I see. Without a way for a vendor to expose nonstandard extensions to the public, they're required to submit it to proposal, get it to draft and push it trough to community approved before they can expose it to the public. In turn this means that any single vendor can demand that their extension is elevated practically straight to community approved without consensus at the proposal stage, without alternative implementations at the draft stage and without community approval at the community approved stage. Effectively your suggestion amounts to that proposal, draft and community approved are "standards exempt". I do think that proposal, draft and community approved are standards track states. On Wed, Feb 11, 2015 at 12:13 PM, Kenneth Russell > wrote: I think the WebGL extension registry should document all extensions, even those which might not be intended for a standards track. It's not a burden to write a little documentation for new extensions, and gives other implementers the opportunity to provide some compatibility. It's also not a big burden to leave an extension in draft status for some time while its utility is being proven. There was a long discussion about vendor prefixes for WebGL extensions some time ago, with the conclusion that draft extensions should preferably be exposed behind some sort of run-time flag, not enabled by default, and also not use vendor prefixes. I've updated the extension registry in https://github.com/KhronosGroup/WebGL/pull/861 to indicate this. -Ken On Wed, Feb 11, 2015 at 7:50 AM, Florian B?sch > wrote: > On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier > > wrote: >> >> I agree with you that it would be useful to allow for a vendor to >> implement an extension not intended for any kind of standards process at >> that time as long as they properly prefix it. I believe such a mechanism >> would be useful especially in HTML runtime environments that is *not* the >> open web. (Silly example: A browser might expose some prefixed WebGL >> extension (exposed to the browser add-on runtime environment only) that >> allows the add-on developer to render 3D graphics into the browser frame.) > > > In traditional GL the vendor prefix usually serves this function. However in > WebGL we've already used the vendor prefix slightly differently (for draft > extensions on track to be standardized). > > I'd suggest tacking on an additional prefix for extensions a vendor does not > wish to standardize at that time, something like: > NONSTANDARD_MS_your_extension. > > Would this be a satisfactory convention for everybody? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 11 04:23:54 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 13:23:54 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: I'll ilustrate the idea of the process (including a non-standard track) http://codeflow.org/pictures/extension-process.svg On Wed, Feb 11, 2015 at 12:48 PM, Olli Etuaho wrote: > Yep, the extension registry also says that "Every extension should > advance to Khronos ratified". It would be good to add a separate track for > non-standard extensions that are not meant to be exposed to the public web > if some vendor is interested in implementing such extensions. But I'd defer > adding such a track until there's an actual use case for it. > > > > -Olli > ------------------------------ > *From:* owners-public_webgl...@ > on behalf of Florian B?sch > *Sent:* Wednesday, February 11, 2015 1:35 PM > *To:* Kenneth Russell > *Cc:* Frank Olivier; Dean Jackson; public webgl > *Subject:* Re: [Public WebGL] RE: extension development process > > Besides there's no reason the registry couldn't list NONSTANDARD_* > extensions under a category "Non Standard Extensions". > > On Wed, Feb 11, 2015 at 12:23 PM, Florian B?sch wrote: > >> That doesn't address the issue I see. Without a way for a vendor to >> expose nonstandard extensions to the public, they're required to submit it >> to proposal, get it to draft and push it trough to community approved >> before they can expose it to the public. In turn this means that any single >> vendor can demand that their extension is elevated practically straight to >> community approved without consensus at the proposal stage, without >> alternative implementations at the draft stage and without community >> approval at the community approved stage. >> >> Effectively your suggestion amounts to that proposal, draft and >> community approved are "standards exempt". I do think that proposal, draft >> and community approved are standards track states. >> >> On Wed, Feb 11, 2015 at 12:13 PM, Kenneth Russell wrote: >> >>> I think the WebGL extension registry should document all extensions, >>> even those which might not be intended for a standards track. It's not >>> a burden to write a little documentation for new extensions, and gives >>> other implementers the opportunity to provide some compatibility. It's >>> also not a big burden to leave an extension in draft status for some >>> time while its utility is being proven. >>> >>> There was a long discussion about vendor prefixes for WebGL extensions >>> some time ago, with the conclusion that draft extensions should >>> preferably be exposed behind some sort of run-time flag, not enabled >>> by default, and also not use vendor prefixes. I've updated the >>> extension registry in https://github.com/KhronosGroup/WebGL/pull/861 >>> to indicate this. >>> >>> -Ken >>> >>> >>> On Wed, Feb 11, 2015 at 7:50 AM, Florian B?sch wrote: >>> > On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier < >>> Frank.Olivier...@> >>> > wrote: >>> >> >>> >> I agree with you that it would be useful to allow for a vendor to >>> >> implement an extension not intended for any kind of standards process >>> at >>> >> that time as long as they properly prefix it. I believe such a >>> mechanism >>> >> would be useful especially in HTML runtime environments that is *not* >>> the >>> >> open web. (Silly example: A browser might expose some prefixed WebGL >>> >> extension (exposed to the browser add-on runtime environment only) >>> that >>> >> allows the add-on developer to render 3D graphics into the browser >>> frame.) >>> > >>> > >>> > In traditional GL the vendor prefix usually serves this function. >>> However in >>> > WebGL we've already used the vendor prefix slightly differently (for >>> draft >>> > extensions on track to be standardized). >>> > >>> > I'd suggest tacking on an additional prefix for extensions a vendor >>> does not >>> > wish to standardize at that time, something like: >>> > NONSTANDARD_MS_your_extension. >>> > >>> > Would this be a satisfactory convention for everybody? >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 11 04:29:51 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 11 Feb 2015 12:29:51 +0000 Subject: [Public WebGL] RE: extension development process In-Reply-To: <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: I agree with not complicating the extension registry further until there is a specific need for it. In my opinion, adding an extension proposal for a vendor's particular extension idea is a viable option. -Ken On Wed, Feb 11, 2015 at 11:48 AM, Olli Etuaho wrote: > Yep, the extension registry also says that "Every extension should advance > to Khronos ratified". It would be good to add a separate track for > non-standard extensions that are not meant to be exposed to the public web > if some vendor is interested in implementing such extensions. But I'd defer > adding such a track until there's an actual use case for it. > > > > -Olli > > ________________________________ > From: owners-public_webgl...@ on > behalf of Florian B?sch > Sent: Wednesday, February 11, 2015 1:35 PM > To: Kenneth Russell > Cc: Frank Olivier; Dean Jackson; public webgl > Subject: Re: [Public WebGL] RE: extension development process > > Besides there's no reason the registry couldn't list NONSTANDARD_* > extensions under a category "Non Standard Extensions". > > On Wed, Feb 11, 2015 at 12:23 PM, Florian B?sch wrote: >> >> That doesn't address the issue I see. Without a way for a vendor to expose >> nonstandard extensions to the public, they're required to submit it to >> proposal, get it to draft and push it trough to community approved before >> they can expose it to the public. In turn this means that any single vendor >> can demand that their extension is elevated practically straight to >> community approved without consensus at the proposal stage, without >> alternative implementations at the draft stage and without community >> approval at the community approved stage. >> >> Effectively your suggestion amounts to that proposal, draft and community >> approved are "standards exempt". I do think that proposal, draft and >> community approved are standards track states. >> >> On Wed, Feb 11, 2015 at 12:13 PM, Kenneth Russell wrote: >>> >>> I think the WebGL extension registry should document all extensions, >>> even those which might not be intended for a standards track. It's not >>> a burden to write a little documentation for new extensions, and gives >>> other implementers the opportunity to provide some compatibility. It's >>> also not a big burden to leave an extension in draft status for some >>> time while its utility is being proven. >>> >>> There was a long discussion about vendor prefixes for WebGL extensions >>> some time ago, with the conclusion that draft extensions should >>> preferably be exposed behind some sort of run-time flag, not enabled >>> by default, and also not use vendor prefixes. I've updated the >>> extension registry in https://github.com/KhronosGroup/WebGL/pull/861 >>> to indicate this. >>> >>> -Ken >>> >>> >>> On Wed, Feb 11, 2015 at 7:50 AM, Florian B?sch wrote: >>> > On Wed, Feb 11, 2015 at 3:08 AM, Frank Olivier >>> > >>> > wrote: >>> >> >>> >> I agree with you that it would be useful to allow for a vendor to >>> >> implement an extension not intended for any kind of standards process >>> >> at >>> >> that time as long as they properly prefix it. I believe such a >>> >> mechanism >>> >> would be useful especially in HTML runtime environments that is *not* >>> >> the >>> >> open web. (Silly example: A browser might expose some prefixed WebGL >>> >> extension (exposed to the browser add-on runtime environment only) >>> >> that >>> >> allows the add-on developer to render 3D graphics into the browser >>> >> frame.) >>> > >>> > >>> > In traditional GL the vendor prefix usually serves this function. >>> > However in >>> > WebGL we've already used the vendor prefix slightly differently (for >>> > draft >>> > extensions on track to be standardized). >>> > >>> > I'd suggest tacking on an additional prefix for extensions a vendor >>> > does not >>> > wish to standardize at that time, something like: >>> > NONSTANDARD_MS_your_extension. >>> > >>> > Would this be a satisfactory convention for everybody? >> >> > ----------------------------------------------------------- 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 Feb 11 04:38:31 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 13:38:31 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell wrote: > In my opinion, adding an extension proposal for a vendor's particular > extension idea is a viable option. > It's not a viable option. In order to publicly expose an extension it has to move to "Community Approved". In order to do that, consensus has to reached on the proposal, and multiple vendors have to be implementing it. It's a good option for an extension for which that process is intended, and it should if at all possible be intended for every extension. But it could happen that that's not the case (for instance there could be proprietary IP attached to the extension, or no consensus could be reached, or unsurmountable implementation difficulties could emerge etc.), but the vendor would still like to expose the extension. Moving something to "Community Approved" that isn't is perverse. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 11 04:56:11 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 13:56:11 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: OpenGL and OpenGL ES has a clear scheme to deal with non-standard extensions. They're vendor prefixed. They don't have publicly transparent scheme for proposal/draft/community approved/ratified states (although some of that is noted on the extensions). WebGL lacks a clear scheme to deal with non-standard extensions, and so we're having discussions about the deeper meanings of the standards track states. Adding a non-standard category allows the standard categories to be rigid and easy to follow. Not allowing a non-standard category makes it muddy and uncertain what these "standard track" categories even mean. On Wed, Feb 11, 2015 at 1:38 PM, Florian B?sch wrote: > On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell wrote: > >> In my opinion, adding an extension proposal for a vendor's particular >> extension idea is a viable option. >> > > It's not a viable option. In order to publicly expose an extension it has > to move to "Community Approved". In order to do that, consensus has to > reached on the proposal, and multiple vendors have to be implementing it. > It's a good option for an extension for which that process is intended, and > it should if at all possible be intended for every extension. But it could > happen that that's not the case (for instance there could be proprietary IP > attached to the extension, or no consensus could be reached, or > unsurmountable implementation difficulties could emerge etc.), but the > vendor would still like to expose the extension. Moving something to > "Community Approved" that isn't is perverse. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 11 05:09:22 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 14:09:22 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: If you don't have a way to deal with non standard extensions, then the status of proposal, draft and community approved become meaningless and should be abandoned. Because the result would be that extensions which are consensus based and multi-vendor implementation based find themselves in "community approved" alongside extensions which aren't. That would be quite confusing. On Wed, Feb 11, 2015 at 1:56 PM, Florian B?sch wrote: > OpenGL and OpenGL ES has a clear scheme to deal with non-standard > extensions. They're vendor prefixed. They don't have publicly transparent > scheme for proposal/draft/community approved/ratified states (although some > of that is noted on the extensions). > > WebGL lacks a clear scheme to deal with non-standard extensions, and so > we're having discussions about the deeper meanings of the standards track > states. Adding a non-standard category allows the standard categories to be > rigid and easy to follow. Not allowing a non-standard category makes it > muddy and uncertain what these "standard track" categories even mean. > > On Wed, Feb 11, 2015 at 1:38 PM, Florian B?sch wrote: > >> On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell wrote: >> >>> In my opinion, adding an extension proposal for a vendor's particular >>> extension idea is a viable option. >>> >> >> It's not a viable option. In order to publicly expose an extension it has >> to move to "Community Approved". In order to do that, consensus has to >> reached on the proposal, and multiple vendors have to be implementing it. >> It's a good option for an extension for which that process is intended, and >> it should if at all possible be intended for every extension. But it could >> happen that that's not the case (for instance there could be proprietary IP >> attached to the extension, or no consensus could be reached, or >> unsurmountable implementation difficulties could emerge etc.), but the >> vendor would still like to expose the extension. Moving something to >> "Community Approved" that isn't is perverse. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 11 05:10:41 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 14:10:41 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: It would be confusing because then it becomes impossible for users to gauge the safety and future-proofness of using an extension based on its status. On Wed, Feb 11, 2015 at 2:09 PM, Florian B?sch wrote: > If you don't have a way to deal with non standard extensions, then the > status of proposal, draft and community approved become meaningless and > should be abandoned. Because the result would be that extensions which are > consensus based and multi-vendor implementation based find themselves in > "community approved" alongside extensions which aren't. That would be quite > confusing. > > On Wed, Feb 11, 2015 at 1:56 PM, Florian B?sch wrote: > >> OpenGL and OpenGL ES has a clear scheme to deal with non-standard >> extensions. They're vendor prefixed. They don't have publicly transparent >> scheme for proposal/draft/community approved/ratified states (although some >> of that is noted on the extensions). >> >> WebGL lacks a clear scheme to deal with non-standard extensions, and so >> we're having discussions about the deeper meanings of the standards track >> states. Adding a non-standard category allows the standard categories to be >> rigid and easy to follow. Not allowing a non-standard category makes it >> muddy and uncertain what these "standard track" categories even mean. >> >> On Wed, Feb 11, 2015 at 1:38 PM, Florian B?sch wrote: >> >>> On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell wrote: >>> >>>> In my opinion, adding an extension proposal for a vendor's particular >>>> extension idea is a viable option. >>>> >>> >>> It's not a viable option. In order to publicly expose an extension it >>> has to move to "Community Approved". In order to do that, consensus has to >>> reached on the proposal, and multiple vendors have to be implementing it. >>> It's a good option for an extension for which that process is intended, and >>> it should if at all possible be intended for every extension. But it could >>> happen that that's not the case (for instance there could be proprietary IP >>> attached to the extension, or no consensus could be reached, or >>> unsurmountable implementation difficulties could emerge etc.), but the >>> vendor would still like to expose the extension. Moving something to >>> "Community Approved" that isn't is perverse. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 11 05:20:29 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Feb 2015 14:20:29 +0100 Subject: [Public WebGL] RE: extension development process In-Reply-To: References: <06EE349F-5B98-4494-8E2A-3E8DC53215FB@apple.com> <74d7778905b44fe3b2b996f2f916afd9@UKMAIL101.nvidia.com> Message-ID: I don't think it's a problem not to define the how to do it at this time. As long as there's agreement that that kind of extension does not fit into the existing process we have. On Wed, Feb 11, 2015 at 2:10 PM, Florian B?sch wrote: > It would be confusing because then it becomes impossible for users to > gauge the safety and future-proofness of using an extension based on its > status. > > On Wed, Feb 11, 2015 at 2:09 PM, Florian B?sch wrote: > >> If you don't have a way to deal with non standard extensions, then the >> status of proposal, draft and community approved become meaningless and >> should be abandoned. Because the result would be that extensions which are >> consensus based and multi-vendor implementation based find themselves in >> "community approved" alongside extensions which aren't. That would be quite >> confusing. >> >> On Wed, Feb 11, 2015 at 1:56 PM, Florian B?sch wrote: >> >>> OpenGL and OpenGL ES has a clear scheme to deal with non-standard >>> extensions. They're vendor prefixed. They don't have publicly transparent >>> scheme for proposal/draft/community approved/ratified states (although some >>> of that is noted on the extensions). >>> >>> WebGL lacks a clear scheme to deal with non-standard extensions, and so >>> we're having discussions about the deeper meanings of the standards track >>> states. Adding a non-standard category allows the standard categories to be >>> rigid and easy to follow. Not allowing a non-standard category makes it >>> muddy and uncertain what these "standard track" categories even mean. >>> >>> On Wed, Feb 11, 2015 at 1:38 PM, Florian B?sch wrote: >>> >>>> On Wed, Feb 11, 2015 at 1:29 PM, Kenneth Russell >>>> wrote: >>>> >>>>> In my opinion, adding an extension proposal for a vendor's particular >>>>> extension idea is a viable option. >>>>> >>>> >>>> It's not a viable option. In order to publicly expose an extension it >>>> has to move to "Community Approved". In order to do that, consensus has to >>>> reached on the proposal, and multiple vendors have to be implementing it. >>>> It's a good option for an extension for which that process is intended, and >>>> it should if at all possible be intended for every extension. But it could >>>> happen that that's not the case (for instance there could be proprietary IP >>>> attached to the extension, or no consensus could be reached, or >>>> unsurmountable implementation difficulties could emerge etc.), but the >>>> vendor would still like to expose the extension. Moving something to >>>> "Community Approved" that isn't is perverse. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Feb 17 15:13:30 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 17 Feb 2015 15:13:30 -0800 Subject: [Public WebGL] Proposal for WEBGL_render_to_float Message-ID: I have proposed a more restricted extension for supporting render-to-float functionality: https://github.com/KhronosGroup/WebGL/pull/867 >From the pull request: --- This might be a more portable way to allow render-to-float behavior in WebGL. It's more restricted than WEBGL_color_buffer_float or EXT_color_buffer_half_float. It's implementable everywhere that supports render-to-float, including D3D9. BLEND with floating-point is disallowed because of lack of support. EXT_color_buffer_float does not allow blending with float32s, and D3D9 only supports normalized uint8 glBlendColor-equivalent. clear() is disallowed because many implementations clamp clearColor, (driver bugs) and/or limit clearColor to normalized uint8 values. (D3D9. Notably, 0.5f is not representable in normalized uint8) WebGL implementations can work around this by doing a full-screen blit, but this is much more expensive, and current best-practice is to no longer hide performance caveats. For textures, the initial contents can be set at upload-time. If there is strong support for floating-point clears on drivers that can't support the full WEBGL_color_buffer_float/EXT_color_buffer_half_float extensions, we can add an extension just for floating-point clears. (similar in nature to OES_texture_float_linear) We could split this into WEBGL_render_to_float and WEBGL_render_to_half_float, but we should only do so if there are platforms or configurations which require this differentiation. (That is, FLOAT and HALF_FLOAT_OES textures are supported, but only one of the two is renderable) --- This should be able to address the concerns about supporting render-to-float without meeting the requirements of the actual render-to-float extensions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Wed Feb 18 04:19:30 2015 From: oet...@ (Olli Etuaho) Date: Wed, 18 Feb 2015 12:19:30 +0000 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: Removing the support for blending is an unfortunate regression. That means use cases that need blending need to switch to ping-ponging between two framebuffers, and that eats up a lot of performance. On an app I've developed a path that uses blending to floating-point framebuffers is 2x as fast as a path that uses switching framebuffers. Maybe blending to floating point framebuffers could be exposed as a separate extension, which could also be made available on WebGL 2? I don't agree with that clear() should be disallowed. Driver bugs can and should be fixed, and needing a workaround on D3D9 which is slowly getting phased out doesn't seem like enough of a reason to make this basic operation hard to do in WebGL. -Olli ________________________________ From: owners-public_webgl...@ on behalf of Jeff Gilbert Sent: Wednesday, February 18, 2015 1:13 AM To: webgl, public Subject: [Public WebGL] Proposal for WEBGL_render_to_float I have proposed a more restricted extension for supporting render-to-float functionality: https://github.com/KhronosGroup/WebGL/pull/867 >From the pull request: --- This might be a more portable way to allow render-to-float behavior in WebGL. It's more restricted than WEBGL_color_buffer_float or EXT_color_buffer_half_float. It's implementable everywhere that supports render-to-float, including D3D9. BLEND with floating-point is disallowed because of lack of support. EXT_color_buffer_float does not allow blending with float32s, and D3D9 only supports normalized uint8 glBlendColor-equivalent. clear() is disallowed because many implementations clamp clearColor, (driver bugs) and/or limit clearColor to normalized uint8 values. (D3D9. Notably, 0.5f is not representable in normalized uint8) WebGL implementations can work around this by doing a full-screen blit, but this is much more expensive, and current best-practice is to no longer hide performance caveats. For textures, the initial contents can be set at upload-time. If there is strong support for floating-point clears on drivers that can't support the full WEBGL_color_buffer_float/EXT_color_buffer_half_float extensions, we can add an extension just for floating-point clears. (similar in nature to OES_texture_float_linear) We could split this into WEBGL_render_to_float and WEBGL_render_to_half_float, but we should only do so if there are platforms or configurations which require this differentiation. (That is, FLOAT and HALF_FLOAT_OES textures are supported, but only one of the two is renderable) --- This should be able to address the concerns about supporting render-to-float without meeting the requirements of the actual render-to-float extensions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 18 06:15:02 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Feb 2015 15:15:02 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: On Wed, Feb 18, 2015 at 12:13 AM, Jeff Gilbert wrote: > I have proposed a more restricted extension for supporting render-to-float > functionality: > https://github.com/KhronosGroup/WebGL/pull/867 > Regardless of content I think it's getting kinda messy with the myriad of floating point extensions. BLEND with floating-point is disallowed because of lack of support. > EXT_color_buffer_float does not allow blending with float32s > That's quite a limitation because that is often the impetus to use floating point in the first place. > and D3D9 only supports normalized uint8 glBlendColor-equivalent. > You do not need glBlendColor to make effective use of say, additive blending to a floating point texture to accumulate a calculation. > clear() is disallowed because many implementations clamp clearColor, > (driver bugs) and/or limit clearColor to normalized uint8 values. (D3D9. > Notably, 0.5f is not representable in normalized uint8) WebGL > implementations can work around this by doing a full-screen blit, but this > is much more expensive, and current best-practice is to no longer hide > performance caveats. > I believe that setting the viewport, setting a vertex attrib pointer, using a shader and calling draw is actually cheaper than calling glClear in pretty much all circumstances. And I was under the impression that gl.clear was shimmed to that anyway. > For textures, the initial contents can be set at upload-time. If there is > strong support for floating-point clears on drivers that can't support the > full WEBGL_color_buffer_float/EXT_color_buffer_half_float extensions, we > can add an extension just for floating-point clears. (similar in nature to > OES_texture_float_linear) > It's getting even more crowded with those extensions... > We could split this into WEBGL_render_to_float and > WEBGL_render_to_half_float, but we should only do so if there are platforms > or configurations which require this differentiation. (That is, FLOAT and > HALF_FLOAT_OES textures are supported, but only one of the two is > renderable) > Mobiles typically do not support rendering to float32 at all, but may support rendering to float16. I'd like to add that I strongly disapprove of the mess this is getting, and I'd like to suggest that adding more and more extensions to cover float this-or-that seems like a bad thing to do. How about an extension to end all float extensions, that contains an interface that lets one query every imaginable aspect related to floating point textures? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 18 06:31:46 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Feb 2015 15:31:46 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: On Wed, Feb 18, 2015 at 3:15 PM, Florian B?sch wrote: > > I'd like to add that I strongly disapprove of the mess this is getting, > and I'd like to suggest that adding more and more extensions to cover float > this-or-that seems like a bad thing to do. How about an extension to end > all float extensions, that contains an interface that lets one query every > imaginable aspect related to floating point textures? > I'd like to elaborate a bit on that point. So far we have no less than 7 extensions that deal with floating point textures: - OES_texture_float - OES_texture_half_float - OES_texture_float_linear - OES_texture_half_float_linear - EXT_color_buffer_half_float - WEBGL_color_buffer_float - EXT_color_buffer_float (fair bit of overlap with the former two, except blending) And now the suggestion is to add 2 more (bringing it to 9): - WEBGL_render_to_half_float - WEBGL_render_to_float But because these don't cover clearing we're talking about adding 2 more (for a total of 11) - WEBGL_clear_half_float - WEBGL_clear_float Of course these don't cover blending, which may further differentiate into blendFunc and blendColor, so we'd be adding 4 more (for a total of 15) - WEBGL_blend_func_half_float - WEBGL_blend_func_float - WEBGL_blend_color_half_float - WEBGL_blend_color_float I suppose there could be further implementation differences requiring even more extensions. I think this is a problem for several reasons: 1) It makes handling floating point textures messy for users because some of these extensions overlap in functionality, others, in some circumstances implicitely enable each other, etc. 2) It makes handling floating point textures messy for implementors because following the rules imposed by multiply-overlapping-implicitely-enabling extensions on the implementation behavior becomes quite the exercise. I believe it would be better to have one extension, that covers everything related to floating point textures and offers its own interface to deal with them. It would offer: - All the floating point enumerants - Flags indicating a capability (such as extension.float32.blendable) - If that's desired it could offer float-versions of functions such as clear, blendFunc, blendColor, readPixels, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 18 09:45:44 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Feb 2015 18:45:44 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: As far as I can tell ASTC has support on roughly 0% of desktops and mobiles. A while back I compiled extension statistics, and ASTC doesn't appear on that list at all (because the extension isn't listed for any device on http://gfxbench.com/. The extension is also not listed on http://feedback.wildfiregames.com/report/opengl/ . How do you conclude that it's well supported? On Wed, Feb 18, 2015 at 4:29 PM, Christophe Riccio < christophe.riccio...@> wrote: > Hi, > > Are you considering an ASTC extension for WebGL? > It seems that the ecosystem adoption of ASTC is significantly larger than > ETC2/EAC. > > Thanks, > Christophe > > On 6 February 2015 at 21:48, Kenneth Russell wrote: > >> >> On Fri, Feb 6, 2015 at 1:45 AM, Florian B?sch wrote: >> > On Fri, Feb 6, 2015 at 4:00 AM, Kenneth Russell wrote: >> >> >> >> >> The ES 3.0.4 specification defines the errors INVALID_OPERATION, >> should >> >> >> it >> >> >> be added? >> >> > >> >> > Anybody know the answer to that one? >> >> >> >> It looks like the other WebGL extensions defining compressed textures >> >> use INVALID_VALUE for this size check. I assume the conformance tests >> >> are already verifying this. I'm in favor of minimizing the churn of >> >> both the specs and tests in this area, so would suggest it be left as >> >> is. >> > >> > >> > INVALID_OPERATION is issued by compressedTexImage2D if: >> > >> > the format does not match the internal format >> > If additional restrictions specified by the compression format >> specification >> > apply and aren't satisfied >> > >> > INVALID_OPERATION is issued by compressedTexSubImage2D if: >> > >> > xoffset or yoffset are not zero >> > width and height don't match the dimension of the texture level (is >> relaxed >> > for specific formats which are easily modified) >> >> I'm not sure what portion of the spec you're referring to. Please feel >> >> free to submit pull requests containing any clarifications you suggest >> >> and they can be discussed there. Thanks. >> > >> > >> > INVALID_VALUE is issued in addition to dimension mismatch when: >> > >> > The encoding of the compressed texture doesn't match the format >> > specification >> >> I'm not understanding what you're proposing be changed here -- don't >> have time right now to go through these specs in detail. Please just >> submit pull requests for whatever you are proposing so we can be very >> precise about what's being discussed. Thanks. >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> >> > > > -- > Christophe Riccio - G-Truc Creation > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 18 11:34:31 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Feb 2015 20:34:31 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: I get that ASTC is nice and all. But it's got 0% support, and 0% adoption so far. How's it helping to introduce "functionality" to WebGL which nobody can run, nobody can write code for, nobody can write a conformance test for and nobody will be able to do any of those things for years and years? If it does turn out to be around somewhere, anywhere at all, there's ample time to add it at that time. On Wed, Feb 18, 2015 at 8:22 PM, Christophe Riccio < christophe.riccio...@> wrote: > I am not speaking about support here but about adoption. What we need as > an ecosystem is an universal texture format, supported by everyone. ASTC > has been designed for this purpose and this is why it's a KHR extension > and > not only ARB extension. > > ETC2 and EAC have been force on the ARB because of ES compatibility so > effectively all the drivers on desktop hardware just uncompressed the > textures when loading them. I am not sure about the status of ETC2 and EAC > on mobile but I expect a certain level of identical behavior. > Furthermore, while ETC2 is a 4bpp format, ASTC is a 0.86bpp format which > for the WebGL side of things is super important. > > Creating a WebGL extension for ASTC would really help the whole ecosystem > to move forward so that we can get this universal texture format that we > absolutely require. > > Thanks, > Christophe > > > On 18 February 2015 at 18:45, Florian B?sch wrote: > >> As far as I can tell ASTC has support on roughly 0% of desktops and >> mobiles. >> >> A while back I compiled extension statistics, and ASTC doesn't appear on >> that list at all (because the extension isn't listed for any device on >> http://gfxbench.com/. The extension is also not listed on >> http://feedback.wildfiregames.com/report/opengl/ . >> >> How do you conclude that it's well supported? >> >> >> >> On Wed, Feb 18, 2015 at 4:29 PM, Christophe Riccio < >> christophe.riccio...@> wrote: >> >>> Hi, >>> >>> Are you considering an ASTC extension for WebGL? >>> It seems that the ecosystem adoption of ASTC is significantly larger >>> than ETC2/EAC. >>> >>> Thanks, >>> Christophe >>> >>> On 6 February 2015 at 21:48, Kenneth Russell wrote: >>> >>>> >>>> On Fri, Feb 6, 2015 at 1:45 AM, Florian B?sch wrote: >>>> > On Fri, Feb 6, 2015 at 4:00 AM, Kenneth Russell >>>> wrote: >>>> >> >>>> >> >> The ES 3.0.4 specification defines the errors INVALID_OPERATION, >>>> should >>>> >> >> it >>>> >> >> be added? >>>> >> > >>>> >> > Anybody know the answer to that one? >>>> >> >>>> >> It looks like the other WebGL extensions defining compressed textures >>>> >> use INVALID_VALUE for this size check. I assume the conformance tests >>>> >> are already verifying this. I'm in favor of minimizing the churn of >>>> >> both the specs and tests in this area, so would suggest it be left as >>>> >> is. >>>> > >>>> > >>>> > INVALID_OPERATION is issued by compressedTexImage2D if: >>>> > >>>> > the format does not match the internal format >>>> > If additional restrictions specified by the compression format >>>> specification >>>> > apply and aren't satisfied >>>> > >>>> > INVALID_OPERATION is issued by compressedTexSubImage2D if: >>>> > >>>> > xoffset or yoffset are not zero >>>> > width and height don't match the dimension of the texture level (is >>>> relaxed >>>> > for specific formats which are easily modified) >>>> >> I'm not sure what portion of the spec you're referring to. Please >>>> feel >>>> >> free to submit pull requests containing any clarifications you >>>> suggest >>>> >> and they can be discussed there. Thanks. >>>> > >>>> > >>>> > INVALID_VALUE is issued in addition to dimension mismatch when: >>>> > >>>> > The encoding of the compressed texture doesn't match the format >>>> > specification >>>> >>>> I'm not understanding what you're proposing be changed here -- don't >>>> have time right now to go through these specs in detail. Please just >>>> submit pull requests for whatever you are proposing so we can be very >>>> precise about what's being discussed. Thanks. >>>> >>>> ----------------------------------------------------------- >>>> 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...@ Wed Feb 18 11:49:48 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Feb 2015 20:49:48 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: It's not that it isn't important. But to explain, the policy on WebGL extensions has been so far to add those which expose widely available features (on both mobiles and desktops). Every extension in the registry has been subjected to this litmus test. I may not personally agree with that policy, but it's one that every member of the committee and every public participant had to accommodate themselves with. For example, 3D-textures wheren't added to WebGL years ago because mobile support for them wasn't great. It's still not great. Mobiles make something like 10-20% of WebGL traffic. I have argued, to no avail, that this shouldn't be a reason not to add them. The second we'll change this policy, I'll personally suggest at least a dozen new extensions exposing features I'm quite fond of, but for which support is not great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Wed Feb 18 11:59:51 2015 From: chr...@ (Christophe Riccio) Date: Wed, 18 Feb 2015 20:59:51 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: I wasn't aware of that policy but I understand the purpose. What's the criterion/limit for considering new extension? Thanks, Christophe On Wed, Feb 18, 2015 at 8:49 PM, Florian B?sch wrote: > It's not that it isn't important. But to explain, the policy on WebGL > extensions has been so far to add those which expose widely available > features (on both mobiles and desktops). Every extension in the registry > has been subjected to this litmus test. > > I may not personally agree with that policy, but it's one that every > member of the committee and every public participant had to accommodate > themselves with. For example, 3D-textures wheren't added to WebGL years ago > because mobile support for them wasn't great. It's still not great. Mobiles > make something like 10-20% of WebGL traffic. I have argued, to no avail, > that this shouldn't be a reason not to add them. > > The second we'll change this policy, I'll personally suggest at least a > dozen new extensions exposing features I'm quite fond of, but for which > support is not great. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 18 12:05:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Feb 2015 21:05:05 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Wed, Feb 18, 2015 at 8:59 PM, Christophe Riccio < christophe.riccio...@> wrote: > What's the criterion/limit for considering new extension? > It's not a fixed number. An extension is considered if consensus on it can be reached. Most of the time (in my experience) it's difficult to reach consensus for extensions for which support isn't great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Wed Feb 18 12:07:29 2015 From: chr...@ (Christophe Riccio) Date: Wed, 18 Feb 2015 21:07:29 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: Thanks! :) On Wed, Feb 18, 2015 at 9:05 PM, Florian B?sch wrote: > On Wed, Feb 18, 2015 at 8:59 PM, Christophe Riccio < > christophe.riccio...@> wrote: > >> What's the criterion/limit for considering new extension? >> > It's not a fixed number. An extension is considered if consensus on it can > be reached. Most of the time (in my experience) it's difficult to reach > consensus for extensions for which support isn't great. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 18 14:59:29 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 18 Feb 2015 22:59:29 +0000 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: It would be great to expose the ASTC compressed texture format to WebGL. It seems it's the most likely compressed texture format to be supported universally across devices. In order to define a WebGL extension for it, some amount of validation of the incoming data has to be performed -- in particular, structural validation of the input data, to ensure the incoming data is the correct size. The following extensions: https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_atc/ https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_etc1/ https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_pvrtc/ https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_s3tc/ define the required size of the input data based on its format. It seems more difficult to do so for ASTC, based on scanning through https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt . Christophe, would you be able to help define the needed language for the WebGL extension? Do ASTC conformance tests already exist -- both positive and negative tests -- which could be adapted for WebGL? Thanks, -Ken On Wed, Feb 18, 2015 at 8:07 PM, Christophe Riccio wrote: > Thanks! :) > > On Wed, Feb 18, 2015 at 9:05 PM, Florian B?sch wrote: >> >> On Wed, Feb 18, 2015 at 8:59 PM, Christophe Riccio >> wrote: >>> >>> What's the criterion/limit for considering new extension? >> >> It's not a fixed number. An extension is considered if consensus on it can >> be reached. Most of the time (in my experience) it's difficult to reach >> consensus for extensions for which support isn't great. > > ----------------------------------------------------------- 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 Feb 18 15:10:02 2015 From: chr...@ (Christophe Riccio) Date: Thu, 19 Feb 2015 00:10:02 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: Hi Ken, We have been supporting ASTC in Unity for 2 years already and we have code to compute the correct size per format. I should be able to submit a proposal for ASTC. I'll investigate regarding the conformance tests. Thanks! Christophe On Wed, Feb 18, 2015 at 11:59 PM, Kenneth Russell wrote: > It would be great to expose the ASTC compressed texture format to > WebGL. It seems it's the most likely compressed texture format to be > supported universally across devices. > > In order to define a WebGL extension for it, some amount of validation > of the incoming data has to be performed -- in particular, structural > validation of the input data, to ensure the incoming data is the > correct size. > > The following extensions: > > > https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_atc/ > > https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_etc1/ > > https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_pvrtc/ > > https://www.khronos.org/registry/webgl/extensions/WEBGL_compressed_texture_s3tc/ > > define the required size of the input data based on its format. > > It seems more difficult to do so for ASTC, based on scanning through > https://www.opengl.org/registry/specs/KHR/texture_compression_astc_hdr.txt > . Christophe, would you be able to help define the needed language for > the WebGL extension? > > Do ASTC conformance tests already exist -- both positive and negative > tests -- which could be adapted for WebGL? > > Thanks, > > -Ken > > > > On Wed, Feb 18, 2015 at 8:07 PM, Christophe Riccio > wrote: > > Thanks! :) > > > > On Wed, Feb 18, 2015 at 9:05 PM, Florian B?sch wrote: > >> > >> On Wed, Feb 18, 2015 at 8:59 PM, Christophe Riccio > >> wrote: > >>> > >>> What's the criterion/limit for considering new extension? > >> > >> It's not a fixed number. An extension is considered if consensus on it > can > >> be reached. Most of the time (in my experience) it's difficult to reach > >> consensus for extensions for which support isn't great. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 18 15:38:16 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 18 Feb 2015 23:38:16 +0000 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: Jeff, thanks for putting together this extension proposal and uncovering more of the underlying issues. It does seem to me that the number of extensions defining floating-point texture behavior in WebGL is getting out of hand, and that the limitations imposed by this proposal are too harsh. Let's discuss it in a higher-bandwidth format on the next working group conference call (tomorrow). The discovery that https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_float.txt forbids blending when any of the color buffers are fp32 is correct, and surprising. Since https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_half_float.txt doesn't impose this restriction I would like to understand why that restriction is present, and whether it can be lifted. -Ken On Wed, Feb 18, 2015 at 2:31 PM, Florian B?sch wrote: > On Wed, Feb 18, 2015 at 3:15 PM, Florian B?sch wrote: >> >> I'd like to add that I strongly disapprove of the mess this is getting, >> and I'd like to suggest that adding more and more extensions to cover float >> this-or-that seems like a bad thing to do. How about an extension to end all >> float extensions, that contains an interface that lets one query every >> imaginable aspect related to floating point textures? > > > I'd like to elaborate a bit on that point. > > So far we have no less than 7 extensions that deal with floating point > textures: > > - OES_texture_float > - OES_texture_half_float > - OES_texture_float_linear > - OES_texture_half_float_linear > - EXT_color_buffer_half_float > - WEBGL_color_buffer_float > - EXT_color_buffer_float (fair bit of overlap with the former two, except > blending) > > And now the suggestion is to add 2 more (bringing it to 9): > > - WEBGL_render_to_half_float > - WEBGL_render_to_float > > But because these don't cover clearing we're talking about adding 2 more > (for a total of 11) > > - WEBGL_clear_half_float > - WEBGL_clear_float > > Of course these don't cover blending, which may further differentiate into > blendFunc and blendColor, so we'd be adding 4 more (for a total of 15) > > - WEBGL_blend_func_half_float > - WEBGL_blend_func_float > - WEBGL_blend_color_half_float > - WEBGL_blend_color_float > > I suppose there could be further implementation differences requiring even > more extensions. > > I think this is a problem for several reasons: > > 1) It makes handling floating point textures messy for users because some of > these extensions overlap in functionality, others, in some circumstances > implicitely enable each other, etc. > 2) It makes handling floating point textures messy for implementors because > following the rules imposed by multiply-overlapping-implicitely-enabling > extensions on the implementation behavior becomes quite the exercise. > > I believe it would be better to have one extension, that covers everything > related to floating point textures and offers its own interface to deal with > them. It would offer: > > - All the floating point enumerants > - Flags indicating a capability (such as extension.float32.blendable) > - If that's desired it could offer float-versions of functions such as > clear, blendFunc, blendColor, readPixels, etc. > ----------------------------------------------------------- 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...@ Wed Feb 18 16:20:57 2015 From: jgi...@ (Jeff Gilbert) Date: Wed, 18 Feb 2015 16:20:57 -0800 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: Clear() is faster than doing a rasterization pass, and is effectively free on many drivers. (basically all tilers) If Clear() weren't cheaper, the driver would implement it as a rendering pass. In practice, I don't think we need a huge list of these extensions. I'm just trying to get us to a sane point regarding what people believe is implementable for rendering-to-float as historically implied by OES_texture_[half_]float. Firefox is going to expose both color_buffer extensions on many drivers, but notably we cannot support these on D3D9. On Wed, Feb 18, 2015 at 6:31 AM, Florian B?sch wrote: > On Wed, Feb 18, 2015 at 3:15 PM, Florian B?sch wrote: >> >> I'd like to add that I strongly disapprove of the mess this is getting, >> and I'd like to suggest that adding more and more extensions to cover float >> this-or-that seems like a bad thing to do. How about an extension to end >> all float extensions, that contains an interface that lets one query every >> imaginable aspect related to floating point textures? >> > > I'd like to elaborate a bit on that point. > > So far we have no less than 7 extensions that deal with floating point > textures: > > - OES_texture_float > - OES_texture_half_float > - OES_texture_float_linear > - OES_texture_half_float_linear > - EXT_color_buffer_half_float > - WEBGL_color_buffer_float > - EXT_color_buffer_float (fair bit of overlap with the former two, except > blending) > > And now the suggestion is to add 2 more (bringing it to 9): > > - WEBGL_render_to_half_float > - WEBGL_render_to_float > > But because these don't cover clearing we're talking about adding 2 more > (for a total of 11) > > - WEBGL_clear_half_float > - WEBGL_clear_float > > Of course these don't cover blending, which may further differentiate into > blendFunc and blendColor, so we'd be adding 4 more (for a total of 15) > > - WEBGL_blend_func_half_float > - WEBGL_blend_func_float > - WEBGL_blend_color_half_float > - WEBGL_blend_color_float > > I suppose there could be further implementation differences requiring even > more extensions. > > I think this is a problem for several reasons: > > 1) It makes handling floating point textures messy for users because some > of these extensions overlap in functionality, others, in some circumstances > implicitely enable each other, etc. > 2) It makes handling floating point textures messy for implementors > because following the rules imposed by > multiply-overlapping-implicitely-enabling extensions on the implementation > behavior becomes quite the exercise. > > I believe it would be better to have one extension, that covers everything > related to floating point textures and offers its own interface to deal > with them. It would offer: > > - All the floating point enumerants > - Flags indicating a capability (such as extension.float32.blendable) > - If that's desired it could offer float-versions of functions such as > clear, blendFunc, blendColor, readPixels, etc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Wed Feb 18 18:35:51 2015 From: Raf...@ (Rafael Cintron) Date: Thu, 19 Feb 2015 02:35:51 +0000 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: I was not around when these extensions were proposed. However, it is true, at least on the Windows platform, that some hardware can support 16bit blendable render targets while others can only do non-blendable render targets. The web page https://msdn.microsoft.com/en-us/library/windows/desktop/ff471324(v=vs.85).aspx (Hardware Support for Direct3D 10Level9 Formats) has tables that detail the restrictions. Note that for 16bit floating textures, blendable render targets are only supported on FL9_3 and above, whereas non-blendable is supported on FL9_2 and above. For 32bit floating point textures, only feature level 9_3 supports non-blendable render targets. No blending is allowed on feature level 9_X. Feature level 10+, of course, supports blendable 16 and 32 bit floating point textures. Floating point textures already have extensions that let you distinguish between "linear" and non-linear support with regard to shader sampling and mip maps. Adding additional extension types for blended vs. non-blended render targets would increase the combinatorial gymnastics for developers. Adding capability bits to existing or new extension types seems like the best way forward if we want to lift the blendability restriction. --Rafael -----Original Message----- From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell Sent: Wednesday, February 18, 2015 3:38 PM To: Florian B?sch Cc: Jeff Gilbert; webgl, public Subject: Re: [Public WebGL] Proposal for WEBGL_render_to_float Jeff, thanks for putting together this extension proposal and uncovering more of the underlying issues. It does seem to me that the number of extensions defining floating-point texture behavior in WebGL is getting out of hand, and that the limitations imposed by this proposal are too harsh. Let's discuss it in a higher-bandwidth format on the next working group conference call (tomorrow). The discovery that https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_float.txt forbids blending when any of the color buffers are fp32 is correct, and surprising. Since https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_half_float.txt doesn't impose this restriction I would like to understand why that restriction is present, and whether it can be lifted. -Ken On Wed, Feb 18, 2015 at 2:31 PM, Florian B?sch wrote: > On Wed, Feb 18, 2015 at 3:15 PM, Florian B?sch wrote: >> >> I'd like to add that I strongly disapprove of the mess this is >> getting, and I'd like to suggest that adding more and more extensions >> to cover float this-or-that seems like a bad thing to do. How about >> an extension to end all float extensions, that contains an interface >> that lets one query every imaginable aspect related to floating point textures? > > > I'd like to elaborate a bit on that point. > > So far we have no less than 7 extensions that deal with floating point > textures: > > - OES_texture_float > - OES_texture_half_float > - OES_texture_float_linear > - OES_texture_half_float_linear > - EXT_color_buffer_half_float > - WEBGL_color_buffer_float > - EXT_color_buffer_float (fair bit of overlap with the former two, > except > blending) > > And now the suggestion is to add 2 more (bringing it to 9): > > - WEBGL_render_to_half_float > - WEBGL_render_to_float > > But because these don't cover clearing we're talking about adding 2 > more (for a total of 11) > > - WEBGL_clear_half_float > - WEBGL_clear_float > > Of course these don't cover blending, which may further differentiate > into blendFunc and blendColor, so we'd be adding 4 more (for a total > of 15) > > - WEBGL_blend_func_half_float > - WEBGL_blend_func_float > - WEBGL_blend_color_half_float > - WEBGL_blend_color_float > > I suppose there could be further implementation differences requiring > even more extensions. > > I think this is a problem for several reasons: > > 1) It makes handling floating point textures messy for users because > some of these extensions overlap in functionality, others, in some > circumstances implicitely enable each other, etc. > 2) It makes handling floating point textures messy for implementors > because following the rules imposed by > multiply-overlapping-implicitely-enabling > extensions on the implementation behavior becomes quite the exercise. > > I believe it would be better to have one extension, that covers > everything related to floating point textures and offers its own > interface to deal with them. It would offer: > > - All the floating point enumerants > - Flags indicating a capability (such as extension.float32.blendable) > - If that's desired it could offer float-versions of functions such as > clear, blendFunc, blendColor, readPixels, etc. > ----------------------------------------------------------- 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 khr...@ Sat Feb 21 01:33:10 2015 From: khr...@ (Mark Callow) Date: Sat, 21 Feb 2015 18:33:10 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> Regarding ClearColor, OpenGL specifications up to 4.2 specified clampf arguments to glClearColor. This spec. bug was fixed in an update to OpenGL 4.2. (The spec now has the opposite problem: it does not specify clamping for fixed-point buffers). I recommend leaving the *_color_buffer{_half,}_float specs as is. Implementations should clear via drawing a full screen quad when running on older versions of OpenGL that are clamping. The performance difference should be small, certainly nowhere near a MajorPerformanceCaveat. Implementations can still use glClear if the specified clear color is between 0 and 1. This clamping problem must have always existed for implementations exposing float rendering implicitly via OES_texture{_half,}_float. Regarding blending, I recommend changing WEBGL_color_buffer_float to make the blending behavior the same as EXT_color_buffer_float. This will allow implementations of WebGL 1 to expose it on OpenGL ES 3.x class hardware. We should create a new extension, WEBGL_blend_float say, to allow full blending to be exposed when running on desktop. There is no equivalent OpenGL ES extension, from which we can conclude that no mobile GPUs have yet added this feature. IIRC, it was omitted from OpenGL ES 3.x because of the number of gates it would require. Intermediate computations for both blending and filtering require more than 32-bits. It was felt that the cost outweighed the benefit. This leaves a problem for implementations exposing floating-point rendering implicitly via OES_texture_float. They may today support blending when running on desktop-class hardware. Since OES_texture_float says to follow WEBGL_color_buffer_float, they would now be prohibited from allowing that blending. There are 2 choices I see Attempt to change a ratified extension to state that applications implicitly enabling float rendering act as if both WEBGL_color_buffer_float and WEBGL_blend_float are enabled. Drawback: they could not now expose float rendering on OpenGL ES-class hardware or D3D9. Live with the regression. blending couldn?t have worked on ES-class hardware anyway and likely hasn?t been working on D3D9, unless ANGLE is jumping through hoops. Therefore the number of affected applications is likely to be small. I recommend #2. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Sat Feb 21 01:37:55 2015 From: khr...@ (Mark Callow) Date: Sat, 21 Feb 2015 18:37:55 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: Message-ID: > On Feb 19, 2015, at 11:35 AM, Rafael Cintron wrote: > > Floating point textures already have extensions that let you distinguish between "linear" and non-linear support with regard to shader sampling and mip maps. Adding additional extension types for blended vs. non-blended render targets would increase the combinatorial gymnastics for developers. Adding capability bits to existing or new extension types seems like the best way forward if we want to lift the blendability restriction. I think that whether blending support is determined by attempting to enable an extension or querying a capability bit makes little difference to an application. But capability bits probably make for less messy documentation and an easier to grasp overall picture. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Sat Feb 21 01:40:09 2015 From: khr...@ (Mark Callow) Date: Sat, 21 Feb 2015 18:40:09 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> Message-ID: <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> > On Feb 21, 2015, at 6:33 PM, Mark Callow wrote: > > We should create a new extension, WEBGL_blend_float say, to allow full blending to be exposed when running on desktop. This extension could also be supported by WebGL 2 implementations when exposing EXT_color_buffer_float on desktop-class hardware. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Sat Feb 21 05:10:59 2015 From: khr...@ (Mark Callow) Date: Sat, 21 Feb 2015 22:10:59 +0900 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: <37B3179A-0907-4242-A5A9-D92F7C9F76D9@callow.im> > On Feb 19, 2015, at 7:59 AM, Kenneth Russell wrote: > > Do ASTC conformance tests already exist -- both positive and negative > tests -- which could be adapted for WebGL? Yes, quite extensive but not sure about both positive and negative. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Sat Feb 21 05:25:29 2015 From: khr...@ (Mark Callow) Date: Sat, 21 Feb 2015 22:25:29 +0900 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: > On Feb 19, 2015, at 2:45 AM, Florian B?sch wrote: > > As far as I can tell ASTC has support on roughly 0% of desktops and mobiles. > > A while back I compiled extension statistics, and ASTC doesn't appear on that list at all (because the extension isn't listed for any device on http://gfxbench.com/ . The extension is also not listed on http://feedback.wildfiregames.com/report/opengl/ . > > How do you conclude that it's well supported? The relevant extensions don?t appear in the list at the latter site so it appears it is not even measuring if they are supported or not. As for the former, I don?t see how to search by supported extensions. Maybe you need to register to do that. The NVIDIA Logan family has hardware support for ASTC. I believe it is supported in software on some earlier devices. I?m pretty sure ARM supports it too. :-) Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sat Feb 21 23:00:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 08:00:33 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Sat, Feb 21, 2015 at 2:25 PM, Mark Callow wrote: > The relevant extensions don?t appear in the list at the latter site so it > appears it is not even measuring if they are supported or not. > Wildfire games records every extension it sees. If it had encountered it, it'd be there. I don't have any machine on which ASTC extensions show up. > As for the former, I don?t see how to search by supported extensions. > Maybe you need to register to do that. > I did a crawler to do that. None of the devices on gfxbench.com list the extension for any device they have in their database. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Feb 21 23:06:18 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 08:06:18 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: I'd like to put a stop to the somewhat popular notion that we can change ratified extensions and change implemented behavior (even if it's somewhat undefined) for several reasons. 1) We cannot modify a ratified extension, ever. 2) Retrograding features such as blending on floating point textures will lead to massive application breakage. Making idle assumptions of the kind of "oh that'll be alright, somewhere it was undefined and therefore not much will break if we break it" are dangerous, irresponsible and contra-productive to WebGL. They're extremely contra productive because existing use will break, which is extremely frustrating to both users and developers of WebGL as they will have to address regressions that a browser introduced. This is one of the most destructive actions vendors can take, and they undermine the credibility of WebGL quite a lot. On Sat, Feb 21, 2015 at 10:40 AM, Mark Callow wrote: > > On Feb 21, 2015, at 6:33 PM, Mark Callow wrote: > > We should create a new extension, WEBGL_blend_float say, to allow full > blending to be exposed when running on desktop. > > > This extension could also be supported by WebGL 2 implementations when > exposing EXT_color_buffer_float on desktop-class hardware. > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Feb 21 23:13:20 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 08:13:20 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Sun, Feb 22, 2015 at 8:00 AM, Florian B?sch wrote: > As for the former, I don?t see how to search by supported extensions. >> Maybe you need to register to do that. >> > I did a crawler to do that. None of the devices on gfxbench.com list the > extension for any device they have in their database. > Ah, not quite correct. I can do some analysis on that a bit later. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sat Feb 21 23:35:50 2015 From: khr...@ (Mark Callow) Date: Sun, 22 Feb 2015 16:35:50 +0900 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: > On Feb 22, 2015, at 4:00 PM, Florian B?sch wrote: > > Wildfire games records every extension it sees. If it had encountered it, it'd be there. I don't have any machine on which ASTC extensions show up. > Ahh! I was misled by the fairly large number of extensions with 0% support. They are actually 0% after rounding. According to https://www.semiwiki.com/forum/content/3169-astc-new-midrange-arm-mali-t720-gpu.html ASTC is supported by the ARM Mali-T720, Tegra K1, PowerVR Series6XT and Adreno 420. The source of the information is not described. All these companies have announced that they will support ASTC and, as a cross-platform solution, it is very likely to quickly build momentum. Therefore it seems a good idea to prepare a WebGL extension spec. now rather than waiting until ASTC is already in a large number of end-user devices. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Sun Feb 22 00:03:41 2015 From: khr...@ (Mark Callow) Date: Sun, 22 Feb 2015 17:03:41 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: > On Feb 22, 2015, at 4:06 PM, Florian B?sch wrote: > > 2) Retrograding features such as blending on floating point textures will lead to massive application breakage. > > Making idle assumptions of the kind of "oh that'll be alright, somewhere it was undefined and therefore not much will break if we break it" are dangerous, irresponsible and contra-productive to WebGL. They're extremely contra productive because existing use will break, which is extremely frustrating to both users and developers of WebGL as they will have to address regressions that a browser introduced. This is one of the most destructive actions vendors can take, and they undermine the credibility of WebGL quite a lot. If any implementation is implicitly exposing fp32 rendering on OpenGL ES 3-class hardware then we have already broken the apps. Similarly if any implementation is exposing fp rendering on both > GL 4.2 and < GL 4.2 we have already broken the apps. Not sure where D3D sits with regards to the clamping. It would help to sort this mess out if we knew on what hardware classes implementations are implicitly exposing fp rendering and if some or all of that hardware is subject to the clear and blend color clamping problem and to not supporting blending for fp32 or fp16. The latter should only be a problem on D3D9. Both GL_EXT_color_buffer_half_float and GL_EXT_color_buffer_float support fp16 blending. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sun Feb 22 00:10:10 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 09:10:10 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: You shan't pour out the baby with the bath. Just because blendColor might be clamped, doesn't mean that blending doesn't work (or would be clamped). For instance, if you enable blending, and set it to addtive (ONE, ONE), you have an accumulator. If you render to that render target with a floating point texture, this will merrily add unclamped. blendColor doesn't feature in this equation at all. The two most popular blending modes (addtivie and alpha blending) don't consider blendColor. And even if you have an equation configured that does use the blendColor, the result will not be clamped, even though the users specification of the blendColor might be. On Sun, Feb 22, 2015 at 8:35 AM, Mark Callow wrote: > > On Feb 22, 2015, at 4:00 PM, Florian B?sch wrote: > > Wildfire games records every extension it sees. If it had encountered it, > it'd be there. I don't have any machine on which ASTC extensions show up. > > > Ahh! I was misled by the fairly large number of extensions with 0% > support. They are actually 0% after rounding. > > According to > https://www.semiwiki.com/forum/content/3169-astc-new-midrange-arm-mali-t720-gpu.html > ASTC is supported by the ARM Mali-T720, Tegra K1, PowerVR Series6XT and > Adreno 420. The source of the information is not described. All these > companies have announced that they will support ASTC and, as a > cross-platform solution, it is very likely to quickly build momentum. > Therefore it seems a good idea to prepare a WebGL extension spec. now > rather than waiting until ASTC is already in a large number of end-user > devices. > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 00:13:31 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 09:13:31 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: Wrong thread, sorry. On Sun, Feb 22, 2015 at 9:10 AM, Florian B?sch wrote: > You shan't pour out the baby with the bath. Just because blendColor might > be clamped, doesn't mean that blending doesn't work (or would be clamped). > > For instance, if you enable blending, and set it to addtive (ONE, ONE), > you have an accumulator. If you render to that render target with a > floating point texture, this will merrily add unclamped. blendColor doesn't > feature in this equation at all. The two most popular blending modes > (addtivie and alpha blending) don't consider blendColor. And even if you > have an equation configured that does use the blendColor, the result will > not be clamped, even though the users specification of the blendColor might > be. > > On Sun, Feb 22, 2015 at 8:35 AM, Mark Callow wrote: > >> >> On Feb 22, 2015, at 4:00 PM, Florian B?sch wrote: >> >> Wildfire games records every extension it sees. If it had encountered it, >> it'd be there. I don't have any machine on which ASTC extensions show up. >> >> >> Ahh! I was misled by the fairly large number of extensions with 0% >> support. They are actually 0% after rounding. >> >> According to >> https://www.semiwiki.com/forum/content/3169-astc-new-midrange-arm-mali-t720-gpu.html >> ASTC is supported by the ARM Mali-T720, Tegra K1, PowerVR Series6XT and >> Adreno 420. The source of the information is not described. All these >> companies have announced that they will support ASTC and, as a >> cross-platform solution, it is very likely to quickly build momentum. >> Therefore it seems a good idea to prepare a WebGL extension spec. now >> rather than waiting until ASTC is already in a large number of end-user >> devices. >> >> Regards >> >> -Mark >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 00:13:51 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 09:13:51 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: You shan't pour out the baby with the bath. Just because blendColor might be clamped, doesn't mean that blending doesn't work (or would be clamped). For instance, if you enable blending, and set it to addtive (ONE, ONE), you have an accumulator. If you render to that render target with a floating point texture, this will merrily add unclamped. blendColor doesn't feature in this equation at all. The two most popular blending modes (addtivie and alpha blending) don't consider blendColor. And even if you have an equation configured that does use the blendColor, the result will not be clamped, even though the users specification of the blendColor might be. On Sun, Feb 22, 2015 at 9:03 AM, Mark Callow wrote: > > On Feb 22, 2015, at 4:06 PM, Florian B?sch wrote: > > 2) Retrograding features such as blending on floating point textures will > lead to massive application breakage. > > Making idle assumptions of the kind of "oh that'll be alright, somewhere > it was undefined and therefore not much will break if we break it" are > dangerous, irresponsible and contra-productive to WebGL. They're extremely > contra productive because existing use will break, which is extremely > frustrating to both users and developers of WebGL as they will have to > address regressions that a browser introduced. This is one of the most > destructive actions vendors can take, and they undermine the credibility of > WebGL quite a lot. > > > If any implementation is implicitly exposing fp32 rendering on OpenGL ES > 3-class hardware then we have already broken the apps. Similarly if any > implementation is exposing fp rendering on both > GL 4.2 and < GL 4.2 we > have already broken the apps. Not sure where D3D sits with regards to the > clamping. > > It would help to sort this mess out if we knew on what hardware classes > implementations are implicitly exposing fp rendering and if some or all of > that hardware is subject to the clear and blend color clamping problem and > to not supporting blending for fp32 or fp16. The latter should only be a > problem on D3D9. Both GL_EXT_color_buffer_half_float and > GL_EXT_color_buffer_float support fp16 blending. > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Feb 22 00:27:09 2015 From: khr...@ (Mark Callow) Date: Sun, 22 Feb 2015 17:27:09 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: > On Feb 22, 2015, at 5:13 PM, Florian B?sch wrote: > > You shan't pour out the baby with the bath. Just because blendColor might be clamped, doesn't mean that blending doesn't work (or would be clamped). > > For instance, if you enable blending, and set it to addtive (ONE, ONE), you have an accumulator. If you render to that render target with a floating point texture, this will merrily add unclamped. blendColor doesn't feature in this equation at all. The two most popular blending modes (addtivie and alpha blending) don't consider blendColor. And even if you have an equation configured that does use the blendColor, the result will not be clamped, even though the users specification of the blendColor might be. > I know all this. What exactly is your point? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sun Feb 22 00:32:13 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 09:32:13 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: That you don't inflict massive breakage of a feature, which is happily in active use (and working too), because a tiny subset of its use is undefined. On Sun, Feb 22, 2015 at 9:27 AM, Mark Callow wrote: > > On Feb 22, 2015, at 5:13 PM, Florian B?sch wrote: > > You shan't pour out the baby with the bath. Just because blendColor might > be clamped, doesn't mean that blending doesn't work (or would be clamped). > > For instance, if you enable blending, and set it to addtive (ONE, ONE), > you have an accumulator. If you render to that render target with a > floating point texture, this will merrily add unclamped. blendColor doesn't > feature in this equation at all. The two most popular blending modes > (addtivie and alpha blending) don't consider blendColor. And even if you > have an equation configured that does use the blendColor, the result will > not be clamped, even though the users specification of the blendColor might > be. > > > I know all this. What exactly is your point? > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 00:33:23 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 09:33:23 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: To be more specific, YOU DO NOT BREAK BLENDING PERIOD! just because blendColor might be flakey. On Sun, Feb 22, 2015 at 9:32 AM, Florian B?sch wrote: > That you don't inflict massive breakage of a feature, which is happily in > active use (and working too), because a tiny subset of its use is > undefined. > > On Sun, Feb 22, 2015 at 9:27 AM, Mark Callow wrote: > >> >> On Feb 22, 2015, at 5:13 PM, Florian B?sch wrote: >> >> You shan't pour out the baby with the bath. Just because blendColor might >> be clamped, doesn't mean that blending doesn't work (or would be clamped). >> >> For instance, if you enable blending, and set it to addtive (ONE, ONE), >> you have an accumulator. If you render to that render target with a >> floating point texture, this will merrily add unclamped. blendColor doesn't >> feature in this equation at all. The two most popular blending modes >> (addtivie and alpha blending) don't consider blendColor. And even if you >> have an equation configured that does use the blendColor, the result will >> not be clamped, even though the users specification of the blendColor might >> be. >> >> >> I know all this. What exactly is your point? >> >> Regards >> >> -Mark >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Feb 22 00:44:09 2015 From: khr...@ (Mark Callow) Date: Sun, 22 Feb 2015 17:44:09 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> Message-ID: <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> > On Feb 22, 2015, at 5:33 PM, Florian B?sch wrote: > > To be more specific, YOU DO NOT BREAK BLENDING PERIOD! just because blendColor might be flakey. In this situation, > If any implementation is implicitly exposing fp32 rendering on OpenGL ES 3-class hardware ... fp32 blending is broken. Period. This class of hardware does not support it. The issue has nothing to do with blend color. And please stop shouting. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sun Feb 22 00:58:11 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 09:58:11 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: Just because fp32 might be inadvertedly exposed on some ES-3 hardware THAT IS NO FUCKING REASON TO BREAK FP BLENDING EVERY FUCKING WHERE, DO I MAKE MYSELF SUFFICIENTLY ABDUNDANTLY CRYSTAL FUCKING CLEAR? On Sun, Feb 22, 2015 at 9:44 AM, Mark Callow wrote: > > > On Feb 22, 2015, at 5:33 PM, Florian B?sch wrote: > > > > To be more specific, YOU DO NOT BREAK BLENDING PERIOD! just because > blendColor might be flakey. > > In this situation, > > > If any implementation is implicitly exposing fp32 rendering on OpenGL ES > 3-class hardware ... > > fp32 blending is broken. Period. This class of hardware does not support > it. The issue has nothing to do with blend color. And please stop shouting. > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 01:00:45 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 10:00:45 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: And if you wanna know why I'm shouting it's because a good number of my demos and professional work, as well as that of a great number of other people, will BREAK if you meddle around with FP blending. I will not abide that. On Sun, Feb 22, 2015 at 9:58 AM, Florian B?sch wrote: > Just because fp32 might be inadvertedly exposed on some ES-3 hardware THAT > IS NO FUCKING REASON TO BREAK FP BLENDING EVERY FUCKING WHERE, DO I MAKE > MYSELF SUFFICIENTLY ABDUNDANTLY CRYSTAL FUCKING CLEAR? > > On Sun, Feb 22, 2015 at 9:44 AM, Mark Callow wrote: > >> >> > On Feb 22, 2015, at 5:33 PM, Florian B?sch wrote: >> > >> > To be more specific, YOU DO NOT BREAK BLENDING PERIOD! just because >> blendColor might be flakey. >> >> In this situation, >> >> > If any implementation is implicitly exposing fp32 rendering on OpenGL >> ES 3-class hardware ... >> >> fp32 blending is broken. Period. This class of hardware does not support >> it. The issue has nothing to do with blend color. And please stop shouting. >> >> Regards >> >> -Mark >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 01:02:03 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 10:02:03 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: I have it just about UP HERE with WebGL constantly breaking and breaking and breaking and breaking FP support all the time. It's enough. You can make any suggestion to improve things, but those WILL NOT include breaking things that previously worked. On Sun, Feb 22, 2015 at 10:00 AM, Florian B?sch wrote: > And if you wanna know why I'm shouting it's because a good number of my > demos and professional work, as well as that of a great number of other > people, will BREAK if you meddle around with FP blending. I will not abide > that. > > On Sun, Feb 22, 2015 at 9:58 AM, Florian B?sch wrote: > >> Just because fp32 might be inadvertedly exposed on some ES-3 hardware >> THAT IS NO FUCKING REASON TO BREAK FP BLENDING EVERY FUCKING WHERE, DO I >> MAKE MYSELF SUFFICIENTLY ABDUNDANTLY CRYSTAL FUCKING CLEAR? >> >> On Sun, Feb 22, 2015 at 9:44 AM, Mark Callow wrote: >> >>> >>> > On Feb 22, 2015, at 5:33 PM, Florian B?sch wrote: >>> > >>> > To be more specific, YOU DO NOT BREAK BLENDING PERIOD! just because >>> blendColor might be flakey. >>> >>> In this situation, >>> >>> > If any implementation is implicitly exposing fp32 rendering on OpenGL >>> ES 3-class hardware ... >>> >>> fp32 blending is broken. Period. This class of hardware does not support >>> it. The issue has nothing to do with blend color. And please stop shouting. >>> >>> Regards >>> >>> -Mark >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 01:12:35 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 10:12:35 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: If you go around and make suggestions that will land me in hot water with half my clients from the past 4 years, and will force me to take down 3-4 of the most popular WebGL demos of mine (demos to which I've been repatedly told they're the reason people got into WebGL in the first place), you will have to expect a lot of vitriolic unpleasantness from me. On Sun, Feb 22, 2015 at 10:02 AM, Florian B?sch wrote: > I have it just about UP HERE with WebGL constantly breaking and breaking > and breaking and breaking FP support all the time. It's enough. You can > make any suggestion to improve things, but those WILL NOT include breaking > things that previously worked. > > On Sun, Feb 22, 2015 at 10:00 AM, Florian B?sch wrote: > >> And if you wanna know why I'm shouting it's because a good number of my >> demos and professional work, as well as that of a great number of other >> people, will BREAK if you meddle around with FP blending. I will not abide >> that. >> >> On Sun, Feb 22, 2015 at 9:58 AM, Florian B?sch wrote: >> >>> Just because fp32 might be inadvertedly exposed on some ES-3 hardware >>> THAT IS NO FUCKING REASON TO BREAK FP BLENDING EVERY FUCKING WHERE, DO I >>> MAKE MYSELF SUFFICIENTLY ABDUNDANTLY CRYSTAL FUCKING CLEAR? >>> >>> On Sun, Feb 22, 2015 at 9:44 AM, Mark Callow wrote: >>> >>>> >>>> > On Feb 22, 2015, at 5:33 PM, Florian B?sch wrote: >>>> > >>>> > To be more specific, YOU DO NOT BREAK BLENDING PERIOD! just because >>>> blendColor might be flakey. >>>> >>>> In this situation, >>>> >>>> > If any implementation is implicitly exposing fp32 rendering on OpenGL >>>> ES 3-class hardware ... >>>> >>>> fp32 blending is broken. Period. This class of hardware does not >>>> support it. The issue has nothing to do with blend color. And please stop >>>> shouting. >>>> >>>> Regards >>>> >>>> -Mark >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 01:48:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 10:48:33 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: OES_texture_compression_astc is supported by these 46 devices. 10moons D8 Plus 10moons D9 Acer S56 Liquid Jade S Alps k2v1 (development board) Coolpad 8297 (Mali-T760) Cube Technology T7 Cube Technology T9 Elephone P6000 Five Technology ifive Air Five Technology ifive mini 4 Gionee S3 HTC Desire 820 (Mali-T760, D820) Hardkernel ODROID-XU3 (development board) Hisense F5281 Vidaa Pad Huawei H60 Honor 6 Huawei Honor PE-UL00 (PE-TL10) Huawei MT7 Huawei Z100 InFocus M550 3D Jiayu JY-S3 Leadcore L1860 Lenovo P70 Lenovo P70-A MStar Android TV (Mali-T760) Meizu MX4 Pro Meizu k52 Meizu m1 note Oplus Evo 4G Oppo U3 Pipo P1 Pipo P4 Pipo P7 Pipo P9 Pipo P9 3G Rockchip rk3288 (development board) Samsung Galaxy Alpha (Mali-T628, SM-G850) Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) Samsung Galaxy Note Edge (Mali-T760, SM-N915x) Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) Samsung SM-G900x Galaxy S5 (Mali-T628) TCL 5042T TCL M2M TCL i718M Teclast P90HD Teclast T98 4G (C6R2) KHR_texture_compression_astc_hdr is supported by these 46 devices. 10moons D8 Plus 10moons D9 Acer S56 Liquid Jade S Alps k2v1 (development board) Coolpad 8297 (Mali-T760) Cube Technology T7 Cube Technology T9 Elephone P6000 Five Technology ifive Air Five Technology ifive mini 4 Gionee S3 HTC Desire 820 (Mali-T760, D820) Hardkernel ODROID-XU3 (development board) Hisense F5281 Vidaa Pad Huawei H60 Honor 6 Huawei Honor PE-UL00 (PE-TL10) Huawei MT7 Huawei Z100 InFocus M550 3D Jiayu JY-S3 Leadcore L1860 Lenovo P70 Lenovo P70-A MStar Android TV (Mali-T760) Meizu MX4 Pro Meizu k52 Meizu m1 note Oplus Evo 4G Oppo U3 Pipo P1 Pipo P4 Pipo P7 Pipo P9 Pipo P9 3G Rockchip rk3288 (development board) Samsung Galaxy Alpha (Mali-T628, SM-G850) Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) Samsung Galaxy Note Edge (Mali-T760, SM-N915x) Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) Samsung SM-G900x Galaxy S5 (Mali-T628) TCL 5042T TCL M2M TCL i718M Teclast P90HD Teclast T98 4G (C6R2) KHR_texture_compression_astc_hdr is supported by these 133 devices. 10moons D8 Plus 10moons D9 Acer S56 Liquid Jade S Alcatel 5042 One Touch Pop 2 (4.5) Alcatel A846L Alps k2v1 (development board) Amazon Kindle Fire HDX 8.9 (4th Gen, KFSAWA, KFSAWI) Apple iPad Air 2 Apple iPhone 6 Apple iPhone 6 Plus Archos 50 Diamond (K-Touch Touch 7) Bouygues Telecom Ultym 5L Coolpad 8297 (Mali-T760) Coolpad 8297-T01 (Adreno 306) Coolpad 8675-W00 (Adreno 205) Coolpad 8675-W00 (Adreno 405) Coolpad K1-NT Cube Technology T7 Cube Technology T9 Elephone P6000 Five Technology ifive Air Five Technology ifive mini 4 Gionee S3 Google Nexus 6 Google Nexus 9 Google Project Tango HTC D820mu (Adreno 306) HTC Desire 510 (Adreno 306) HTC Desire 820 (Adreno 405, D820) HTC Desire 820 (Mali-T760, D820) HTC Desire 820q Hardkernel ODROID-XU3 (development board) Hasee Q501 Hisense F5281 Vidaa Pad Huawei Ascend G7 Huawei H60 Honor 6 Huawei Honor 4X (Che1-CL20) Huawei Honor PE-UL00 (PE-TL10) Huawei MT7 Huawei MediaPad T1 8.0 LTE (Adreno 306) Huawei MediaPad T1 8.0 Pro Huawei Y550 Huawei Z100 InFocus M550 3D Intel(R) CherryView HD Graphics Jiayu JY-S3 LG F60 D390 LG G3 (Adreno 420, F460) Leadcore L1860 Lenovo K1 HD (2014) Lenovo K30 Lenovo P70 Lenovo P70-A Lenovo S90 Lenovo ThinkVision 28 Lenovo Z2 Vibe MStar Android TV (Mali-T760) Meizu MX4 Pro Meizu k52 Meizu m1 note Motorola Droid Turbo XT1254, Moto Maxx XT1225 NVIDIA Shield tablet NVIDIA Tegra GK20A (ardbeg, development board) NVIDIA Tegra Note 8 NVIDIA Tegra X1 Reference Platform (development board) Oplus Evo 4G Oppo R5 (R8106, R8107) Oppo R8207 Oppo U3 Panasonic Eluga U2 Pantech IM-A930 Vega Pipo P1 Pipo P4 Pipo P7 Pipo P9 Pipo P9 3G Prestigio PSP5454DUO MultiPhone 5454 DUO Qualcomm MSM8994 for arm64 (Adreno 430, development board) Qualcomm apq8084 (Adreno 420, development board) Qualcomm apq8084 (Adreno 420, development board) Rockchip rk3288 (development board) Samsung Galaxy A3 (SM-A300x) Samsung Galaxy A7 (SM-A700x) Samsung Galaxy Alpha (Mali-T628, SM-G850) Samsung Galaxy Core Max (SM-G510F, SM-G5108Q, SM-G5109) Samsung Galaxy Core Prime (Adreno 306, SM-G360) Samsung Galaxy E5 (SM-E500) Samsung Galaxy Grand 3 (SM-G7200, SM-G7202) Samsung Galaxy K zoom (SM-C111, SM-C115x) Samsung Galaxy Mega 2 (SM-G7508Q, SM-G7509) Samsung Galaxy Note 10.1 (SM-P600, SM-P601, SM-P602) Samsung Galaxy Note 3 Neo (Mali-T624, SM-N750, SM-N7500, SM-N7505, SM-N7507) Samsung Galaxy Note 4 (Adreno 420, SM-N910x) Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) Samsung Galaxy Note Edge (Adreno 420, SM-N915x, SCL24, SC-01G) Samsung Galaxy Note Edge (Mali-T760, SM-N915x) Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) Samsung Galaxy Note Pro 12.2 (SM-P900, SM-P901, SM-P902) Samsung Galaxy S5 (Adreno 420, SM-G901) Samsung Galaxy Tab 4 8.0 (Adreno 306, SM-T333) Samsung Galaxy Tab S 10.5 (Mali-T628, SM-T807) Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) Samsung Galaxy Tab S 10.5 (SM-T800, SM-T801, SM-T805) Samsung Galaxy Tab S 8.4 (Mali-T628, SM-T707A) Samsung Galaxy Tab S 8.4 (SM-T700, SM-T705) Samsung SM-A500x Samsung SM-E7000 Galaxy E7 Samsung SM-G357FZ Samsung SM-G530x Samsung SM-G750H Samsung SM-G900x Galaxy S5 (Mali-T628) Samsung SM-G906 Galaxy S5 Prime Samsung SM-G910F (Mali-T624) Samsung SM-N910x (Mali-T624) Samsung SM-S820L Samsung SM-T520 Galaxy Tab 10.1 Samsung SM-T900 Galaxy Tab Pro 12.2 TCL 5042T TCL M2M TCL i718M Teclast P90HD Teclast T98 4G (C6R2) Verykool SL4500 Vivo X5Max L Vivo Y27 Vodafone Smart Tab 4G XOLO LT2000 Xiaomi MiPad Xiaomi Redmi 2 (Adreno 306, 2014xxx) ZTE A880 ZTE N958St ZTE V5S N918St bq Aquaris E5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 01:50:32 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 10:50:32 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: On Sun, Feb 22, 2015 at 8:35 AM, Mark Callow wrote: > Therefore it seems a good idea to prepare a WebGL extension spec. now > rather than waiting until ASTC is already in a large number of end-user > devices. > I'm fine with that, but it does mean that future extension proposals cannot be measured against the support levels in hardware/drivers anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 01:51:58 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 10:51:58 +0100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: Typo in last device list bottom listing should be ldr, not hdr. On Sun, Feb 22, 2015 at 10:48 AM, Florian B?sch wrote: > OES_texture_compression_astc is supported by these 46 devices. > > 10moons D8 Plus > 10moons D9 > Acer S56 Liquid Jade S > Alps k2v1 (development board) > Coolpad 8297 (Mali-T760) > Cube Technology T7 > Cube Technology T9 > Elephone P6000 > Five Technology ifive Air > Five Technology ifive mini 4 > Gionee S3 > HTC Desire 820 (Mali-T760, D820) > Hardkernel ODROID-XU3 (development board) > Hisense F5281 Vidaa Pad > Huawei H60 Honor 6 > Huawei Honor PE-UL00 (PE-TL10) > Huawei MT7 > Huawei Z100 > InFocus M550 3D > Jiayu JY-S3 > Leadcore L1860 > Lenovo P70 > Lenovo P70-A > MStar Android TV (Mali-T760) > Meizu MX4 Pro > Meizu k52 > Meizu m1 note > Oplus Evo 4G > Oppo U3 > Pipo P1 > Pipo P4 > Pipo P7 > Pipo P9 > Pipo P9 3G > Rockchip rk3288 (development board) > Samsung Galaxy Alpha (Mali-T628, SM-G850) > Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) > Samsung Galaxy Note Edge (Mali-T760, SM-N915x) > Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) > Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) > Samsung SM-G900x Galaxy S5 (Mali-T628) > TCL 5042T > TCL M2M > TCL i718M > Teclast P90HD > Teclast T98 4G (C6R2) > > > KHR_texture_compression_astc_hdr is supported by these 46 devices. > > 10moons D8 Plus > 10moons D9 > Acer S56 Liquid Jade S > Alps k2v1 (development board) > Coolpad 8297 (Mali-T760) > Cube Technology T7 > Cube Technology T9 > Elephone P6000 > Five Technology ifive Air > Five Technology ifive mini 4 > Gionee S3 > HTC Desire 820 (Mali-T760, D820) > Hardkernel ODROID-XU3 (development board) > Hisense F5281 Vidaa Pad > Huawei H60 Honor 6 > Huawei Honor PE-UL00 (PE-TL10) > Huawei MT7 > Huawei Z100 > InFocus M550 3D > Jiayu JY-S3 > Leadcore L1860 > Lenovo P70 > Lenovo P70-A > MStar Android TV (Mali-T760) > Meizu MX4 Pro > Meizu k52 > Meizu m1 note > Oplus Evo 4G > Oppo U3 > Pipo P1 > Pipo P4 > Pipo P7 > Pipo P9 > Pipo P9 3G > Rockchip rk3288 (development board) > Samsung Galaxy Alpha (Mali-T628, SM-G850) > Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) > Samsung Galaxy Note Edge (Mali-T760, SM-N915x) > Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) > Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) > Samsung SM-G900x Galaxy S5 (Mali-T628) > TCL 5042T > TCL M2M > TCL i718M > Teclast P90HD > Teclast T98 4G (C6R2) > > > KHR_texture_compression_astc_hdr is supported by these 133 devices. > > 10moons D8 Plus > 10moons D9 > Acer S56 Liquid Jade S > Alcatel 5042 One Touch Pop 2 (4.5) > Alcatel A846L > Alps k2v1 (development board) > Amazon Kindle Fire HDX 8.9 (4th Gen, KFSAWA, KFSAWI) > Apple iPad Air 2 > Apple iPhone 6 > Apple iPhone 6 Plus > Archos 50 Diamond (K-Touch Touch 7) > Bouygues Telecom Ultym 5L > Coolpad 8297 (Mali-T760) > Coolpad 8297-T01 (Adreno 306) > Coolpad 8675-W00 (Adreno 205) > Coolpad 8675-W00 (Adreno 405) > Coolpad K1-NT > Cube Technology T7 > Cube Technology T9 > Elephone P6000 > Five Technology ifive Air > Five Technology ifive mini 4 > Gionee S3 > Google Nexus 6 > Google Nexus 9 > Google Project Tango > HTC D820mu (Adreno 306) > HTC Desire 510 (Adreno 306) > HTC Desire 820 (Adreno 405, D820) > HTC Desire 820 (Mali-T760, D820) > HTC Desire 820q > Hardkernel ODROID-XU3 (development board) > Hasee Q501 > Hisense F5281 Vidaa Pad > Huawei Ascend G7 > Huawei H60 Honor 6 > Huawei Honor 4X (Che1-CL20) > Huawei Honor PE-UL00 (PE-TL10) > Huawei MT7 > Huawei MediaPad T1 8.0 LTE (Adreno 306) > Huawei MediaPad T1 8.0 Pro > Huawei Y550 > Huawei Z100 > InFocus M550 3D > Intel(R) CherryView HD Graphics > Jiayu JY-S3 > LG F60 D390 > LG G3 (Adreno 420, F460) > Leadcore L1860 > Lenovo K1 HD (2014) > Lenovo K30 > Lenovo P70 > Lenovo P70-A > Lenovo S90 > Lenovo ThinkVision 28 > Lenovo Z2 Vibe > MStar Android TV (Mali-T760) > Meizu MX4 Pro > Meizu k52 > Meizu m1 note > Motorola Droid Turbo XT1254, Moto Maxx XT1225 > NVIDIA Shield tablet > NVIDIA Tegra GK20A (ardbeg, development board) > NVIDIA Tegra Note 8 > NVIDIA Tegra X1 Reference Platform (development board) > Oplus Evo 4G > Oppo R5 (R8106, R8107) > Oppo R8207 > Oppo U3 > Panasonic Eluga U2 > Pantech IM-A930 Vega > Pipo P1 > Pipo P4 > Pipo P7 > Pipo P9 > Pipo P9 3G > Prestigio PSP5454DUO MultiPhone 5454 DUO > Qualcomm MSM8994 for arm64 (Adreno 430, development board) > Qualcomm apq8084 (Adreno 420, development board) > Qualcomm apq8084 (Adreno 420, development board) > Rockchip rk3288 (development board) > Samsung Galaxy A3 (SM-A300x) > Samsung Galaxy A7 (SM-A700x) > Samsung Galaxy Alpha (Mali-T628, SM-G850) > Samsung Galaxy Core Max (SM-G510F, SM-G5108Q, SM-G5109) > Samsung Galaxy Core Prime (Adreno 306, SM-G360) > Samsung Galaxy E5 (SM-E500) > Samsung Galaxy Grand 3 (SM-G7200, SM-G7202) > Samsung Galaxy K zoom (SM-C111, SM-C115x) > Samsung Galaxy Mega 2 (SM-G7508Q, SM-G7509) > Samsung Galaxy Note 10.1 (SM-P600, SM-P601, SM-P602) > Samsung Galaxy Note 3 Neo (Mali-T624, SM-N750, SM-N7500, SM-N7505, > SM-N7507) > Samsung Galaxy Note 4 (Adreno 420, SM-N910x) > Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) > Samsung Galaxy Note Edge (Adreno 420, SM-N915x, SCL24, SC-01G) > Samsung Galaxy Note Edge (Mali-T760, SM-N915x) > Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) > Samsung Galaxy Note Pro 12.2 (SM-P900, SM-P901, SM-P902) > Samsung Galaxy S5 (Adreno 420, SM-G901) > Samsung Galaxy Tab 4 8.0 (Adreno 306, SM-T333) > Samsung Galaxy Tab S 10.5 (Mali-T628, SM-T807) > Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) > Samsung Galaxy Tab S 10.5 (SM-T800, SM-T801, SM-T805) > Samsung Galaxy Tab S 8.4 (Mali-T628, SM-T707A) > Samsung Galaxy Tab S 8.4 (SM-T700, SM-T705) > Samsung SM-A500x > Samsung SM-E7000 Galaxy E7 > Samsung SM-G357FZ > Samsung SM-G530x > Samsung SM-G750H > Samsung SM-G900x Galaxy S5 (Mali-T628) > Samsung SM-G906 Galaxy S5 Prime > Samsung SM-G910F (Mali-T624) > Samsung SM-N910x (Mali-T624) > Samsung SM-S820L > Samsung SM-T520 Galaxy Tab 10.1 > Samsung SM-T900 Galaxy Tab Pro 12.2 > TCL 5042T > TCL M2M > TCL i718M > Teclast P90HD > Teclast T98 4G (C6R2) > Verykool SL4500 > Vivo X5Max L > Vivo Y27 > Vodafone Smart Tab 4G > XOLO LT2000 > Xiaomi MiPad > Xiaomi Redmi 2 (Adreno 306, 2014xxx) > ZTE A880 > ZTE N958St > ZTE V5S N918St > bq Aquaris E5 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Feb 22 02:06:00 2015 From: khr...@ (Mark Callow) Date: Sun, 22 Feb 2015 19:06:00 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: <78A2F6FD-7B38-4F5B-B6D0-BE3515EFE904@callow.im> > On Feb 22, 2015, at 5:44 PM, Mark Callow wrote: > > In this situation, > >> If any implementation is implicitly exposing fp32 rendering on OpenGL ES 3-class hardware ... > > fp32 blending is broken. Period. This class of hardware does not support it. The issue has nothing to do with blend color. And please stop shouting. Likewise, in fp32 rendering exposed onD3D9, blending will not work. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sun Feb 22 02:09:46 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 11:09:46 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: <78A2F6FD-7B38-4F5B-B6D0-BE3515EFE904@callow.im> References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> <78A2F6FD-7B38-4F5B-B6D0-BE3515EFE904@callow.im> Message-ID: On Sun, Feb 22, 2015 at 11:06 AM, Mark Callow wrote: > Likewise, in fp32 rendering exposed onD3D9, blending will not work. > It doesn't matter where it doesn't work. What matters is that you're plotting to intentionally make it not work everywhere. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Feb 22 02:23:12 2015 From: khr...@ (Mark Callow) Date: Sun, 22 Feb 2015 19:23:12 +0900 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: > On Feb 22, 2015, at 6:12 PM, Florian B?sch wrote: > > If you go around and make suggestions that will land me in hot water with half my clients from the past 4 years, and will force me to take down 3-4 of the most popular WebGL demos of mine (demos to which I've been repatedly told they're the reason people got into WebGL in the first place), you will have to expect a lot of vitriolic unpleasantness from me. > Instead of screaming at us, how about making some constructive suggestions to fix the problems. all you have done is complain about all the suggestions made so far. As it stands, applications have no way to tell if blending will work or not, in the case when fp32 is implicitly enabled, as I don?t believe there is any conformance test that determines if the implementation follows WEBGL_color_buffer_float. As WEBGL_color_buffer_float is not currently widely supported I suspect there aren?t many apps explicitly trying to enable it. Do your apps try to do so? Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Sun Feb 22 10:03:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 19:03:21 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: On Sun, Feb 22, 2015 at 11:23 AM, Mark Callow wrote: > Instead of screaming at us, how about making some constructive suggestions > to fix the problems. all you have done is complain about all the > suggestions made so far. > I did, I suggested not disabling things that worked before (thank you very much float_linear was quite bad enough), and capturing the aspects of what works with which formats in a single extension and not a myriad of new ones. > As it stands, applications have no way to tell if blending will work or > not, You can tell, but it requires running a test up-front. Quite the same actually as figuring out if float luminance will work. > in the case when fp32 is implicitly enabled, as I don?t believe there is > any conformance test that determines if the implementation follows > WEBGL_color_buffer_float. As WEBGL_color_buffer_float is not currently > widely supported I suspect there aren?t many apps explicitly trying to > enable it. Do your apps try to do so? > WEBGL_color_buffer_float isn't implemented anyway so far, so there's no point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 22 10:05:03 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 22 Feb 2015 19:05:03 +0100 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: On Sun, Feb 22, 2015 at 7:03 PM, Florian B?sch wrote: > As it stands, applications have no way to tell if blending will work or >> not, > > You can tell, but it requires running a test up-front. Quite the same > actually as figuring out if float luminance will work. > My, let's call it "WEBGL_float_all" extension proposal aims at people not being required to run a mini floating point conformance test up front on every pageload in order to determine which renderpath to take (yes, I do that too, meanwhile). -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Feb 23 11:57:33 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 23 Feb 2015 11:57:33 -0800 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: Thanks for assembling the list of supported devices Florian. That's a considerable number of devices even if their market share doesn't appear large. Let's proceed with creating a WebGL extension proposal for ASTC texture compression. It has a good chance of being a universally supported and high quality compressed texture format. Christophe, could you help with the extension proposal? Even if you can only help with the math that computes the data sizes, I'd be happy to fill in the rest. Thanks. -Ken On Sun, Feb 22, 2015 at 1:51 AM, Florian B?sch wrote: > Typo in last device list bottom listing should be ldr, not hdr. > > On Sun, Feb 22, 2015 at 10:48 AM, Florian B?sch wrote: >> >> OES_texture_compression_astc is supported by these 46 devices. >> >> 10moons D8 Plus >> 10moons D9 >> Acer S56 Liquid Jade S >> Alps k2v1 (development board) >> Coolpad 8297 (Mali-T760) >> Cube Technology T7 >> Cube Technology T9 >> Elephone P6000 >> Five Technology ifive Air >> Five Technology ifive mini 4 >> Gionee S3 >> HTC Desire 820 (Mali-T760, D820) >> Hardkernel ODROID-XU3 (development board) >> Hisense F5281 Vidaa Pad >> Huawei H60 Honor 6 >> Huawei Honor PE-UL00 (PE-TL10) >> Huawei MT7 >> Huawei Z100 >> InFocus M550 3D >> Jiayu JY-S3 >> Leadcore L1860 >> Lenovo P70 >> Lenovo P70-A >> MStar Android TV (Mali-T760) >> Meizu MX4 Pro >> Meizu k52 >> Meizu m1 note >> Oplus Evo 4G >> Oppo U3 >> Pipo P1 >> Pipo P4 >> Pipo P7 >> Pipo P9 >> Pipo P9 3G >> Rockchip rk3288 (development board) >> Samsung Galaxy Alpha (Mali-T628, SM-G850) >> Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) >> Samsung Galaxy Note Edge (Mali-T760, SM-N915x) >> Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) >> Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) >> Samsung SM-G900x Galaxy S5 (Mali-T628) >> TCL 5042T >> TCL M2M >> TCL i718M >> Teclast P90HD >> Teclast T98 4G (C6R2) >> >> >> KHR_texture_compression_astc_hdr is supported by these 46 devices. >> >> 10moons D8 Plus >> 10moons D9 >> Acer S56 Liquid Jade S >> Alps k2v1 (development board) >> Coolpad 8297 (Mali-T760) >> Cube Technology T7 >> Cube Technology T9 >> Elephone P6000 >> Five Technology ifive Air >> Five Technology ifive mini 4 >> Gionee S3 >> HTC Desire 820 (Mali-T760, D820) >> Hardkernel ODROID-XU3 (development board) >> Hisense F5281 Vidaa Pad >> Huawei H60 Honor 6 >> Huawei Honor PE-UL00 (PE-TL10) >> Huawei MT7 >> Huawei Z100 >> InFocus M550 3D >> Jiayu JY-S3 >> Leadcore L1860 >> Lenovo P70 >> Lenovo P70-A >> MStar Android TV (Mali-T760) >> Meizu MX4 Pro >> Meizu k52 >> Meizu m1 note >> Oplus Evo 4G >> Oppo U3 >> Pipo P1 >> Pipo P4 >> Pipo P7 >> Pipo P9 >> Pipo P9 3G >> Rockchip rk3288 (development board) >> Samsung Galaxy Alpha (Mali-T628, SM-G850) >> Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) >> Samsung Galaxy Note Edge (Mali-T760, SM-N915x) >> Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) >> Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) >> Samsung SM-G900x Galaxy S5 (Mali-T628) >> TCL 5042T >> TCL M2M >> TCL i718M >> Teclast P90HD >> Teclast T98 4G (C6R2) >> >> >> KHR_texture_compression_astc_hdr is supported by these 133 devices. >> >> 10moons D8 Plus >> 10moons D9 >> Acer S56 Liquid Jade S >> Alcatel 5042 One Touch Pop 2 (4.5) >> Alcatel A846L >> Alps k2v1 (development board) >> Amazon Kindle Fire HDX 8.9 (4th Gen, KFSAWA, KFSAWI) >> Apple iPad Air 2 >> Apple iPhone 6 >> Apple iPhone 6 Plus >> Archos 50 Diamond (K-Touch Touch 7) >> Bouygues Telecom Ultym 5L >> Coolpad 8297 (Mali-T760) >> Coolpad 8297-T01 (Adreno 306) >> Coolpad 8675-W00 (Adreno 205) >> Coolpad 8675-W00 (Adreno 405) >> Coolpad K1-NT >> Cube Technology T7 >> Cube Technology T9 >> Elephone P6000 >> Five Technology ifive Air >> Five Technology ifive mini 4 >> Gionee S3 >> Google Nexus 6 >> Google Nexus 9 >> Google Project Tango >> HTC D820mu (Adreno 306) >> HTC Desire 510 (Adreno 306) >> HTC Desire 820 (Adreno 405, D820) >> HTC Desire 820 (Mali-T760, D820) >> HTC Desire 820q >> Hardkernel ODROID-XU3 (development board) >> Hasee Q501 >> Hisense F5281 Vidaa Pad >> Huawei Ascend G7 >> Huawei H60 Honor 6 >> Huawei Honor 4X (Che1-CL20) >> Huawei Honor PE-UL00 (PE-TL10) >> Huawei MT7 >> Huawei MediaPad T1 8.0 LTE (Adreno 306) >> Huawei MediaPad T1 8.0 Pro >> Huawei Y550 >> Huawei Z100 >> InFocus M550 3D >> Intel(R) CherryView HD Graphics >> Jiayu JY-S3 >> LG F60 D390 >> LG G3 (Adreno 420, F460) >> Leadcore L1860 >> Lenovo K1 HD (2014) >> Lenovo K30 >> Lenovo P70 >> Lenovo P70-A >> Lenovo S90 >> Lenovo ThinkVision 28 >> Lenovo Z2 Vibe >> MStar Android TV (Mali-T760) >> Meizu MX4 Pro >> Meizu k52 >> Meizu m1 note >> Motorola Droid Turbo XT1254, Moto Maxx XT1225 >> NVIDIA Shield tablet >> NVIDIA Tegra GK20A (ardbeg, development board) >> NVIDIA Tegra Note 8 >> NVIDIA Tegra X1 Reference Platform (development board) >> Oplus Evo 4G >> Oppo R5 (R8106, R8107) >> Oppo R8207 >> Oppo U3 >> Panasonic Eluga U2 >> Pantech IM-A930 Vega >> Pipo P1 >> Pipo P4 >> Pipo P7 >> Pipo P9 >> Pipo P9 3G >> Prestigio PSP5454DUO MultiPhone 5454 DUO >> Qualcomm MSM8994 for arm64 (Adreno 430, development board) >> Qualcomm apq8084 (Adreno 420, development board) >> Qualcomm apq8084 (Adreno 420, development board) >> Rockchip rk3288 (development board) >> Samsung Galaxy A3 (SM-A300x) >> Samsung Galaxy A7 (SM-A700x) >> Samsung Galaxy Alpha (Mali-T628, SM-G850) >> Samsung Galaxy Core Max (SM-G510F, SM-G5108Q, SM-G5109) >> Samsung Galaxy Core Prime (Adreno 306, SM-G360) >> Samsung Galaxy E5 (SM-E500) >> Samsung Galaxy Grand 3 (SM-G7200, SM-G7202) >> Samsung Galaxy K zoom (SM-C111, SM-C115x) >> Samsung Galaxy Mega 2 (SM-G7508Q, SM-G7509) >> Samsung Galaxy Note 10.1 (SM-P600, SM-P601, SM-P602) >> Samsung Galaxy Note 3 Neo (Mali-T624, SM-N750, SM-N7500, SM-N7505, >> SM-N7507) >> Samsung Galaxy Note 4 (Adreno 420, SM-N910x) >> Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) >> Samsung Galaxy Note Edge (Adreno 420, SM-N915x, SCL24, SC-01G) >> Samsung Galaxy Note Edge (Mali-T760, SM-N915x) >> Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) >> Samsung Galaxy Note Pro 12.2 (SM-P900, SM-P901, SM-P902) >> Samsung Galaxy S5 (Adreno 420, SM-G901) >> Samsung Galaxy Tab 4 8.0 (Adreno 306, SM-T333) >> Samsung Galaxy Tab S 10.5 (Mali-T628, SM-T807) >> Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) >> Samsung Galaxy Tab S 10.5 (SM-T800, SM-T801, SM-T805) >> Samsung Galaxy Tab S 8.4 (Mali-T628, SM-T707A) >> Samsung Galaxy Tab S 8.4 (SM-T700, SM-T705) >> Samsung SM-A500x >> Samsung SM-E7000 Galaxy E7 >> Samsung SM-G357FZ >> Samsung SM-G530x >> Samsung SM-G750H >> Samsung SM-G900x Galaxy S5 (Mali-T628) >> Samsung SM-G906 Galaxy S5 Prime >> Samsung SM-G910F (Mali-T624) >> Samsung SM-N910x (Mali-T624) >> Samsung SM-S820L >> Samsung SM-T520 Galaxy Tab 10.1 >> Samsung SM-T900 Galaxy Tab Pro 12.2 >> TCL 5042T >> TCL M2M >> TCL i718M >> Teclast P90HD >> Teclast T98 4G (C6R2) >> Verykool SL4500 >> Vivo X5Max L >> Vivo Y27 >> Vodafone Smart Tab 4G >> XOLO LT2000 >> Xiaomi MiPad >> Xiaomi Redmi 2 (Adreno 306, 2014xxx) >> ZTE A880 >> ZTE N958St >> ZTE V5S N918St >> bq Aquaris E5 > > ----------------------------------------------------------- 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...@ Mon Feb 23 13:17:17 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 23 Feb 2015 13:17:17 -0800 Subject: [Public WebGL] Proposal for WEBGL_render_to_float In-Reply-To: References: <43627D26-AE62-4983-B82A-E8854544C183@callow.im> <16DF6847-6CE5-41A5-8D1E-FDCBA9E59E70@callow.im> <10C7A66C-D88C-47E6-9C06-8F0E21BCABF6@callow.im> Message-ID: Regarding modifications to the existing EXT_color_buffer_half_float [1], WEBGL_color_buffer_float [2] and EXT_color_buffer_float extensions [3]: The WebGL WG is still investigating the root of the text in the GLES extension [4] forbidding blending of FP32 color buffers, and which OpenGL ES 3.0 hardware may actually support this. I think losing the ability to blend FP32 color buffers would be a significant regression in functionality, and adding a getInteger query to [2] and [3] sounds like a reasonable way to advertise this capability. There are definitely too many extensions around floating-point textures right now and I'd like to avoid adding yet another one just for controlling FP32 blending. Regarding Jeff's WEBGL_render_to_float proposal [5], the working group is in agreement that it's too restrictive and that we'll collectively work on moving extensions [1], [2] and [3] instead. -Ken [1] https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_half_float/ [2] https://www.khronos.org/registry/webgl/extensions/WEBGL_color_buffer_float/ [3] https://www.khronos.org/registry/webgl/extensions/EXT_color_buffer_float/ [4] https://www.khronos.org/registry/gles/extensions/EXT/EXT_color_buffer_float.txt [5] https://github.com/KhronosGroup/WebGL/pull/867 On Sun, Feb 22, 2015 at 10:05 AM, Florian B?sch wrote: > On Sun, Feb 22, 2015 at 7:03 PM, Florian B?sch wrote: >>> >>> As it stands, applications have no way to tell if blending will work or >>> not, >> >> You can tell, but it requires running a test up-front. Quite the same >> actually as figuring out if float luminance will work. > > My, let's call it "WEBGL_float_all" extension proposal aims at people not > being required to run a mini floating point conformance test up front on > every pageload in order to determine which renderpath to take (yes, I do > that too, meanwhile). ----------------------------------------------------------- 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...@ Mon Feb 23 13:56:02 2015 From: din...@ (Dean Jackson) Date: Tue, 24 Feb 2015 08:56:02 +1100 Subject: [Public WebGL] Proposal to move WEBGL_compressed_texture_es3 to Draft In-Reply-To: References: <308570674.5295755.1390945353996.JavaMail.zimbra@mozilla.com> <396684089.5297551.1390946211124.JavaMail.zimbra@mozilla.com> Message-ID: > On 24 Feb 2015, at 6:57 am, Kenneth Russell wrote: > > > Thanks for assembling the list of supported devices Florian. That's a > considerable number of devices even if their market share doesn't > appear large. Let's proceed with creating a WebGL extension proposal > for ASTC texture compression. It has a good chance of being a > universally supported and high quality compressed texture format. > Christophe, could you help with the extension proposal? Even if you > can only help with the math that computes the data sizes, I'd be happy > to fill in the rest. Thanks. Agreed. We'd probably enable the extension ASAP on our hardware with ASTC support (iPhone 6, 6+ and iPad Air 2). Dean > > -Ken > > > On Sun, Feb 22, 2015 at 1:51 AM, Florian B?sch wrote: >> Typo in last device list bottom listing should be ldr, not hdr. >> >> On Sun, Feb 22, 2015 at 10:48 AM, Florian B?sch wrote: >>> >>> OES_texture_compression_astc is supported by these 46 devices. >>> >>> 10moons D8 Plus >>> 10moons D9 >>> Acer S56 Liquid Jade S >>> Alps k2v1 (development board) >>> Coolpad 8297 (Mali-T760) >>> Cube Technology T7 >>> Cube Technology T9 >>> Elephone P6000 >>> Five Technology ifive Air >>> Five Technology ifive mini 4 >>> Gionee S3 >>> HTC Desire 820 (Mali-T760, D820) >>> Hardkernel ODROID-XU3 (development board) >>> Hisense F5281 Vidaa Pad >>> Huawei H60 Honor 6 >>> Huawei Honor PE-UL00 (PE-TL10) >>> Huawei MT7 >>> Huawei Z100 >>> InFocus M550 3D >>> Jiayu JY-S3 >>> Leadcore L1860 >>> Lenovo P70 >>> Lenovo P70-A >>> MStar Android TV (Mali-T760) >>> Meizu MX4 Pro >>> Meizu k52 >>> Meizu m1 note >>> Oplus Evo 4G >>> Oppo U3 >>> Pipo P1 >>> Pipo P4 >>> Pipo P7 >>> Pipo P9 >>> Pipo P9 3G >>> Rockchip rk3288 (development board) >>> Samsung Galaxy Alpha (Mali-T628, SM-G850) >>> Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) >>> Samsung Galaxy Note Edge (Mali-T760, SM-N915x) >>> Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) >>> Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) >>> Samsung SM-G900x Galaxy S5 (Mali-T628) >>> TCL 5042T >>> TCL M2M >>> TCL i718M >>> Teclast P90HD >>> Teclast T98 4G (C6R2) >>> >>> >>> KHR_texture_compression_astc_hdr is supported by these 46 devices. >>> >>> 10moons D8 Plus >>> 10moons D9 >>> Acer S56 Liquid Jade S >>> Alps k2v1 (development board) >>> Coolpad 8297 (Mali-T760) >>> Cube Technology T7 >>> Cube Technology T9 >>> Elephone P6000 >>> Five Technology ifive Air >>> Five Technology ifive mini 4 >>> Gionee S3 >>> HTC Desire 820 (Mali-T760, D820) >>> Hardkernel ODROID-XU3 (development board) >>> Hisense F5281 Vidaa Pad >>> Huawei H60 Honor 6 >>> Huawei Honor PE-UL00 (PE-TL10) >>> Huawei MT7 >>> Huawei Z100 >>> InFocus M550 3D >>> Jiayu JY-S3 >>> Leadcore L1860 >>> Lenovo P70 >>> Lenovo P70-A >>> MStar Android TV (Mali-T760) >>> Meizu MX4 Pro >>> Meizu k52 >>> Meizu m1 note >>> Oplus Evo 4G >>> Oppo U3 >>> Pipo P1 >>> Pipo P4 >>> Pipo P7 >>> Pipo P9 >>> Pipo P9 3G >>> Rockchip rk3288 (development board) >>> Samsung Galaxy Alpha (Mali-T628, SM-G850) >>> Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) >>> Samsung Galaxy Note Edge (Mali-T760, SM-N915x) >>> Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) >>> Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) >>> Samsung SM-G900x Galaxy S5 (Mali-T628) >>> TCL 5042T >>> TCL M2M >>> TCL i718M >>> Teclast P90HD >>> Teclast T98 4G (C6R2) >>> >>> >>> KHR_texture_compression_astc_hdr is supported by these 133 devices. >>> >>> 10moons D8 Plus >>> 10moons D9 >>> Acer S56 Liquid Jade S >>> Alcatel 5042 One Touch Pop 2 (4.5) >>> Alcatel A846L >>> Alps k2v1 (development board) >>> Amazon Kindle Fire HDX 8.9 (4th Gen, KFSAWA, KFSAWI) >>> Apple iPad Air 2 >>> Apple iPhone 6 >>> Apple iPhone 6 Plus >>> Archos 50 Diamond (K-Touch Touch 7) >>> Bouygues Telecom Ultym 5L >>> Coolpad 8297 (Mali-T760) >>> Coolpad 8297-T01 (Adreno 306) >>> Coolpad 8675-W00 (Adreno 205) >>> Coolpad 8675-W00 (Adreno 405) >>> Coolpad K1-NT >>> Cube Technology T7 >>> Cube Technology T9 >>> Elephone P6000 >>> Five Technology ifive Air >>> Five Technology ifive mini 4 >>> Gionee S3 >>> Google Nexus 6 >>> Google Nexus 9 >>> Google Project Tango >>> HTC D820mu (Adreno 306) >>> HTC Desire 510 (Adreno 306) >>> HTC Desire 820 (Adreno 405, D820) >>> HTC Desire 820 (Mali-T760, D820) >>> HTC Desire 820q >>> Hardkernel ODROID-XU3 (development board) >>> Hasee Q501 >>> Hisense F5281 Vidaa Pad >>> Huawei Ascend G7 >>> Huawei H60 Honor 6 >>> Huawei Honor 4X (Che1-CL20) >>> Huawei Honor PE-UL00 (PE-TL10) >>> Huawei MT7 >>> Huawei MediaPad T1 8.0 LTE (Adreno 306) >>> Huawei MediaPad T1 8.0 Pro >>> Huawei Y550 >>> Huawei Z100 >>> InFocus M550 3D >>> Intel(R) CherryView HD Graphics >>> Jiayu JY-S3 >>> LG F60 D390 >>> LG G3 (Adreno 420, F460) >>> Leadcore L1860 >>> Lenovo K1 HD (2014) >>> Lenovo K30 >>> Lenovo P70 >>> Lenovo P70-A >>> Lenovo S90 >>> Lenovo ThinkVision 28 >>> Lenovo Z2 Vibe >>> MStar Android TV (Mali-T760) >>> Meizu MX4 Pro >>> Meizu k52 >>> Meizu m1 note >>> Motorola Droid Turbo XT1254, Moto Maxx XT1225 >>> NVIDIA Shield tablet >>> NVIDIA Tegra GK20A (ardbeg, development board) >>> NVIDIA Tegra Note 8 >>> NVIDIA Tegra X1 Reference Platform (development board) >>> Oplus Evo 4G >>> Oppo R5 (R8106, R8107) >>> Oppo R8207 >>> Oppo U3 >>> Panasonic Eluga U2 >>> Pantech IM-A930 Vega >>> Pipo P1 >>> Pipo P4 >>> Pipo P7 >>> Pipo P9 >>> Pipo P9 3G >>> Prestigio PSP5454DUO MultiPhone 5454 DUO >>> Qualcomm MSM8994 for arm64 (Adreno 430, development board) >>> Qualcomm apq8084 (Adreno 420, development board) >>> Qualcomm apq8084 (Adreno 420, development board) >>> Rockchip rk3288 (development board) >>> Samsung Galaxy A3 (SM-A300x) >>> Samsung Galaxy A7 (SM-A700x) >>> Samsung Galaxy Alpha (Mali-T628, SM-G850) >>> Samsung Galaxy Core Max (SM-G510F, SM-G5108Q, SM-G5109) >>> Samsung Galaxy Core Prime (Adreno 306, SM-G360) >>> Samsung Galaxy E5 (SM-E500) >>> Samsung Galaxy Grand 3 (SM-G7200, SM-G7202) >>> Samsung Galaxy K zoom (SM-C111, SM-C115x) >>> Samsung Galaxy Mega 2 (SM-G7508Q, SM-G7509) >>> Samsung Galaxy Note 10.1 (SM-P600, SM-P601, SM-P602) >>> Samsung Galaxy Note 3 Neo (Mali-T624, SM-N750, SM-N7500, SM-N7505, >>> SM-N7507) >>> Samsung Galaxy Note 4 (Adreno 420, SM-N910x) >>> Samsung Galaxy Note 4 (Mali-T760, SM-N910x, SM-N916) >>> Samsung Galaxy Note Edge (Adreno 420, SM-N915x, SCL24, SC-01G) >>> Samsung Galaxy Note Edge (Mali-T760, SM-N915x) >>> Samsung Galaxy Note III (Mali-T628, SM-N900, SM-N9000Q) >>> Samsung Galaxy Note Pro 12.2 (SM-P900, SM-P901, SM-P902) >>> Samsung Galaxy S5 (Adreno 420, SM-G901) >>> Samsung Galaxy Tab 4 8.0 (Adreno 306, SM-T333) >>> Samsung Galaxy Tab S 10.5 (Mali-T628, SM-T807) >>> Samsung Galaxy Tab S 10.5 (Mali-T760, SM-T805S) >>> Samsung Galaxy Tab S 10.5 (SM-T800, SM-T801, SM-T805) >>> Samsung Galaxy Tab S 8.4 (Mali-T628, SM-T707A) >>> Samsung Galaxy Tab S 8.4 (SM-T700, SM-T705) >>> Samsung SM-A500x >>> Samsung SM-E7000 Galaxy E7 >>> Samsung SM-G357FZ >>> Samsung SM-G530x >>> Samsung SM-G750H >>> Samsung SM-G900x Galaxy S5 (Mali-T628) >>> Samsung SM-G906 Galaxy S5 Prime >>> Samsung SM-G910F (Mali-T624) >>> Samsung SM-N910x (Mali-T624) >>> Samsung SM-S820L >>> Samsung SM-T520 Galaxy Tab 10.1 >>> Samsung SM-T900 Galaxy Tab Pro 12.2 >>> TCL 5042T >>> TCL M2M >>> TCL i718M >>> Teclast P90HD >>> Teclast T98 4G (C6R2) >>> Verykool SL4500 >>> Vivo X5Max L >>> Vivo Y27 >>> Vodafone Smart Tab 4G >>> XOLO LT2000 >>> Xiaomi MiPad >>> Xiaomi Redmi 2 (Adreno 306, 2014xxx) >>> ZTE A880 >>> ZTE N958St >>> ZTE V5S N918St >>> bq Aquaris E5 >> >> > > ----------------------------------------------------------- > 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...@ Mon Feb 23 14:15:26 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 23 Feb 2015 14:15:26 -0800 Subject: [Public WebGL] TexSubImage2D and error checking In-Reply-To: References: Message-ID: Thanks Roger for pointing out the need for these fixes. They've been backported to the 1.0.1, 1.0.2 and 1.0.3 conformance suites in https://github.com/KhronosGroup/WebGL/pull/870 . Please email the list if you see any problems with the revised tests. -Ken On Sat, Feb 7, 2015 at 3:19 PM, Roger Fong wrote: > Yup, test indeed passes on our implementation! > > Thanks! > Roger > > On Fri, Feb 6, 2015 at 5:50 PM, Kenneth Russell wrote: >> >> Roger, thanks very much for pointing out this issue. >> >> The test is definitely buggy. The tests which check that an >> INVALID_OPERATION error is generated are passing by luck. They are >> supposed to pass because of argument validation, but instead they're >> passing because no texture is bound, which also generates an >> INVALID_OPERATION error. The tests aren't supposed to verify the >> behavior if two errors might be generated, only one. This is an >> embarrassingly longstanding bug. >> >> I've just merged a pull request which fixes this in the top-of-tree >> >> https://www.khronos.org/registry/webgl/sdk/tests/conformance/textures/tex-image-with-invalid-data.html >> . Can you confirm that this test works on your implementation now? If >> so, we can merge this fix back to the earlier conformance suites. >> >> Note that the exception-throwing tests should probably be working on >> all implementations. The type conversions are conceptually supposed to >> be done during the call, before the implementation of texImage2D or >> texSubImage2D is reached. In fact, some of those tests should probably >> be run both with a texture bound and without. >> >> -Ken >> >> >> >> On Fri, Feb 6, 2015 at 12:52 PM, Roger Fong >> wrote: >> > Hello again folks, >> > >> > I have a question about TexSubImage2D and more specifically about the >> > implications of this test: >> > >> > https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/textures/tex-image-with-invalid-data.html >> > >> > For starters, there is a setup() function in this test, but stepping >> > into >> > the code, it never ever gets called. >> > This seems like a problem, as the test still seems to expect that >> > texSubImage2D calls should fail, not because there is no bound texture >> > to >> > write over, but because of invalid data issues. >> > >> > Does this imply that texSubImage2D should fail due to invalid data types >> > even before checking for whether or not a texture is actually bound? Or >> > is >> > the test just faulty? >> > >> > Thanks! >> > Roger > > ----------------------------------------------------------- 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...@ Mon Feb 23 17:40:00 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 23 Feb 2015 17:40:00 -0800 Subject: [Public WebGL] Minor spec updates Message-ID: A couple of minor spec updates to WebGL 2.0: - Texture swizzling has been removed from the specification in https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL implementations, texture swizzles can not be implemented in a performant manner, meaning that applications relying on this functionality would run significantly more slowly on those implementations. For this reason, texture swizzles will not be supported in WebGL 2.0. - A query of the implementation-dependent maximum client wait timeout has been added in https://github.com/KhronosGroup/WebGL/pull/871 . This is intended to prevent applications from blocking the browser's main thread for long periods of time. An INVALID_OPERATION error will now be generated if the user requests a timeout larger than the maximum. Please send any comments about these changes to the list. Thanks, -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 juj...@ Mon Feb 23 21:57:11 2015 From: juj...@ (=?utf-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 24 Feb 2015 07:57:11 +0200 Subject: [Public WebGL] Minor spec updates In-Reply-To: References: Message-ID: The choice to remove texture swizzles sounds arbitrary to me. Neither the pull request or this mail actually explain what the hardware for this was, which leaves the most important bits of detail for a decision like this up for random guesses to parties who were not present in the F2F discussion. Why is native GL/GLES then able to implement these, and why is WebGL special in this respect that it can't? > On 24 Feb 2015, at 03:40, Kenneth Russell wrote: > > > A couple of minor spec updates to WebGL 2.0: > > - Texture swizzling has been removed from the specification in > https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL > implementations, texture swizzles can not be implemented in a > performant manner, meaning that applications relying on this > functionality would run significantly more slowly on those > implementations. For this reason, texture swizzles will not be > supported in WebGL 2.0. > > - A query of the implementation-dependent maximum client wait timeout > has been added in https://github.com/KhronosGroup/WebGL/pull/871 . > This is intended to prevent applications from blocking the browser's > main thread for long periods of time. An INVALID_OPERATION error will > now be generated if the user requests a timeout larger than the > maximum. > > Please send any comments about these changes to the list. > > Thanks, > > -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...@ Tue Feb 24 15:01:51 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 24 Feb 2015 15:01:51 -0800 Subject: [Public WebGL] Minor spec updates In-Reply-To: References: Message-ID: It was determined by both the ANGLE team (who have built OpenGL ES on top of Direct3D) and Microsoft's browser team that OpenGL's texture swizzle functionality can not be implemented with high performance on top of Direct3D. There are two primary options for doing so -- either re-uploading texture data behind the scenes -- expensive, as you can appreciate -- or dynamically recompiling shaders on the fly to include the appropriate texture swizzles -- also expensive, and a lot of bookkeeping. Either way, an application heavily utilizing OpenGL ES's texture swizzle functionality would never perform well on a Direct3D based WebGL implementation. For this reason the functionality was removed from WebGL. For use cases like Emscripten, it will be necessary to push back to application authors and re-cast the use of texture swizzles in some other way. There are plenty of other options, including generating new shaders on the fly, or generating several up front at application startup. -Ken On Mon, Feb 23, 2015 at 9:57 PM, Jukka Jyl?nki wrote: > > The choice to remove texture swizzles sounds arbitrary to me. Neither the pull request or this mail actually explain what the hardware for this was, which leaves the most important bits of detail for a decision like this up for random guesses to parties who were not present in the F2F discussion. Why is native GL/GLES then able to implement these, and why is WebGL special in this respect that it can't? > >> On 24 Feb 2015, at 03:40, Kenneth Russell wrote: >> >> >> A couple of minor spec updates to WebGL 2.0: >> >> - Texture swizzling has been removed from the specification in >> https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL >> implementations, texture swizzles can not be implemented in a >> performant manner, meaning that applications relying on this >> functionality would run significantly more slowly on those >> implementations. For this reason, texture swizzles will not be >> supported in WebGL 2.0. >> >> - A query of the implementation-dependent maximum client wait timeout >> has been added in https://github.com/KhronosGroup/WebGL/pull/871 . >> This is intended to prevent applications from blocking the browser's >> main thread for long periods of time. An INVALID_OPERATION error will >> now be generated if the user requests a timeout larger than the >> maximum. >> >> Please send any comments about these changes to the list. >> >> Thanks, >> >> -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 thu...@ Tue Feb 24 15:23:10 2015 From: thu...@ (Ben Adams) Date: Tue, 24 Feb 2015 23:23:10 +0000 Subject: [Public WebGL] Minor spec updates In-Reply-To: References: Message-ID: This is just parsing swizzles, not GLSL swizzles? On 24 February 2015 at 23:01, Kenneth Russell wrote: > > It was determined by both the ANGLE team (who have built OpenGL ES on > top of Direct3D) and Microsoft's browser team that OpenGL's texture > swizzle functionality can not be implemented with high performance on > top of Direct3D. There are two primary options for doing so -- either > re-uploading texture data behind the scenes -- expensive, as you can > appreciate -- or dynamically recompiling shaders on the fly to include > the appropriate texture swizzles -- also expensive, and a lot of > bookkeeping. Either way, an application heavily utilizing OpenGL ES's > texture swizzle functionality would never perform well on a Direct3D > based WebGL implementation. For this reason the functionality was > removed from WebGL. > > For use cases like Emscripten, it will be necessary to push back to > application authors and re-cast the use of texture swizzles in some > other way. There are plenty of other options, including generating new > shaders on the fly, or generating several up front at application > startup. > > -Ken > > > On Mon, Feb 23, 2015 at 9:57 PM, Jukka Jyl?nki wrote: > > > > The choice to remove texture swizzles sounds arbitrary to me. Neither > the pull request or this mail actually explain what the hardware for this > was, which leaves the most important bits of detail for a decision like > this up for random guesses to parties who were not present in the F2F > discussion. Why is native GL/GLES then able to implement these, and why is > WebGL special in this respect that it can't? > > > >> On 24 Feb 2015, at 03:40, Kenneth Russell wrote: > >> > >> > >> A couple of minor spec updates to WebGL 2.0: > >> > >> - Texture swizzling has been removed from the specification in > >> https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL > >> implementations, texture swizzles can not be implemented in a > >> performant manner, meaning that applications relying on this > >> functionality would run significantly more slowly on those > >> implementations. For this reason, texture swizzles will not be > >> supported in WebGL 2.0. > >> > >> - A query of the implementation-dependent maximum client wait timeout > >> has been added in https://github.com/KhronosGroup/WebGL/pull/871 . > >> This is intended to prevent applications from blocking the browser's > >> main thread for long periods of time. An INVALID_OPERATION error will > >> now be generated if the user requests a timeout larger than the > >> maximum. > >> > >> Please send any comments about these changes to the list. > >> > >> Thanks, > >> > >> -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Feb 24 16:35:35 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 24 Feb 2015 16:35:35 -0800 Subject: [Public WebGL] Minor spec updates In-Reply-To: References: Message-ID: It's the swizzle state of texture objects that's been removed. GLSL swizzles are unaffected. On Tue, Feb 24, 2015 at 3:23 PM, Ben Adams wrote: > This is just parsing swizzles, not GLSL swizzles? > > > On 24 February 2015 at 23:01, Kenneth Russell wrote: >> >> >> It was determined by both the ANGLE team (who have built OpenGL ES on >> top of Direct3D) and Microsoft's browser team that OpenGL's texture >> swizzle functionality can not be implemented with high performance on >> top of Direct3D. There are two primary options for doing so -- either >> re-uploading texture data behind the scenes -- expensive, as you can >> appreciate -- or dynamically recompiling shaders on the fly to include >> the appropriate texture swizzles -- also expensive, and a lot of >> bookkeeping. Either way, an application heavily utilizing OpenGL ES's >> texture swizzle functionality would never perform well on a Direct3D >> based WebGL implementation. For this reason the functionality was >> removed from WebGL. >> >> For use cases like Emscripten, it will be necessary to push back to >> application authors and re-cast the use of texture swizzles in some >> other way. There are plenty of other options, including generating new >> shaders on the fly, or generating several up front at application >> startup. >> >> -Ken >> >> >> On Mon, Feb 23, 2015 at 9:57 PM, Jukka Jyl?nki wrote: >> > >> > The choice to remove texture swizzles sounds arbitrary to me. Neither >> > the pull request or this mail actually explain what the hardware for this >> > was, which leaves the most important bits of detail for a decision like this >> > up for random guesses to parties who were not present in the F2F discussion. >> > Why is native GL/GLES then able to implement these, and why is WebGL special >> > in this respect that it can't? >> > >> >> On 24 Feb 2015, at 03:40, Kenneth Russell wrote: >> >> >> >> >> >> A couple of minor spec updates to WebGL 2.0: >> >> >> >> - Texture swizzling has been removed from the specification in >> >> https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL >> >> implementations, texture swizzles can not be implemented in a >> >> performant manner, meaning that applications relying on this >> >> functionality would run significantly more slowly on those >> >> implementations. For this reason, texture swizzles will not be >> >> supported in WebGL 2.0. >> >> >> >> - A query of the implementation-dependent maximum client wait timeout >> >> has been added in https://github.com/KhronosGroup/WebGL/pull/871 . >> >> This is intended to prevent applications from blocking the browser's >> >> main thread for long periods of time. An INVALID_OPERATION error will >> >> now be generated if the user requests a timeout larger than the >> >> maximum. >> >> >> >> Please send any comments about these changes to the list. >> >> >> >> Thanks, >> >> >> >> -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 >> ----------------------------------------------------------- >> > ----------------------------------------------------------- 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 Feb 24 23:29:25 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 25 Feb 2015 08:29:25 +0100 Subject: [Public WebGL] Minor spec updates In-Reply-To: References: Message-ID: Texture swizzling ( https://www.opengl.org/registry/specs/EXT/texture_swizzle.txt) allows you to remap any channel (RGBA) to any other channel not as part of a shader command texture2D(foo, bar).bgra but as part of a texture parameter state glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_SWIZZLE_R_EXT, GL_BLUE). It's expensive on D3D because D3D doesn't have texture swizzling state parameter functionality. It has been elevated to core functionality in ES 3.0 and GL 3.3. The idea behind this functionality is to make it easier to handle passing data around in textures. It's based on the observation that if you put data into a texture, you're assuming an implicit semantic as to what channels mean. Swizzle is supposed to make that easier. I personally don't see how it makes that easier. A more meaningful extension (which doesn't exist) would allow a programmer to define a structure of some kind, and define that a sampler obtains said structure, such that calls like myStructure.sample(someUniform, someUV).albedo become possible. It could be argued this could be introduced as a shader transpiler of some kind. On Wed, Feb 25, 2015 at 1:35 AM, Kenneth Russell wrote: > > It's the swizzle state of texture objects that's been removed. GLSL > swizzles are unaffected. > > > On Tue, Feb 24, 2015 at 3:23 PM, Ben Adams > wrote: > > This is just parsing swizzles, not GLSL swizzles? > > > > > > On 24 February 2015 at 23:01, Kenneth Russell wrote: > >> > >> > >> It was determined by both the ANGLE team (who have built OpenGL ES on > >> top of Direct3D) and Microsoft's browser team that OpenGL's texture > >> swizzle functionality can not be implemented with high performance on > >> top of Direct3D. There are two primary options for doing so -- either > >> re-uploading texture data behind the scenes -- expensive, as you can > >> appreciate -- or dynamically recompiling shaders on the fly to include > >> the appropriate texture swizzles -- also expensive, and a lot of > >> bookkeeping. Either way, an application heavily utilizing OpenGL ES's > >> texture swizzle functionality would never perform well on a Direct3D > >> based WebGL implementation. For this reason the functionality was > >> removed from WebGL. > >> > >> For use cases like Emscripten, it will be necessary to push back to > >> application authors and re-cast the use of texture swizzles in some > >> other way. There are plenty of other options, including generating new > >> shaders on the fly, or generating several up front at application > >> startup. > >> > >> -Ken > >> > >> > >> On Mon, Feb 23, 2015 at 9:57 PM, Jukka Jyl?nki > wrote: > >> > > >> > The choice to remove texture swizzles sounds arbitrary to me. Neither > >> > the pull request or this mail actually explain what the hardware for > this > >> > was, which leaves the most important bits of detail for a decision > like this > >> > up for random guesses to parties who were not present in the F2F > discussion. > >> > Why is native GL/GLES then able to implement these, and why is WebGL > special > >> > in this respect that it can't? > >> > > >> >> On 24 Feb 2015, at 03:40, Kenneth Russell wrote: > >> >> > >> >> > >> >> A couple of minor spec updates to WebGL 2.0: > >> >> > >> >> - Texture swizzling has been removed from the specification in > >> >> https://github.com/KhronosGroup/WebGL/pull/854 . On some WebGL > >> >> implementations, texture swizzles can not be implemented in a > >> >> performant manner, meaning that applications relying on this > >> >> functionality would run significantly more slowly on those > >> >> implementations. For this reason, texture swizzles will not be > >> >> supported in WebGL 2.0. > >> >> > >> >> - A query of the implementation-dependent maximum client wait timeout > >> >> has been added in https://github.com/KhronosGroup/WebGL/pull/871 . > >> >> This is intended to prevent applications from blocking the browser's > >> >> main thread for long periods of time. An INVALID_OPERATION error will > >> >> now be generated if the user requests a timeout larger than the > >> >> maximum. > >> >> > >> >> Please send any comments about these changes to the list. > >> >> > >> >> Thanks, > >> >> > >> >> -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 > >> ----------------------------------------------------------- > >> > > > > ----------------------------------------------------------- > 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 dav...@ Thu Feb 26 00:24:33 2015 From: dav...@ (David) Date: Thu, 26 Feb 2015 16:24:33 +0800 Subject: [Public WebGL] Progress on iOS/Android support Message-ID: Hi guys, As we know, iOS 8/Android 5.0 claim that WebGL is supported on webview. Does anyone have more details? I?ve seen screenshots like below from http://blog.ludei.com/webgl-ios-8-safari-webview/. I?d like to know the data sources and how it is suppored on Android webview. Thanks, -David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 50327 bytes Desc: not available URL: From kri...@ Fri Feb 27 01:13:30 2015 From: kri...@ (Kristian Sons) Date: Fri, 27 Feb 2015 10:13:30 +0100 Subject: [Public WebGL] Progress on iOS/Android support In-Reply-To: References: Message-ID: <54F0353A.7070500@dfki.de> Hi David, I can't directly answer your question, but like to point you to the crosswalk project: https://crosswalk-project.org/ It provides an alternative webview with access to additional APIs including WebGL. They claim to provide WebGL on any Android 4.x device (take that with a grain of salt). So even if there is support in some recent or vendor-specific webview, this approach might help. We have had good experiences turning some WebGL-based XML3D applications into Android apps. Best, Kristian Am 26.02.2015 um 09:24 schrieb David: > > Hi guys, > > As we know, iOS 8/Android 5.0 claim that WebGL is supported on > webview. Does anyone have more details? > > I?ve seen screenshots like below from > http://blog.ludei.com/webgl-ios-8-safari-webview/. I?d like to know > the data sources and how it is suppored on Android webview. > > Thanks, > > -David > -- _______________________________________________________________________________ Kristian Sons Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realit?t Campus, Geb. D 3 2, Raum 0.77 66123 Saarbr?cken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775?2235 kristian.sons...@ http://www.xml3d.org Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _______________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 50327 bytes Desc: not available URL: From kbr...@ Fri Feb 27 11:03:28 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 27 Feb 2015 11:03:28 -0800 Subject: [Public WebGL] Progress on iOS/Android support In-Reply-To: References: Message-ID: I can't speak authoritatively, but on any Android 5.0 device where WebGL is supported in Chrome, it should now also be supported in the system WebView. My understanding is that iOS 8 supports WebGL both in Safari and applications using WebView. We've verified that WebGL works in Chrome on iOS, which uses the system WebView. -Ken On Thu, Feb 26, 2015 at 12:24 AM, David wrote: > Hi guys, > > > > As we know, iOS 8/Android 5.0 claim that WebGL is supported on webview. > Does anyone have more details? > > > > I?ve seen screenshots like below from > http://blog.ludei.com/webgl-ios-8-safari-webview/. I?d like to know the > data sources and how it is suppored on Android webview. > > > > Thanks, > > -David > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 50327 bytes Desc: not available URL: From dav...@ Fri Feb 27 18:58:29 2015 From: dav...@ (David) Date: Sat, 28 Feb 2015 10:58:29 +0800 Subject: [Public WebGL] =?UTF-8?Q?=E7=AD=94=E5=A4=8D:_=5BPublic_WebGL=5D_Progress_on_i?= =?UTF-8?Q?OS/Android_support?= In-Reply-To: <001801d052fa$0e4eeee0$2aeccca0$@google.com> References: <001801d052fa$0e4eeee0$2aeccca0$@google.com> Message-ID: Thanks Kenneth. I am playing a few samples of http://threejs.org on iOS 8.1. Some of them can be played well, however, one of them(https://www.batmanarkhamknight.com/en_US/batmobile) cannot be played on either safari or chrome. As you know, this can be played well on PC chrome. I guess probably some APIs are not supported. That?s why I wonder if any information we can see. I don?t have a device of Android 5.0 on hand, so I cannot tell what it looks like. I do wonder if webgl is supported well as iOS 8/Android 5.0 claims. ???: owners-public_webgl...@ [mailto:owners-public_webgl...@] ?? Kenneth Russell ????: 2015?2?28? 3:03 ???: David ??: public_webgl...@ ??: Re: [Public WebGL] Progress on iOS/Android support I can't speak authoritatively, but on any Android 5.0 device where WebGL is supported in Chrome, it should now also be supported in the system WebView. My understanding is that iOS 8 supports WebGL both in Safari and applications using WebView. We've verified that WebGL works in Chrome on iOS, which uses the system WebView. -Ken On Thu, Feb 26, 2015 at 12:24 AM, David wrote: Hi guys, As we know, iOS 8/Android 5.0 claim that WebGL is supported on webview. Does anyone have more details? I?ve seen screenshots like below from http://blog.ludei.com/webgl-ios-8-safari-webview/. I?d like to know the data sources and how it is suppored on Android webview. Thanks, -David -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 50327 bytes Desc: not available URL: From dav...@ Fri Feb 27 19:06:46 2015 From: dav...@ (David) Date: Sat, 28 Feb 2015 11:06:46 +0800 Subject: [Public WebGL] =?UTF-8?Q?=E7=AD=94=E5=A4=8D:_=5BPublic_WebGL=5D_Progress_on_i?= =?UTF-8?Q?OS/Android_support?= In-Reply-To: <001b01d05275$97d256a0$c77703e0$@dfki.de> References: <001b01d05275$97d256a0$c77703e0$@dfki.de> Message-ID: Thanks Kristian. An alternative webview is not a solution I am looking for as it will make the size of an app increase a lot so that it can hit the size limitation easily. ???: owners-public_webgl...@ [mailto:owners-public_webgl...@] ?? Kristian Sons ????: 2015?2?27? 17:14 ???: David; public_webgl...@ ??: Re: [Public WebGL] Progress on iOS/Android support Hi David, I can't directly answer your question, but like to point you to the crosswalk project: https://crosswalk-project.org/ It provides an alternative webview with access to additional APIs including WebGL. They claim to provide WebGL on any Android 4.x device (take that with a grain of salt). So even if there is support in some recent or vendor-specific webview, this approach might help. We have had good experiences turning some WebGL-based XML3D applications into Android apps. Best, Kristian Am 26.02.2015 um 09:24 schrieb David: Hi guys, As we know, iOS 8/Android 5.0 claim that WebGL is supported on webview. Does anyone have more details? I?ve seen screenshots like below from http://blog.ludei.com/webgl-ios-8-safari-webview/. I?d like to know the data sources and how it is suppored on Android webview. Thanks, -David -- _______________________________________________________________________________ Kristian Sons Deutsches Forschungszentrum f?r K?nstliche Intelligenz GmbH, DFKI Agenten und Simulierte Realit?t Campus, Geb. D 3 2, Raum 0.77 66123 Saarbr?cken, Germany Phone: +49 681 85775-3833 Phone: +49 681 302-3833 Fax: +49 681 85775?2235 kristian.sons...@ http://www.xml3d.org Gesch?ftsf?hrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 _______________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 50327 bytes Desc: not available URL: