From jda...@ Wed Aug 2 13:40:17 2017 From: jda...@ (John Davis) Date: Wed, 2 Aug 2017 16:40:17 -0400 Subject: [Public WebGL] Augmented Reality Message-ID: Where's the WebAR standard? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cwa...@ Wed Aug 2 13:55:59 2017 From: cwa...@ (Corentin Wallez) Date: Wed, 2 Aug 2017 16:55:59 -0400 Subject: [Public WebGL] Augmented Reality In-Reply-To: References: Message-ID: There is no such standard for now, Chromium has a prototype to give an idea of what it could be. Make sure you read their disclaimer: Defining how a web standard will look like is a complex conversation. All the code and proposals in this project are not meant to be the definitive implementations of AR capabilities for the web, but some prototypes you can play around with at your own risk and have some starting point to build upon. On Wed, Aug 2, 2017 at 4:40 PM, John Davis wrote: > Where's the WebAR standard? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Aug 9 20:16:23 2017 From: kbr...@ (Kenneth Russell) Date: Wed, 9 Aug 2017 20:16:23 -0700 Subject: [Public WebGL] WebGL BOF presentations from SIGGRAPH 2017 Message-ID: [cross-posted to webgl-dev-list] WebGL community, Thanks to you all, the WebGL BOF at SIGGRAPH was a great success! If you couldn't attend in person, all of the presentation materials, demos, and video of the BOF are now available here: https://www.khronos.org/webgl/wiki/Presentations#SIGGRAPH_2017_WebGL_BOF Thanks to all the presenters for making it a great get-together! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Thu Aug 10 12:03:55 2017 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Thu, 10 Aug 2017 22:03:55 +0300 Subject: [Public WebGL] WebGL BOF presentations from SIGGRAPH 2017 In-Reply-To: References: Message-ID: Thanks for producing a video of the event Ken! It was great to get to watch it, I feel sad I was not able to attend. In particular, Spector.js looks like a dream tool, did not know about it before, and I was already able to use it to debug two bugs I have had in my backlog. This is extremely impressive work from Babylon.js authors - you guys had to write a tool to debug Babylon.js, but in the process made it generic so it applies to any WebGL page. That rocks big time! Cheers, Jukka 2017-08-10 6:16 GMT+03:00 Kenneth Russell : > [cross-posted to webgl-dev-list] > > WebGL community, > > Thanks to you all, the WebGL BOF at SIGGRAPH was a great success! If you > couldn't attend in person, all of the presentation materials, demos, and > video of the BOF are now available here: > > https://www.khronos.org/webgl/wiki/Presentations#SIGGRAPH_2017_WebGL_BOF > > Thanks to all the presenters for making it a great get-together! > > -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 kbr...@ Thu Aug 10 17:33:34 2017 From: kbr...@ (Kenneth Russell) Date: Thu, 10 Aug 2017 17:33:34 -0700 Subject: [Public WebGL] WebGL BOF presentations from SIGGRAPH 2017 In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 12:03 PM, Jukka Jyl?nki wrote: > Thanks for producing a video of the event Ken! > Please thank Khronos for it! They had superb A/V support. It was great to get to watch it, I feel sad I was not able to attend. > Also sorry you weren't there, but hopefully next time! And hope that you will present your latest work the next time, too! In particular, Spector.js looks like a dream tool, did not know about > it before, and I was already able to use it to debug two bugs I have > had in my backlog. This is extremely impressive work from Babylon.js > authors - you guys had to write a tool to debug Babylon.js, but in the > process made it generic so it applies to any WebGL page. That rocks > big time! > SpectorJS is awesome. It is really robust and works against even sophisticated content, like Epic's Zen Garden which you ported to WebAssembly! -Ken Cheers, > Jukka > > 2017-08-10 6:16 GMT+03:00 Kenneth Russell : > > [cross-posted to webgl-dev-list] > > > > WebGL community, > > > > Thanks to you all, the WebGL BOF at SIGGRAPH was a great success! If you > > couldn't attend in person, all of the presentation materials, demos, and > > video of the BOF are now available here: > > > > https://www.khronos.org/webgl/wiki/Presentations#SIGGRAPH_2017_WebGL_BOF > > > > Thanks to all the presenters for making it a great get-together! > > > > -Ken > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Tue Aug 15 08:44:32 2017 From: dmi...@ (Kirill Dmitrenko) Date: Tue, 15 Aug 2017 18:44:32 +0300 Subject: [Public WebGL] Signed Int to Float Convertion Problem Message-ID: <90511502811872@webcorp01e.yandex-team.ru> Hi! While working on a project we've stabled upon what looks like an inconsistency between the spec and implementations. We use normalized integers as vertex attributes and our math rely on conversion rules described in GLES 2 spec (section 2.1.2). However, we were experiencing problems with it. Further investigation showed, that in GLES 3 and GL 4.2+ conversion rules were changed (https://www.khronos.org/opengl/wiki/Normalized_Integer#Signed). I've coded a repro case: http://output.jsbin.com/wezetob/1. The canvas'll be red if GLES 3 conversions are used by an implementation and green if GLES 2 ones. Testing different devices I was able to find some that produces green (on attached photo). We're working on fixing the math we use since it seems we can't rely on any particular rule. Should that be noted in the differences section of the spec? Has someone else run into similar problems? --? Kirill Dmitrenko Yandex Maps Team -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0545.JPG Type: image/jpeg Size: 1523321 bytes Desc: not available URL: From zmo...@ Tue Aug 15 11:14:07 2017 From: zmo...@ (Zhenyao Mo) Date: Tue, 15 Aug 2017 11:14:07 -0700 Subject: [Public WebGL] Signed Int to Float Convertion Problem In-Reply-To: <90511502811872@webcorp01e.yandex-team.ru> References: <90511502811872@webcorp01e.yandex-team.ru> Message-ID: You are right. The rules are indeed different. We will need to discuss this during the next working group meeting and come up with a resolution. On Tue, Aug 15, 2017 at 8:44 AM, Kirill Dmitrenko wrote: > Hi! > > While working on a project we've stabled upon what looks like an inconsistency between the spec and implementations. We use normalized integers as vertex attributes and our math rely on conversion rules described in GLES 2 spec (section 2.1.2). However, we were experiencing problems with it. Further investigation showed, that in GLES 3 and GL 4.2+ conversion rules were changed (https://www.khronos.org/opengl/wiki/Normalized_Integer#Signed). I've coded a repro case: http://output.jsbin.com/wezetob/1. The canvas'll be red if GLES 3 conversions are used by an implementation and green if GLES 2 ones. Testing different devices I was able to find some that produces green (on attached photo). > > We're working on fixing the math we use since it seems we can't rely on any particular rule. > > Should that be noted in the differences section of the spec? Has someone else run into similar problems? > > -- > Kirill Dmitrenko > Yandex Maps Team ----------------------------------------------------------- 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...@ Tue Aug 15 12:16:32 2017 From: khr...@ (Mark Callow) Date: Tue, 15 Aug 2017 12:16:32 -0700 Subject: [Public WebGL] Signed Int to Float Convertion Problem In-Reply-To: References: <90511502811872@webcorp01e.yandex-team.ru> Message-ID: <84D87B99-CDC3-4BB0-869D-09A863A062BB@callow.im> > On Aug 15, 2017, at 11:14, Zhenyao Mo wrote: > > > You are right. The rules are indeed different. We will need to > discuss this during the next working group meeting and come up with a > resolution. > I don?t understand what the problem is w.r.t WebGL. I would have expected WebGL 1 to follow the ES 2 rule and WebGL 2 to follow the ES 3 rule. The difference is described in Appendix F.2 of the ES 3 spec. I would consider any other behavior to be implementation bugs. 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 URL: From zmo...@ Tue Aug 15 12:34:06 2017 From: zmo...@ (Zhenyao Mo) Date: Tue, 15 Aug 2017 12:34:06 -0700 Subject: [Public WebGL] Signed Int to Float Convertion Problem In-Reply-To: <84D87B99-CDC3-4BB0-869D-09A863A062BB@callow.im> References: <90511502811872@webcorp01e.yandex-team.ru> <84D87B99-CDC3-4BB0-869D-09A863A062BB@callow.im> Message-ID: But WebGL1 could be implemented on top of ES2 or ES3, so the question is do we want to emulate ES2's behavior for WebGL1 implemented on top of ES3 or desktop GL. On Tue, Aug 15, 2017 at 12:16 PM, Mark Callow wrote: > > On Aug 15, 2017, at 11:14, Zhenyao Mo wrote: > > > You are right. The rules are indeed different. We will need to > discuss this during the next working group meeting and come up with a > resolution. > > > I don?t understand what the problem is w.r.t WebGL. I would have expected > WebGL 1 to follow the ES 2 rule and WebGL 2 to follow the ES 3 rule. The > difference is described in Appendix F.2 of the ES 3 spec. I would consider > any other behavior to be implementation bugs. > > 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 khr...@ Tue Aug 15 12:47:42 2017 From: khr...@ (Mark Callow) Date: Tue, 15 Aug 2017 12:47:42 -0700 Subject: [Public WebGL] Signed Int to Float Convertion Problem In-Reply-To: References: <90511502811872@webcorp01e.yandex-team.ru> <84D87B99-CDC3-4BB0-869D-09A863A062BB@callow.im> Message-ID: <5DDED988-F65E-4E99-B24C-8E3E7EA5B433@callow.im> > On Aug 15, 2017, at 12:34, Zhenyao Mo wrote: > > > But WebGL1 could be implemented on top of ES2 or ES3, so the question > is do we want to emulate ES2's behavior for WebGL1 implemented on top > of ES3 or desktop GL. > Yes and IIRC it is acceptable for ES implementations to return an ES3 context even when an ES2 context is requested. I don?t know how practical emulation is. 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 URL: From kbr...@ Tue Aug 15 13:42:02 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 15 Aug 2017 13:42:02 -0700 Subject: [Public WebGL] Signed Int to Float Convertion Problem In-Reply-To: <5DDED988-F65E-4E99-B24C-8E3E7EA5B433@callow.im> References: <90511502811872@webcorp01e.yandex-team.ru> <84D87B99-CDC3-4BB0-869D-09A863A062BB@callow.im> <5DDED988-F65E-4E99-B24C-8E3E7EA5B433@callow.im> Message-ID: This is in the fixed function part of the hardware. There's no possibility for emulating the behavior. Since WebGL's hosted on top of a large range of OpenGL versions, it's impossible to guarantee OpenGL ES 2.0's behavior in WebGL 1.0 contexts. To be honest since this hasn't come up until now I'm inclined to simply mention this in the differences section of the spec and not change the spec. Adding a query to determine the underlying behavior would only slow down startup time for most WebGL apps and add yet more code to the browser for a corner case. -Ken On Tue, Aug 15, 2017 at 12:47 PM, Mark Callow wrote: > > On Aug 15, 2017, at 12:34, Zhenyao Mo wrote: > > > But WebGL1 could be implemented on top of ES2 or ES3, so the question > is do we want to emulate ES2's behavior for WebGL1 implemented on top > of ES3 or desktop GL. > > > Yes and IIRC it is acceptable for ES implementations to return an ES3 > context even when an ES2 context is requested. > > I don?t know how practical emulation is. > > Regards > > -Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Aug 15 16:21:26 2017 From: kbr...@ (Kenneth Russell) Date: Tue, 15 Aug 2017 16:21:26 -0700 Subject: [Public WebGL] Signed Int to Float Convertion Problem In-Reply-To: References: <90511502811872@webcorp01e.yandex-team.ru> <84D87B99-CDC3-4BB0-869D-09A863A062BB@callow.im> <5DDED988-F65E-4E99-B24C-8E3E7EA5B433@callow.im> Message-ID: Uploaded https://github.com/KhronosGroup/WebGL/pull/2486 documenting the differences in behavior. Kirill, based on your testing, is the change to the WebGL 2.0 specification needed, or could that one be left alone (and a conformance test added)? Please review. Thanks. -Ken On Tue, Aug 15, 2017 at 1:42 PM, Kenneth Russell wrote: > This is in the fixed function part of the hardware. There's no possibility > for emulating the behavior. Since WebGL's hosted on top of a large range of > OpenGL versions, it's impossible to guarantee OpenGL ES 2.0's behavior in > WebGL 1.0 contexts. > > To be honest since this hasn't come up until now I'm inclined to simply > mention this in the differences section of the spec and not change the > spec. Adding a query to determine the underlying behavior would only slow > down startup time for most WebGL apps and add yet more code to the browser > for a corner case. > > -Ken > > > > On Tue, Aug 15, 2017 at 12:47 PM, Mark Callow wrote: > >> >> On Aug 15, 2017, at 12:34, Zhenyao Mo wrote: >> >> >> But WebGL1 could be implemented on top of ES2 or ES3, so the question >> is do we want to emulate ES2's behavior for WebGL1 implemented on top >> of ES3 or desktop GL. >> >> >> Yes and IIRC it is acceptable for ES implementations to return an ES3 >> context even when an ES2 context is requested. >> >> I don?t know how practical emulation is. >> >> Regards >> >> -Mark >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Fri Aug 18 06:12:58 2017 From: oet...@ (Olli Etuaho) Date: Fri, 18 Aug 2017 13:12:58 +0000 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal Message-ID: <1503061978259.23138@nvidia.com> Hello all! We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft: https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/? I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year. The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group. We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments. Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 18 06:41:43 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 18 Aug 2017 15:41:43 +0200 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal In-Reply-To: <1503061978259.23138@nvidia.com> References: <1503061978259.23138@nvidia.com> Message-ID: I'm a little confused by the example. In the example you do: gl.bindTexture(gl.TEXTURE_2D_ARRAY, tex); > gl.texStorage3D(gl.TEXTURE_2D_ARRAY, 1, gl.RGBA8, 512, 512, 2); > > But the specification states that: Written against the WebGL API 1.0 > specification. Which confuses me because WebGL 1.0 does not support 2D texture arrays, nor is there an extension for it. I also don't see how you'd attach a dual depth or stencil buffer that way (since there is no such thing as a depth buffer array or stencil buffer array). To my understanding the OVR_multiview extension regulates the presence of multiple attachments of the same type (but for different views) with the parameter to FramebufferTextureMultiviewOVR baseViewIndex. Though I also fail to see how mechanism would account for multiple depth/stencil buffers because those would be attached with the function framebufferRenderbuffer and that function does not support multiple attachment points. TL;DR: 1. How is it going to work in WebGL 1 which it claims to be written against using array textures which don't exist in WebGL1? 2. How are you going to attach a multiview depthbuffer when neither the OVR_multiview extension nor this extension makes any provision for it? On Fri, Aug 18, 2017 at 3:12 PM, Olli Etuaho wrote: > Hello all! > > > We have a significantly updated version of the WEBGL_multiview extension > proposal, and kindly request the community's feedback on it so we can > incorporate the feedback and proceed to move the extension to draft: > > > https://www.khronos.org/registry/webgl/extensions/ > proposals/WEBGL_multiview/? > > > I hope this addresses the major concerns people had with regards to the > extension in the previous discussion earlier during the year. > > > The extension is now self-contained and is designed not to require any > amendments to the core WebGL spec. But since enabling the implementation of > a zero-copy multiview pipeline is still a goal, an "opaque multiview > framebuffer" abstraction has been added to the extension proposal. This is > a type of a multiview framebuffer that other web APIs like WebVR would be > able to create, and that would work also with WebGL 1.0. The specific > shape of the WebVR API to create this type of framebuffers will still need > to be specified within the WebVR working group. > > > We have also worked on implementing functionality that would be required > by the extension in ANGLE, and the new revision of the proposal has taken > findings from that work into account. Particularly, we've removed > restrictions on shaders since we found out the restrictions won't be > necessary for good performance. On the other hand, we've added some minor > restrictions that are required by a performant implementation on top of > OpenGL and Direct3D, like baseViewIndex having to match between different > framebuffer attachments. > > > Regards, Olli > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Aug 18 06:46:22 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 18 Aug 2017 15:46:22 +0200 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal In-Reply-To: References: <1503061978259.23138@nvidia.com> Message-ID: P.S. I'm assuming of course that it's self evident that rendering with depth-testing (and hence the presence of a depth buffer) is something that's rather often what people will want to do. On Fri, Aug 18, 2017 at 3:41 PM, Florian B?sch wrote: > I'm a little confused by the example. In the example you do: > > gl.bindTexture(gl.TEXTURE_2D_ARRAY, tex); >> gl.texStorage3D(gl.TEXTURE_2D_ARRAY, 1, gl.RGBA8, 512, 512, 2); >> >> But the specification states that: > > Written against the WebGL API 1.0 >> specification. > > > Which confuses me because WebGL 1.0 does not support 2D texture arrays, > nor is there an extension for it. > > I also don't see how you'd attach a dual depth or stencil buffer that way > (since there is no such thing as a depth buffer array or stencil buffer > array). > > To my understanding the OVR_multiview extension regulates the presence of > multiple attachments of the same type (but for different views) with the > parameter to FramebufferTextureMultiviewOVR baseViewIndex. Though I also > fail to see how mechanism would account for multiple depth/stencil buffers > because those would be attached with the function framebufferRenderbuffer > and that function does not support multiple attachment points. > > TL;DR: > > 1. How is it going to work in WebGL 1 which it claims to be written > against using array textures which don't exist in WebGL1? > 2. How are you going to attach a multiview depthbuffer when neither > the OVR_multiview extension nor this extension makes any provision for it? > > > > On Fri, Aug 18, 2017 at 3:12 PM, Olli Etuaho wrote: > >> Hello all! >> >> >> We have a significantly updated version of the WEBGL_multiview extension >> proposal, and kindly request the community's feedback on it so we can >> incorporate the feedback and proceed to move the extension to draft: >> >> >> https://www.khronos.org/registry/webgl/extensions/proposals/ >> WEBGL_multiview/? >> >> >> I hope this addresses the major concerns people had with regards to the >> extension in the previous discussion earlier during the year. >> >> >> The extension is now self-contained and is designed not to require any >> amendments to the core WebGL spec. But since enabling the implementation of >> a zero-copy multiview pipeline is still a goal, an "opaque multiview >> framebuffer" abstraction has been added to the extension proposal. This is >> a type of a multiview framebuffer that other web APIs like WebVR would be >> able to create, and that would work also with WebGL 1.0. The specific >> shape of the WebVR API to create this type of framebuffers will still need >> to be specified within the WebVR working group. >> >> >> We have also worked on implementing functionality that would be required >> by the extension in ANGLE, and the new revision of the proposal has taken >> findings from that work into account. Particularly, we've removed >> restrictions on shaders since we found out the restrictions won't be >> necessary for good performance. On the other hand, we've added some minor >> restrictions that are required by a performant implementation on top of >> OpenGL and Direct3D, like baseViewIndex having to match between different >> framebuffer attachments. >> >> >> Regards, Olli >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsh...@ Sun Aug 20 07:53:13 2017 From: tsh...@ (Tarek Sherif) Date: Sun, 20 Aug 2017 10:53:13 -0400 Subject: [Public WebGL] Reject WEBGL_compressed_texture_atc? In-Reply-To: References: Message-ID: Hi all, I notice that WEBGL_compressed_texture_atc is still listed under "Community Approved": https://www.khronos.org/registry/webgl/extensions/ Should it not be moved to "Rejected" at this point? Tarek Sherif http://tareksherif.net/ https://www.biodigital.com/ On Thu, Feb 23, 2017 at 10:02 PM, Kenneth Russell wrote: > On Thu, Feb 23, 2017 at 5:44 PM, Florian B?sch wrote: > >> On Thu, Feb 23, 2017 at 11:26 PM, Kai Ninomiya >> wrote: >> >>> I'd like to propose that we reject the WEBGL_compressed_texture_atc >>> >>> extension. >>> >> The extension is in community approved status. The extension process >> defines that: >> >> *A community approved extension can only be rejected in extraordinary >> circumstances.* >> >> >> >>> Apparently it was widely supported at the time the extension was created >>> , >>> but it looks like now it is no longer available on AMD >>> (according >>> to the OpenGL capabilities database & on my own machine) making it only >>> possible to implement on Qualcomm devices. Since there are other, newer >>> compressed texture formats available on Qualcomm, this extension seems >>> pretty useless. >>> >>> The AMD_compressed_ATC_texture spec >>> >>> is very old and underspecified. This is creating quite a bit of maintenance >>> work for the conformance tests and browsers - the tests fail currently on >>> Qualcomm (the only platform where they're available), despite Qualcomm >>> seeming to conform to the underspecified spec. >>> >>> Are there any objections to rejecting this extension? >>> >> >> I'll summarize the circumstances for the reason for rejection thus: >> >> 1. Only marginally supported by hardware >> 2. Badly specified upstream >> 3. Unreliable when actually used >> >> Do these conditions meet the criteria of "extraordinary circumstances"? >> If so, how can we avoid promoting extensions to community approved in the >> future that would befall the same fate? >> > > In my opinion, the current situation does meet this criterion. > > The difficulty with this extension is that support for it has dwindled. > The underlying extension is ambiguous with respect to important > constraints, like whether texture sub-updates must occur on block > boundaries, and errors generated in boundary cases. > > The associated conformance tests are failing on the only device we have > which claims support for the format, so we can't validate against a second > implementation to know whether these are bugs in the driver, test, browser, > etc. > > We could simply stop claiming support for this extension in our browser, > but that's not helpful to the community, because the next browser that > attempts to reach conformance on similar devices will run into the same > problem. > > It's for this reason that I am proposing rejecting this extension at this > late date. It's the only way that we can remove the problematic, and likely > buggy, conformance test. > > Going forward, we should ensure that extensions have robust multi-platform > support, and that the conformance tests have been verified to pass on > multiple platforms, before moving them to community approved. > > > > A brief history of this extension: >> >> - Introduced by Benoit Jacob in 2012 as draft (back then the proposal >> status didn't exist). A poll for objections on the ML didn't net any >> response or objection so after 3 days it was put into draft status. >> - No discussion of atc happened at all for 2 years, support status >> remains marginal. >> - Proposed to move to community approved by Kenneth Russel in 2014 it >> got swept up in an effort to promote several draft extensions prior to iOS >> gaining WebGL support. Jeff Gilbert, Brandon Jones and Dean Jackson replied >> to the poll in favor to community approve, and one day later Kenneth moved >> these extensions (including atc) to community approved. >> - No discussion of atc happened at all for the next 3 years (which >> brings us to today) >> >> I believe that a pattern is discernible here: >> >> 1. No rigorous discussion seems to occur on the extension >> 2. Moving from one status to another is quickly enacted after only >> brief polling periods >> 3. Participants in what little communication there is are not diverse >> (only seem to include UA vendors) >> 4. Years after its introduction the extension is largely unsupported >> 5. The extension gets lumped together with others instead of getting >> the attention it should have gotten. >> >> From this I believe we can formulate a guideline on how to avoid this >> situation: >> >> 1. If an extension isn't announced on the ML or isn't discussed at >> all, then the quality of any poll for consent is suspect. >> 2. It should only move to a new status after a grace period that >> should be somewhat longer than a few days (maybe a month or two?) >> 3. It would be preferable if input from multiple constituents is >> present, and if that is lacking, calls should be made to those constituents >> to render an opinion. >> 4. If an extension lingers with barely any support, it might indicate >> trouble and should be investigated. >> 5. An extension status change should not be lumped together with >> others, for it could obscure issues in the status change. >> >> I apologize that I and we have rushed these extensions in the past. We'll > try to do a better job going forward of giving things sufficient bake time > in the community. > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Mon Aug 21 01:02:34 2017 From: oet...@ (Olli Etuaho) Date: Mon, 21 Aug 2017 08:02:34 +0000 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal In-Reply-To: References: <1503061978259.23138@nvidia.com> , Message-ID: <1503302554367.17832@nvidia.com> In WebGL 1.0, only opaque multiview framebuffers can be supported. Texture array multiview framebuffers are available starting from WebGL 2.0. Creating depth/stencil textures is also possible in WebGL 2.0, so the need for depth-testing is covered. I'll clarify this in the WEBGL_multiview proposal. You may have misunderstood the native OVR_multiview spec a bit. The baseViewIndex only affects which texture layers get affected by drawing commands. There can still only be one attachment per attachment point. So if you call int baseViewIndex = 7; int numViews = 2; FramebufferTextureMultiviewOVR(target, GL_COLOR_ATTACHMENT0, texture, level, baseViewIndex, numViews); it means that texture layers 7 and 8 will be drawn to. This should be evident from the pseudocode in the spec. -Olli ________________________________ From: Florian B?sch Sent: Friday, August 18, 2017 4:46 PM To: Olli Etuaho Cc: Public WebGL (public_webgl...@) Subject: Re: [Public WebGL] Public review of updated WEBGL_multiview extension proposal P.S. I'm assuming of course that it's self evident that rendering with depth-testing (and hence the presence of a depth buffer) is something that's rather often what people will want to do. On Fri, Aug 18, 2017 at 3:41 PM, Florian B?sch > wrote: I'm a little confused by the example. In the example you do: gl.bindTexture(gl.TEXTURE_2D_ARRAY, tex); gl.texStorage3D(gl.TEXTURE_2D_ARRAY, 1, gl.RGBA8, 512, 512, 2); But the specification states that: Written against the WebGL API 1.0 specification. Which confuses me because WebGL 1.0 does not support 2D texture arrays, nor is there an extension for it. I also don't see how you'd attach a dual depth or stencil buffer that way (since there is no such thing as a depth buffer array or stencil buffer array). To my understanding the OVR_multiview extension regulates the presence of multiple attachments of the same type (but for different views) with the parameter to FramebufferTextureMultiviewOVR baseViewIndex. Though I also fail to see how mechanism would account for multiple depth/stencil buffers because those would be attached with the function framebufferRenderbuffer and that function does not support multiple attachment points. TL;DR: 1. How is it going to work in WebGL 1 which it claims to be written against using array textures which don't exist in WebGL1? 2. How are you going to attach a multiview depthbuffer when neither the OVR_multiview extension nor this extension makes any provision for it? On Fri, Aug 18, 2017 at 3:12 PM, Olli Etuaho > wrote: Hello all! We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft: https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/? I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year. The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group. We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments. Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 21 04:16:46 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 21 Aug 2017 13:16:46 +0200 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal In-Reply-To: <1503302554367.17832@nvidia.com> References: <1503061978259.23138@nvidia.com> <1503302554367.17832@nvidia.com> Message-ID: On Mon, Aug 21, 2017 at 10:02 AM, Olli Etuaho wrote: > In WebGL 1.0, only opaque multiview framebuffers can be supported. Texture > array multiview framebuffers are available starting from WebGL 2.0. > Bit of a bummer since WebGL 2.0 has flatlined at ~30% and isn't growing and WebGL 1.0 for now is the only feasible platform. The prevalence of the OVR_multiview extensions on mobiles also seems particularly poor. > You may have misunderstood the native OVR_multiview spec a bit. The > baseViewIndex only affects which texture layers get affected by drawing > commands. There can still only be one attachment per attachment point. So > if you call > > > int baseViewIndex = 7; > > int numViews = 2; > > FramebufferTextureMultiviewOVR(target, GL_COLOR_ATTACHMENT0, texture, > level, baseViewIndex, numViews); > > it means that texture layers 7 and 8 will be drawn to. This should be > evident from the pseudocode in the spec. > I see. Some additional questions: - Does it work with depth textures? - Does it work with multi render targets? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Mon Aug 21 08:02:22 2017 From: oet...@ (Olli Etuaho) Date: Mon, 21 Aug 2017 15:02:22 +0000 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal In-Reply-To: References: <1503061978259.23138@nvidia.com> <1503302554367.17832@nvidia.com>, Message-ID: <1503327742521.40267@nvidia.com> Yes, it's intended to work with both depth textures and multiple render targets. All color attachments that are attached with framebufferTextureMultiviewWebGL will be rendered to. I do agree that WebGL 1.0 support is useful, though WebGL 2.0 support will surely ramp up given time. The main use case of the extension is VR, and especially on devices which are VR capable I'd expect widespread support for WebGL 2.0 already. We did consider some other alternatives for WebGL 1.0 compatibility for the proposal, but they all seemed fairly hacky. I don't think we want to expose rendering two viewports side by side in a 2D texture for example. -Olli ________________________________ From: Florian B?sch Sent: Monday, August 21, 2017 2:16 PM To: Olli Etuaho Cc: Public WebGL (public_webgl...@) Subject: Re: [Public WebGL] Public review of updated WEBGL_multiview extension proposal On Mon, Aug 21, 2017 at 10:02 AM, Olli Etuaho > wrote: In WebGL 1.0, only opaque multiview framebuffers can be supported. Texture array multiview framebuffers are available starting from WebGL 2.0. Bit of a bummer since WebGL 2.0 has flatlined at ~30% and isn't growing and WebGL 1.0 for now is the only feasible platform. The prevalence of the OVR_multiview extensions on mobiles also seems particularly poor. You may have misunderstood the native OVR_multiview spec a bit. The baseViewIndex only affects which texture layers get affected by drawing commands. There can still only be one attachment per attachment point. So if you call int baseViewIndex = 7; int numViews = 2; FramebufferTextureMultiviewOVR(target, GL_COLOR_ATTACHMENT0, texture, level, baseViewIndex, numViews); it means that texture layers 7 and 8 will be drawn to. This should be evident from the pseudocode in the spec. I see. Some additional questions: * Does it work with depth textures? * Does it work with multi render targets? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Aug 21 09:18:41 2017 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 21 Aug 2017 18:18:41 +0200 Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal In-Reply-To: <1503327742521.40267@nvidia.com> References: <1503061978259.23138@nvidia.com> <1503302554367.17832@nvidia.com> <1503327742521.40267@nvidia.com> Message-ID: On Mon, Aug 21, 2017 at 5:02 PM, Olli Etuaho wrote: > > I do agree that WebGL 1.0 support is useful, though WebGL 2.0 support will > surely ramp up given time. The main use case of the extension is VR, and > especially on devices which are VR capable I'd expect widespread support > for WebGL 2.0 already. > Of the top 10 performing mobile devices OVR_multiview support is: - Nvidia Shield Android TV: NO - Google Pixel C (tegra): NO - Samsung Galaxy S8 (Mali-G71): yes - Nubia Z17 (Adreno 540): yes - ZenFone 4 Pro (Adreno 530): yes - OnePlus 5 (Adreno 540): yes - Moto Z2 (Adreno 540): yes - Sony Xperia XZ Premium (Adreno 540): yes - Essential PH-1 (Adreno 540): yes - Xiaomi MI 6 (Adreno 540): yes I can't help but notice that the big gap in that picture is the fault of Google/Nvidia. It's a bit confusing since Nvidia was a major contributor to OVR_multivew spec along with Oculus, Qualcomm and Google. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Thu Aug 24 14:29:51 2017 From: Raf...@ (Rafael Cintron) Date: Thu, 24 Aug 2017 21:29:51 +0000 Subject: [Public WebGL] RE: Public review of updated WEBGL_multiview extension proposal In-Reply-To: <1503061978259.23138@nvidia.com> References: <1503061978259.23138@nvidia.com> Message-ID: I am very supportive of the Multiview extension. I think it will definitely help WebVR scenarios. One aspect of the API that could use improvement is the following statement: ?The error INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and CopyTexSubImage*, if the number of views in the current read framebuffer is greater than 1.? ReadPixels and CopyTexImage* are frequently used in test code to ensure correct rendering. Without these APIs, writing these types of tests will be challenging. Perhaps a future (or current?) version of the extension could add overloads to these functions that contain an additional ?view? integer parameter that specifies the view on which to perform the operation. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Olli Etuaho Sent: Friday, August 18, 2017 6:13 AM To: Public WebGL (public_webgl...@) Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal Hello all! We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft: https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/? I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year. The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group. We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments. Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Thu Aug 24 18:49:46 2017 From: Raf...@ (Rafael Cintron) Date: Fri, 25 Aug 2017 01:49:46 +0000 Subject: [Public WebGL] Re: Public review of updated WEBGL_multiview extension proposal In-Reply-To: References: <1503061978259.23138@nvidia.com>, Message-ID: The overloads could go on the extension object instead of WebGLRenderingContext. --Rafael ________________________________ From: owners-public_webgl...@ on behalf of Rafael Cintron Sent: Thursday, August 24, 2017 2:29:51 PM To: Olli Etuaho; Public WebGL (public_webgl...@) Subject: [Public WebGL] RE: Public review of updated WEBGL_multiview extension proposal This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing Feedback I am very supportive of the Multiview extension. I think it will definitely help WebVR scenarios. One aspect of the API that could use improvement is the following statement: ?The error INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and CopyTexSubImage*, if the number of views in the current read framebuffer is greater than 1.? ReadPixels and CopyTexImage* are frequently used in test code to ensure correct rendering. Without these APIs, writing these types of tests will be challenging. Perhaps a future (or current?) version of the extension could add overloads to these functions that contain an additional ?view? integer parameter that specifies the view on which to perform the operation. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Olli Etuaho Sent: Friday, August 18, 2017 6:13 AM To: Public WebGL (public_webgl...@) Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal Hello all! We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft: https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/? I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year. The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group. We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments. Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Fri Aug 25 03:33:45 2017 From: oet...@ (Olli Etuaho) Date: Fri, 25 Aug 2017 10:33:45 +0000 Subject: [Public WebGL] Re: Public review of updated WEBGL_multiview extension proposal In-Reply-To: References: <1503061978259.23138@nvidia.com>,, Message-ID: <1503657225595.47098@nvidia.com> Thanks for the feedback Rafael, the need for reads is intended to be covered like this by the current spec: 1) For texture array multiview framebuffers: You can read the layers by creating another framebuffer to use as a read framebuffer, and attach the layer you want to read with framebufferTextureLayer. 2) For opaque multiview framebuffers: Wherever the capability to generate opaque multiview framebuffers is added to a web API, the API can also provide the capability to generate secondary opaque multiview framebuffers with 1 view that point to the same underlying memory. Then the reads could be done using these secondary framebuffers. Of course 2) does leave more work to be done by other web APIs - so it is a bit of a trade-off. My proposal here also means that you can't implement a function readMultiviewFramebuffer(fbo) that would work for both texture array and opaque multiview framebuffers. So maybe having a readPixels variant that takes a view index would be better, but I wanted to make sure this other alternative is understood before we start inventing additional API entry points that diverge from the native OVR_multiview spec. -Olli ________________________________ From: Rafael Cintron Sent: Friday, August 25, 2017 4:49 AM To: Olli Etuaho; Public WebGL (public_webgl...@) Subject: Re: Public review of updated WEBGL_multiview extension proposal The overloads could go on the extension object instead of WebGLRenderingContext. --Rafael ________________________________ From: owners-public_webgl...@ on behalf of Rafael Cintron Sent: Thursday, August 24, 2017 2:29:51 PM To: Olli Etuaho; Public WebGL (public_webgl...@) Subject: [Public WebGL] RE: Public review of updated WEBGL_multiview extension proposal This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing Feedback I am very supportive of the Multiview extension. I think it will definitely help WebVR scenarios. One aspect of the API that could use improvement is the following statement: ?The error INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and CopyTexSubImage*, if the number of views in the current read framebuffer is greater than 1.? ReadPixels and CopyTexImage* are frequently used in test code to ensure correct rendering. Without these APIs, writing these types of tests will be challenging. Perhaps a future (or current?) version of the extension could add overloads to these functions that contain an additional ?view? integer parameter that specifies the view on which to perform the operation. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Olli Etuaho Sent: Friday, August 18, 2017 6:13 AM To: Public WebGL (public_webgl...@) Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal Hello all! We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft: https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/? I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year. The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group. We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments. Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Tue Aug 29 17:40:54 2017 From: Raf...@ (Rafael Cintron) Date: Wed, 30 Aug 2017 00:40:54 +0000 Subject: [Public WebGL] RE: Public review of updated WEBGL_multiview extension proposal In-Reply-To: <1503657225595.47098@nvidia.com> References: <1503061978259.23138@nvidia.com>,, <1503657225595.47098@nvidia.com> Message-ID: Thank you for explaining the other variants. I still think having a readPixels/copyTexImage2D on the extension object would be the best for web developers. From an implementation perspective, I think the component that should implement readpixels/copyTexImage2D for Multiview would be ANGLE since it already handles the scissor, viewport, etc adjustments on behalf of the outer code. --Rafael From: Olli Etuaho [mailto:oetuaho...@] Sent: Friday, August 25, 2017 3:34 AM To: Rafael Cintron ; Public WebGL (public_webgl...@) Subject: Re: Public review of updated WEBGL_multiview extension proposal Thanks for the feedback Rafael, the need for reads is intended to be covered like this by the current spec: 1) For texture array multiview framebuffers: You can read the layers by creating another framebuffer to use as a read framebuffer, and attach the layer you want to read with framebufferTextureLayer. 2) For opaque multiview framebuffers: Wherever the capability to generate opaque multiview framebuffers is added to a web API, the API can also provide the capability to generate secondary opaque multiview framebuffers with 1 view that point to the same underlying memory. Then the reads could be done using these secondary framebuffers. Of course 2) does leave more work to be done by other web APIs - so it is a bit of a trade-off. My proposal here also means that you can't implement a function readMultiviewFramebuffer(fbo) that would work for both texture array and opaque multiview framebuffers. So maybe having a readPixels variant that takes a view index would be better, but I wanted to make sure this other alternative is understood before we start inventing additional API entry points that diverge from the native OVR_multiview spec. -Olli ________________________________ From: Rafael Cintron > Sent: Friday, August 25, 2017 4:49 AM To: Olli Etuaho; Public WebGL (public_webgl...@) Subject: Re: Public review of updated WEBGL_multiview extension proposal The overloads could go on the extension object instead of WebGLRenderingContext. --Rafael ________________________________ From: owners-public_webgl...@ > on behalf of Rafael Cintron > Sent: Thursday, August 24, 2017 2:29:51 PM To: Olli Etuaho; Public WebGL (public_webgl...@) Subject: [Public WebGL] RE: Public review of updated WEBGL_multiview extension proposal This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing Feedback I am very supportive of the Multiview extension. I think it will definitely help WebVR scenarios. One aspect of the API that could use improvement is the following statement: ?The error INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and CopyTexSubImage*, if the number of views in the current read framebuffer is greater than 1.? ReadPixels and CopyTexImage* are frequently used in test code to ensure correct rendering. Without these APIs, writing these types of tests will be challenging. Perhaps a future (or current?) version of the extension could add overloads to these functions that contain an additional ?view? integer parameter that specifies the view on which to perform the operation. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Olli Etuaho Sent: Friday, August 18, 2017 6:13 AM To: Public WebGL (public_webgl...@) > Subject: [Public WebGL] Public review of updated WEBGL_multiview extension proposal Hello all! We have a significantly updated version of the WEBGL_multiview extension proposal, and kindly request the community's feedback on it so we can incorporate the feedback and proceed to move the extension to draft: https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_multiview/? I hope this addresses the major concerns people had with regards to the extension in the previous discussion earlier during the year. The extension is now self-contained and is designed not to require any amendments to the core WebGL spec. But since enabling the implementation of a zero-copy multiview pipeline is still a goal, an "opaque multiview framebuffer" abstraction has been added to the extension proposal. This is a type of a multiview framebuffer that other web APIs like WebVR would be able to create, and that would work also with WebGL 1.0. The specific shape of the WebVR API to create this type of framebuffers will still need to be specified within the WebVR working group. We have also worked on implementing functionality that would be required by the extension in ANGLE, and the new revision of the proposal has taken findings from that work into account. Particularly, we've removed restrictions on shaders since we found out the restrictions won't be necessary for good performance. On the other hand, we've added some minor restrictions that are required by a performant implementation on top of OpenGL and Direct3D, like baseViewIndex having to match between different framebuffer attachments. Regards, Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: