From dmi...@ Tue Sep 8 07:27:24 2015 From: dmi...@ (=?koi8-r?B?68nSyczMIOTNydTSxc7Lzw==?=) Date: Tue, 08 Sep 2015 17:27:24 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL Message-ID: <23731441722444@webcorp02f.yandex-team.ru> Greetings! I'm digging into ANGLE and how it works. Recently I've read in the WebGL Insights book that ANGLE doesn't really like when an application changes dimensions or mipmapping of a texture. If I understand it correctly, that is due to the fact that D3D doesn't allow to change texture parameters once it's created. Also, there is a note in the book that texStorage* calls allow ANGLE to overcome this problem (in other words, handle textures more efficiently). But why don't we have those calls as an extension to WebGL, i.e. ARB_texture_storage? -- 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 pya...@ Tue Sep 8 07:57:54 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 8 Sep 2015 16:57:54 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <23731441722444@webcorp02f.yandex-team.ru> References: <23731441722444@webcorp02f.yandex-team.ru> Message-ID: The texStorage family of calls are introduced by these extensions: - ES https://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_storage.txt - GL https://www.opengl.org/registry/specs/ARB/texture_storage.txt They become core functionality in OpenGL ES 3.0 (and hence WebGL 2.0) The reason these calls don't exist in WebGL 1 is because they are not core functionality in OpenGL ES 2.0, and because so far nobody asked for them or wrote an extension specification for them. You could draft a WebGL extension specification to mirror EXT_texture_storage so that these calls could be implemented for WebGL 1.0. However UA maintainers have often cited resource shortage as a reason to strike down extension implementation, instead rather focusing on WebGL 2.0. I personally don't believe that to be a good argument against some functionality. If the problem is resource shortage, the solution isn't doing less, it's to acquire more resources. On Tue, Sep 8, 2015 at 4:27 PM, ?????? ????????? wrote: > > Greetings! > > I'm digging into ANGLE and how it works. Recently I've read in the WebGL > Insights book that ANGLE doesn't really like when an application > changes dimensions or mipmapping of a texture. If I understand it > correctly, that is due to the fact that D3D doesn't allow to change texture > parameters once it's created. Also, there is a note in the book that > texStorage* calls allow ANGLE to overcome this problem (in other words, > handle textures more efficiently). But why don't we have those calls as an > extension to WebGL, i.e. ARB_texture_storage? > > -- > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Tue Sep 8 08:06:45 2015 From: ash...@ (Ashley Gullen) Date: Tue, 8 Sep 2015 16:06:45 +0100 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> Message-ID: I think the main reason against making a WebGL 1 extension for something that is supported in WebGL 2 is because WebGL 2 implementations are already in the works, so this will happen eventually anyway. On 8 September 2015 at 15:57, Florian B?sch wrote: > The texStorage family of calls are introduced by these extensions: > > - ES > https://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_storage.txt > - GL https://www.opengl.org/registry/specs/ARB/texture_storage.txt > > They become core functionality in OpenGL ES 3.0 (and hence WebGL 2.0) > > The reason these calls don't exist in WebGL 1 is because they are not core > functionality in OpenGL ES 2.0, and because so far nobody asked for them or > wrote an extension specification for them. > > You could draft a WebGL extension specification to mirror > EXT_texture_storage so that these calls could be implemented for WebGL 1.0. > However UA maintainers have often cited resource shortage as a reason to > strike down extension implementation, instead rather focusing on WebGL 2.0. > I personally don't believe that to be a good argument against some > functionality. If the problem is resource shortage, the solution isn't > doing less, it's to acquire more resources. > > On Tue, Sep 8, 2015 at 4:27 PM, ?????? ????????? > wrote: > >> >> Greetings! >> >> I'm digging into ANGLE and how it works. Recently I've read in the WebGL >> Insights book that ANGLE doesn't really like when an application >> changes dimensions or mipmapping of a texture. If I understand it >> correctly, that is due to the fact that D3D doesn't allow to change texture >> parameters once it's created. Also, there is a note in the book that >> texStorage* calls allow ANGLE to overcome this problem (in other words, >> handle textures more efficiently). But why don't we have those calls as an >> extension to WebGL, i.e. ARB_texture_storage? >> >> -- >> 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 >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Tue Sep 8 08:42:47 2015 From: chr...@ (Christophe Riccio) Date: Tue, 8 Sep 2015 17:42:47 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> Message-ID: My understanding as well is that WebGL 1 and WebGL 2 are going to remains separated implementations in WebGL browsers and that because of ecosystem reality. the WebGL 2.0 ecosystem is only going to include a subset of the WebGL 1 ecosystem. So if there is a measurable benefit for texture storage and considering that it's a software extensions only which is supported by most desktop and mobile (included ES2 implementation) platforms, I think it should be considered. On Tue, Sep 8, 2015 at 5:06 PM, Ashley Gullen wrote: > I think the main reason against making a WebGL 1 extension for something > that is supported in WebGL 2 is because WebGL 2 implementations are already > in the works, so this will happen eventually anyway. > > > On 8 September 2015 at 15:57, Florian B?sch wrote: > >> The texStorage family of calls are introduced by these extensions: >> >> - ES >> https://www.khronos.org/registry/gles/extensions/EXT/EXT_texture_storage.txt >> - GL https://www.opengl.org/registry/specs/ARB/texture_storage.txt >> >> They become core functionality in OpenGL ES 3.0 (and hence WebGL 2.0) >> >> The reason these calls don't exist in WebGL 1 is because they are not >> core functionality in OpenGL ES 2.0, and because so far nobody asked for >> them or wrote an extension specification for them. >> >> You could draft a WebGL extension specification to mirror >> EXT_texture_storage so that these calls could be implemented for WebGL 1.0. >> However UA maintainers have often cited resource shortage as a reason to >> strike down extension implementation, instead rather focusing on WebGL 2.0. >> I personally don't believe that to be a good argument against some >> functionality. If the problem is resource shortage, the solution isn't >> doing less, it's to acquire more resources. >> >> On Tue, Sep 8, 2015 at 4:27 PM, ?????? ????????? >> wrote: >> >>> >>> Greetings! >>> >>> I'm digging into ANGLE and how it works. Recently I've read in the WebGL >>> Insights book that ANGLE doesn't really like when an application >>> changes dimensions or mipmapping of a texture. If I understand it >>> correctly, that is due to the fact that D3D doesn't allow to change texture >>> parameters once it's created. Also, there is a note in the book that >>> texStorage* calls allow ANGLE to overcome this problem (in other words, >>> handle textures more efficiently). But why don't we have those calls as an >>> extension to WebGL, i.e. ARB_texture_storage? >>> >>> -- >>> 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 >>> ----------------------------------------------------------- >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Sep 8 08:49:29 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 8 Sep 2015 17:49:29 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> Message-ID: On Tue, Sep 8, 2015 at 5:06 PM, Ashley Gullen wrote: > I think the main reason against making a WebGL 1 extension for something > that is supported in WebGL 2 is because WebGL 2 implementations are already > in the works, so this will happen eventually anyway. > The main reasons for including stuff into WebGL1 that's included in WebGL2 is: - Because it's obviously useful - It eases forwards compatibility issues for going from WebGL1 to WebGL2 - It eases backwards compatibility issues for supporting WebGL1 - Since WebGL2 will not be available for a long time in many places, it provides at least a path for UAs to bring more WebGL2 features to their WebGL1 implementations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Tue Sep 8 09:06:42 2015 From: khr...@ (Mark Callow) Date: Tue, 8 Sep 2015 09:06:42 -0700 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <23731441722444@webcorp02f.yandex-team.ru> References: <23731441722444@webcorp02f.yandex-team.ru> Message-ID: <17CDDC01-7CD8-489A-AEC2-076F5D8CECAD@callow.im> > On Sep 8, 2015, at 7:27 AM, ?????? ????????? wrote: > > > Greetings! > > I'm digging into ANGLE and how it works. Recently I've read in the WebGL Insights book that ANGLE doesn't really like when an application > changes dimensions or mipmapping of a texture. If I understand it correctly, that is due to the fact that D3D doesn't allow to change texture parameters once it's created. Also, there is a note in the book that texStorage* calls allow ANGLE to overcome this problem (in other words, handle textures more efficiently). But why don't we have those calls as an extension to WebGL, i.e. ARB_texture_storage? > ARB_texture_storage does not solve the general problem of changing dimensions and mipmapping of a texture whenever you want. What it does solve is that it allows the application to provide all the information about the shape and format of the texture up front before you load any data. Once created these things cannot be changed. Hence the problem texture_storage solves is to remove the need for changes when making textures that differ from defaults set when a texture is created by gl.bindTexture. However this problem can be largely alleviated by the implementation by lazy creation of its internal texture structures. That is, waiting until the first call to gl.texImage*D before creating them. So texture_storage is really about allowing simpler drivers. The problem is not unique to ANGLE which is why the extension exists. 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...@ Tue Sep 8 09:55:30 2015 From: khr...@ (Mark Callow) Date: Tue, 8 Sep 2015 09:55:30 -0700 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <17CDDC01-7CD8-489A-AEC2-076F5D8CECAD@callow.im> References: <23731441722444@webcorp02f.yandex-team.ru> <17CDDC01-7CD8-489A-AEC2-076F5D8CECAD@callow.im> Message-ID: <019477AC-731E-45B7-9B9B-B8EF9D0CD9F1@callow.im> > On Sep 8, 2015, at 9:06 AM, Mark Callow wrote: > > ... However this problem can be largely alleviated by the implementation by lazy creation of its internal texture structures. I am being over optimistic with ?largely.". ?Somewhat? is more accurate. 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 dmi...@ Wed Sep 9 07:13:59 2015 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 09 Sep 2015 17:13:59 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <019477AC-731E-45B7-9B9B-B8EF9D0CD9F1@callow.im> References: <23731441722444@webcorp02f.yandex-team.ru> <17CDDC01-7CD8-489A-AEC2-076F5D8CECAD@callow.im> <019477AC-731E-45B7-9B9B-B8EF9D0CD9F1@callow.im> Message-ID: <12751441808039@webcorp01h.yandex-team.ru> AFAIK it's already been implemented in ANGLE: underlying D3D texture object are created only when a draw call issued. But that's kinda diminishes the whole 'create textures upon init' thing: no matter what you do, a texture will be created during a draw call. Whereas texStorage* allocates corresponding D3D object "synchronously". 08.09.2015, 19:55, "Mark Callow" : >> ?On Sep 8, 2015, at 9:06 AM, Mark Callow wrote: >> >> ?... However this problem can be largely alleviated by the implementation by lazy creation of its internal texture structures. > > I am being over optimistic with ?largely.". ?Somewhat? is more accurate. > > Regards > > ????-Mark -- 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 juj...@ Wed Sep 9 07:24:52 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Wed, 9 Sep 2015 17:24:52 +0300 Subject: [Public WebGL] How does WebGL 2 deal with GLint64 type? Message-ID: Reading the current WebGL 2 spec at https://www.khronos.org/registry/webgl/specs/latest/2.0/ , it introduces a new type GLint64. How does that behave when JavaScript does not currently(yet) have a 64-bit int value type? Cheers, Jukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Wed Sep 9 07:25:40 2015 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 09 Sep 2015 17:25:40 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> Message-ID: <64021441808740@webcorp01f.yandex-team.ru> An HTML attachment was scrubbed... URL: From pya...@ Wed Sep 9 07:41:45 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 9 Sep 2015 16:41:45 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <64021441808740@webcorp01f.yandex-team.ru> References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> Message-ID: On Wed, Sep 9, 2015 at 4:25 PM, Kirill Dmitrenko wrote: > I think that would be strange: WebGL 2 mainly compatible with WebGL 1, > i.e. sensible code written against WebGL 1 spec should work the same way > for WebGL2 context. Thus it makes more sense to have only WebGL 2 > implementation and always return WebGL 2 context, even if WebGL 1 was > requested. This approach works for desktop OpenGL and OpenGL ES, I see no > reason why it can't work for WebGL. > > PS. Perhaps, it would be right to make WebGL 2 *completely* upward > compatible with WebGL 1 > There's a bunch of extension in WebGL1 which will not exist in WebGL2 because they've become core functionality. At best peoples app will suddenly lack the extra functionality, and at worst they will break (tsk-tsk). We wouldn't want that, so no. it's getContext for either 'webgl' or 'webgl2'. Nevertheless it's worthwhile to provide functionality to WebGL1 that exist in WebGL2 because WebGL2 implementations will have considerable lag and need to climb a long ramp of adoption. But we do want people do use WebGL2 as much as is possible. The best way to do that is to make backwards support and forward support as smooth as possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Wed Sep 9 07:51:08 2015 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 09 Sep 2015 17:51:08 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> Message-ID: <73601441810268@webcorp02f.yandex-team.ru> An HTML attachment was scrubbed... URL: From khr...@ Wed Sep 9 13:05:53 2015 From: khr...@ (Mark Callow) Date: Wed, 9 Sep 2015 13:05:53 -0700 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <12751441808039@webcorp01h.yandex-team.ru> References: <23731441722444@webcorp02f.yandex-team.ru> <17CDDC01-7CD8-489A-AEC2-076F5D8CECAD@callow.im> <019477AC-731E-45B7-9B9B-B8EF9D0CD9F1@callow.im> <12751441808039@webcorp01h.yandex-team.ru> Message-ID: <112D1F6F-C51A-4751-8161-328228856FF1@callow.im> > On Sep 9, 2015, at 7:13 AM, Kirill Dmitrenko wrote: > > AFAIK it's already been implemented in ANGLE: underlying D3D texture object are created only when a draw call issued. But that's kinda diminishes the whole 'create textures upon init' thing: no matter what you do, a texture will be created during a draw call. Whereas texStorage* allocates corresponding D3D object "synchronously?. Solving this problem is the reason tex_storage was created though not specifically for ANGLE. From your initial post I thought you were looking for something that would let you change texture dimensions, format and mipmap levels at low cost whenever you wanted, something tex_storage does not solve. I think now that I misinterpreted your post. 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...@ Wed Sep 9 13:14:35 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 9 Sep 2015 22:14:35 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <73601441810268@webcorp02f.yandex-team.ru> References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> Message-ID: On Wed, Sep 9, 2015 at 4:51 PM, Kirill Dmitrenko wrote: > Are there any arguments against keeping "copies" of WebGL 2 method as > WebGL 1 extension method? > The main arguments against are: 1. The functionality will eventually arrive anyway with WebGL2 2. Because 1. and resources are tight so lets concentrate on 1. WebGL2 will not arrive shortly to everywhere. As the year draws slowly to a close, it becomes less likely we'll see any publicly released WebGL2 implementation. WebGL2 implementations will arrive slowly, and updates to UAs that implement them will appear slower on some platforms than on others (Android, Edge and iOS will take forever). It is my estimate that it will take until 2020 before we'll see an activation rate > 80% for WebGL2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Sep 9 13:25:34 2015 From: jgi...@ (Jeff Gilbert) Date: Wed, 9 Sep 2015 13:25:34 -0700 Subject: [Public WebGL] How does WebGL 2 deal with GLint64 type? In-Reply-To: References: Message-ID: We follow what the webidl types are spec'd to do, which I believe is practically just converting js::Number <-> GLint64. Accuracy suffers past 2^53, but that's true of all math in JS. On Wed, Sep 9, 2015 at 7:24 AM, Jukka Jyl?nki wrote: > Reading the current WebGL 2 spec at > https://www.khronos.org/registry/webgl/specs/latest/2.0/ , it introduces > a new type GLint64. > > How does that behave when JavaScript does not currently(yet) have a 64-bit > int value type? > > Cheers, > Jukka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Wed Sep 9 14:04:56 2015 From: zmo...@ (Zhenyao Mo) Date: Wed, 9 Sep 2015 14:04:56 -0700 Subject: [Public WebGL] How does WebGL 2 deal with GLint64 type? In-Reply-To: References: Message-ID: And in Chrome, currently our command buffer supports only 32 bit, so any GLint64 parameters that receives a value that exceeds 32bit, you get an INVALID_VALUE error. On Wed, Sep 9, 2015 at 1:25 PM, Jeff Gilbert wrote: > We follow what the webidl types are spec'd to do, which I believe is > practically just converting js::Number <-> GLint64. Accuracy suffers past > 2^53, but that's true of all math in JS. > > On Wed, Sep 9, 2015 at 7:24 AM, Jukka Jyl?nki wrote: >> >> Reading the current WebGL 2 spec at >> https://www.khronos.org/registry/webgl/specs/latest/2.0/ , it introduces a >> new type GLint64. >> >> How does that behave when JavaScript does not currently(yet) have a 64-bit >> int value type? >> >> Cheers, >> Jukka > > ----------------------------------------------------------- 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 zmo...@ Wed Sep 9 16:09:47 2015 From: zmo...@ (Zhenyao Mo) Date: Wed, 9 Sep 2015 16:09:47 -0700 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> Message-ID: We are working very hard to push out a working WebGL 2 prototype before the end of year. I agree it might be a good idea to expose TexStorage extension for WebGL 1. At least it can save memories on Windows with ANGLE backend, because to create a texture at draw time in ANGLE, we have to maintain a copy of the entire texture data in ram. If someone can help draft a extension spec, that could probably speed things up. On Wed, Sep 9, 2015 at 1:14 PM, Florian B?sch wrote: > On Wed, Sep 9, 2015 at 4:51 PM, Kirill Dmitrenko > wrote: >> >> Are there any arguments against keeping "copies" of WebGL 2 method as >> WebGL 1 extension method? > > The main arguments against are: > > The functionality will eventually arrive anyway with WebGL2 > Because 1. and resources are tight so lets concentrate on 1. > > WebGL2 will not arrive shortly to everywhere. As the year draws slowly to a > close, it becomes less likely we'll see any publicly released WebGL2 > implementation. WebGL2 implementations will arrive slowly, and updates to > UAs that implement them will appear slower on some platforms than on others > (Android, Edge and iOS will take forever). > > It is my estimate that it will take until 2020 before we'll see an > activation rate > 80% for WebGL2. ----------------------------------------------------------- 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 Sep 10 01:35:16 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 10 Sep 2015 10:35:16 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> Message-ID: On Thu, Sep 10, 2015 at 1:09 AM, Zhenyao Mo wrote: > We are working very hard to push out a working WebGL 2 prototype > before the end of year. > There's no doubt that you do. I'm just pointing out the realities of adoption. I started measuring WebGL activation rate early 2012: - 2011: (at a rough guestimate) ~30% - 2012: 60% - 2013: 65% - 2014: 75% - 2015: 88% But that's the whole picture, different platforms differ, to wit, smartphones: - 2011: 0% - 2012: 4% - 2013: 15% - 2014: 30% - 2015: (the big apple jump) 75% But even inside a platform you get some interesting things to see, let's say android, overall the curve looks quite similar to mobiles in general (sans the apple jump), but then you get to ask, why? Well, android comes with two browsers, Chrome and Android "native" (some android vendor packaged version of chrome). To a large degree, "WebGL adoption" on android really means "Chrome adoption". To a degree this is generally true, adoption rate has some relationship to UA update rate. And UA update rates differ, wildly. - Chrome Desktop: ~1 months - Firefox Desktop: ~3 months - IE: ~3 years - Edge: ??? - Android: "it's complicated" - iOS: At most once a year (perhaps every 2) with a new iOS release, and then about 30%/year But why do we even consider mobiles as a significant factor? Well, they make around 15% of the browser landscape. Generally it seems mobiles are more timid to adopt new browser features. Although the big "desktops are dead" movement hasn't happened, mobiles are still grabbing more market share, so this put s a bit of a dent into overall UA update/WebGL adoption long as they're lagging. Of course there's also hardware to consider. A lot of mobiles do have ES 3.0 support, but also a lot of them don't. So how fast does hardware update? I can derive a rough guesstimate from that from the max texture size. Let's consider 8k textures as a watermark on desktops: - 2013: 68% - 2014: 76% - 2015: 89% So how does that look on mobiles? We have to consider 4k textures there as the watermark: - 2013: 94% - 2014: 98% - 2015: 100% >From this you can derive a rough guesstimate how fast actual hardware in the wild turns over. And my guess here is that about 10% of desktop GPUs get replaced every year, and about 5% of mobiles. So what is ES 3.0 support on mobiles today? Well Unity thinks it's about 4%. The bottom line is, new WebGL 2 adoption will be long and grueling and hard to watch. It will happen, but slowly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Sep 10 01:43:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 10 Sep 2015 10:43:05 +0200 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> Message-ID: And that's not considering the lag time it requires the various UA vendors to implement WebGL 2 in the first place. What I'm trying to convey is this: WebGL2 staggering, lagging arrival will not solve everything (tm) within any short period of time, it'll take years and years. On Thu, Sep 10, 2015 at 10:35 AM, Florian B?sch wrote: > On Thu, Sep 10, 2015 at 1:09 AM, Zhenyao Mo wrote: > >> We are working very hard to push out a working WebGL 2 prototype >> before the end of year. >> > > There's no doubt that you do. I'm just pointing out the realities of > adoption. I started measuring WebGL activation rate early 2012: > > - 2011: (at a rough guestimate) ~30% > - 2012: 60% > - 2013: 65% > - 2014: 75% > - 2015: 88% > > But that's the whole picture, different platforms differ, to wit, > smartphones: > > - 2011: 0% > - 2012: 4% > - 2013: 15% > - 2014: 30% > - 2015: (the big apple jump) 75% > > But even inside a platform you get some interesting things to see, let's > say android, overall the curve looks quite similar to mobiles in general > (sans the apple jump), but then you get to ask, why? Well, android comes > with two browsers, Chrome and Android "native" (some android vendor > packaged version of chrome). To a large degree, "WebGL adoption" on android > really means "Chrome adoption". To a degree this is generally true, > adoption rate has some relationship to UA update rate. And UA update rates > differ, wildly. > > - Chrome Desktop: ~1 months > - Firefox Desktop: ~3 months > - IE: ~3 years > - Edge: ??? > - Android: "it's complicated" > - iOS: At most once a year (perhaps every 2) with a new iOS release, > and then about 30%/year > > But why do we even consider mobiles as a significant factor? Well, they > make around 15% of the browser landscape. Generally it seems mobiles are > more timid to adopt new browser features. Although the big "desktops are > dead" movement hasn't happened, mobiles are still grabbing more market > share, so this put s a bit of a dent into overall UA update/WebGL adoption > long as they're lagging. > > Of course there's also hardware to consider. A lot of mobiles do have ES > 3.0 support, but also a lot of them don't. So how fast does hardware > update? I can derive a rough guesstimate from that from the max texture > size. Let's consider 8k textures as a watermark on desktops: > > - 2013: 68% > - 2014: 76% > - 2015: 89% > > So how does that look on mobiles? We have to consider 4k textures there as > the watermark: > > - 2013: 94% > - 2014: 98% > - 2015: 100% > > From this you can derive a rough guesstimate how fast actual hardware in > the wild turns over. And my guess here is that about 10% of desktop GPUs > get replaced every year, and about 5% of mobiles. > > So what is ES 3.0 support on mobiles today? Well Unity thinks it's about > 4%. > > The bottom line is, new WebGL 2 adoption will be long and grueling and > hard to watch. It will happen, but slowly. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Thu Sep 10 04:28:02 2015 From: dmi...@ (Kirill Dmitrenko) Date: Thu, 10 Sep 2015 14:28:02 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> Message-ID: <244961441884482@webcorp02g.yandex-team.ru> An HTML attachment was scrubbed... URL: From dmi...@ Thu Sep 10 04:30:17 2015 From: dmi...@ (Kirill Dmitrenko) Date: Thu, 10 Sep 2015 14:30:17 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> Message-ID: <245961441884617@webcorp02g.yandex-team.ru> I can give it a try. 10.09.2015, 02:09, "Zhenyao Mo" : > We are working very hard to push out a working WebGL 2 prototype > before the end of year. > > I agree it might be a good idea to expose TexStorage extension for > WebGL 1. At least it can save memories on Windows with ANGLE backend, > because to create a texture at draw time in ANGLE, we have to maintain > a copy of the entire texture data in ram. > > If someone can help draft a extension spec, that could probably speed things up. > > On Wed, Sep 9, 2015 at 1:14 PM, Florian B?sch wrote: >> ?On Wed, Sep 9, 2015 at 4:51 PM, Kirill Dmitrenko >> ?wrote: >>> ?Are there any arguments against keeping "copies" of WebGL 2 method as >>> ?WebGL 1 extension method? >> >> ?The main arguments against are: >> >> ?The functionality will eventually arrive anyway with WebGL2 >> ?Because 1. and resources are tight so lets concentrate on 1. >> >> ?WebGL2 will not arrive shortly to everywhere. As the year draws slowly to a >> ?close, it becomes less likely we'll see any publicly released WebGL2 >> ?implementation. WebGL2 implementations will arrive slowly, and updates to >> ?UAs that implement them will appear slower on some platforms than on others >> ?(Android, Edge and iOS will take forever). >> >> ?It is my estimate that it will take until 2020 before we'll see an >> ?activation rate > 80% for WebGL2. -- 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 sta...@ Thu Sep 17 14:35:56 2015 From: sta...@ (andre v) Date: Thu, 17 Sep 2015 14:35:56 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? Message-ID: I am working on a webGL game, sometimes when I demo it on a user's computer the webGL does not work (fails to create context). It would be nice to know why. Is it incompatible graphics card? Black listed OS, drivers, bios? Is it disabled in the settings? Is it some sort of underlaying openGL error? I realize that exposing this to me as a programming might be a bad idea, leaking information it shouldn't have... although I disagree... I understand the fear. But can't we display that to a user? So that they can trouble shoot their own issue? So that they don't blame me saying: "Shouldn't have used webGL, Unity is better", "Write a real game in C++", "Browser will never be a medium for real games"... Instead oh, my drivers are not up to date, oh my WaterFox has it disabled, webGL driver caused an error restart computer... At least some sort of debug flag that can help trouble shooting it during demos. Automated way would be nice, but there is also no real manual way to trouble shoot it either. My checklist is: 1. WebGL failed to create context. 2. Restart computer. (clear any bad graphics hardware state) 3. Check for browser updates. 4. Check for graphics chard drivers updates. 5. Disable extensions like Adblock, try incognito mode. Thats it? Where would I check if the graphics card/os combo is black listed? Is there any debug flag that can tell me why webGL is failing? - Andre von Houck -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Sep 17 16:03:39 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 17 Sep 2015 16:03:39 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: In Chrome, the about:gpu page usually contains useful information about why WebGL would have failed to start. We'd like to hear about situations where this happens, where it appears the user's graphics drivers are correctly installed. -Ken On Thu, Sep 17, 2015 at 2:35 PM, andre v wrote: > I am working on a webGL game, sometimes when I demo it on a user's > computer the webGL does not work (fails to create context). It would be > nice to know why. Is it incompatible graphics card? Black listed OS, > drivers, bios? Is it disabled in the settings? Is it some sort of > underlaying openGL error? > > I realize that exposing this to me as a programming might be a bad idea, > leaking information it shouldn't have... although I disagree... I > understand the fear. But can't we display that to a user? So that they can > trouble shoot their own issue? So that they don't blame me saying: > "Shouldn't have used webGL, Unity is better", "Write a real game in C++", > "Browser will never be a medium for real games"... Instead oh, my drivers > are not up to date, oh my WaterFox has it disabled, webGL driver caused an > error restart computer... At least some sort of debug flag that can help > trouble shooting it during demos. > > Automated way would be nice, but there is also no real manual way to > trouble shoot it either. My checklist is: > 1. WebGL failed to create context. > 2. Restart computer. (clear any bad graphics hardware state) > 3. Check for browser updates. > 4. Check for graphics chard drivers updates. > 5. Disable extensions like Adblock, try incognito mode. > > Thats it? Where would I check if the graphics card/os combo is black > listed? Is there any debug flag that can tell me why webGL is failing? > > - Andre von Houck > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Sep 17 16:27:07 2015 From: jgi...@ (Jeff Gilbert) Date: Thu, 17 Sep 2015 16:27:07 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: It's something we've talked about in the past. Sometimes, we decide a user's drivers aren't reliable enough to run on, and that they should update. However, there's not currently a way to surface this to the app, so the app can recommend updating drivers to the user. It would also be fantastic from a statistics point of view, being able to get stats on why WebGL is failing to load for a more general audience. On Thu, Sep 17, 2015 at 4:03 PM, Kenneth Russell wrote: > In Chrome, the about:gpu page usually contains useful information about > why WebGL would have failed to start. > > We'd like to hear about situations where this happens, where it appears > the user's graphics drivers are correctly installed. > > -Ken > > > On Thu, Sep 17, 2015 at 2:35 PM, andre v wrote: > >> I am working on a webGL game, sometimes when I demo it on a user's >> computer the webGL does not work (fails to create context). It would be >> nice to know why. Is it incompatible graphics card? Black listed OS, >> drivers, bios? Is it disabled in the settings? Is it some sort of >> underlaying openGL error? >> >> I realize that exposing this to me as a programming might be a bad idea, >> leaking information it shouldn't have... although I disagree... I >> understand the fear. But can't we display that to a user? So that they can >> trouble shoot their own issue? So that they don't blame me saying: >> "Shouldn't have used webGL, Unity is better", "Write a real game in C++", >> "Browser will never be a medium for real games"... Instead oh, my drivers >> are not up to date, oh my WaterFox has it disabled, webGL driver caused an >> error restart computer... At least some sort of debug flag that can help >> trouble shooting it during demos. >> >> Automated way would be nice, but there is also no real manual way to >> trouble shoot it either. My checklist is: >> 1. WebGL failed to create context. >> 2. Restart computer. (clear any bad graphics hardware state) >> 3. Check for browser updates. >> 4. Check for graphics chard drivers updates. >> 5. Disable extensions like Adblock, try incognito mode. >> >> Thats it? Where would I check if the graphics card/os combo is black >> listed? Is there any debug flag that can tell me why webGL is failing? >> >> - Andre von Houck >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Thu Sep 17 20:40:00 2015 From: vla...@ (Vladimir Vukicevic) Date: Thu, 17 Sep 2015 23:40:00 -0400 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: Actually, thinking about this.. we could include a context creation flag that would indicate to the UA that the page wants the user to be told if and why context creation failed. The browser would do it itself, so no information leakage, and the content has to opt-in, so content that has silent fallback can still work. Thoughts? - Vlad On Sep 17, 2015 7:27 PM, "Jeff Gilbert" wrote: > It's something we've talked about in the past. Sometimes, we decide a > user's drivers aren't reliable enough to run on, and that they should > update. However, there's not currently a way to surface this to the app, so > the app can recommend updating drivers to the user. > > It would also be fantastic from a statistics point of view, being able to > get stats on why WebGL is failing to load for a more general audience. > > On Thu, Sep 17, 2015 at 4:03 PM, Kenneth Russell wrote: > >> In Chrome, the about:gpu page usually contains useful information about >> why WebGL would have failed to start. >> >> We'd like to hear about situations where this happens, where it appears >> the user's graphics drivers are correctly installed. >> >> -Ken >> >> >> On Thu, Sep 17, 2015 at 2:35 PM, andre v wrote: >> >>> I am working on a webGL game, sometimes when I demo it on a user's >>> computer the webGL does not work (fails to create context). It would be >>> nice to know why. Is it incompatible graphics card? Black listed OS, >>> drivers, bios? Is it disabled in the settings? Is it some sort of >>> underlaying openGL error? >>> >>> I realize that exposing this to me as a programming might be a bad idea, >>> leaking information it shouldn't have... although I disagree... I >>> understand the fear. But can't we display that to a user? So that they can >>> trouble shoot their own issue? So that they don't blame me saying: >>> "Shouldn't have used webGL, Unity is better", "Write a real game in C++", >>> "Browser will never be a medium for real games"... Instead oh, my drivers >>> are not up to date, oh my WaterFox has it disabled, webGL driver caused an >>> error restart computer... At least some sort of debug flag that can help >>> trouble shooting it during demos. >>> >>> Automated way would be nice, but there is also no real manual way to >>> trouble shoot it either. My checklist is: >>> 1. WebGL failed to create context. >>> 2. Restart computer. (clear any bad graphics hardware state) >>> 3. Check for browser updates. >>> 4. Check for graphics chard drivers updates. >>> 5. Disable extensions like Adblock, try incognito mode. >>> >>> Thats it? Where would I check if the graphics card/os combo is black >>> listed? Is there any debug flag that can tell me why webGL is failing? >>> >>> - Andre von Houck >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Sep 18 01:18:08 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 18 Sep 2015 01:18:08 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: Sorry I didn't realize this before, but the webglcontextcreationerror event already contains some of this information: https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.15.4 . The precision of the statusMessage in this event was improved somewhat recently in Chrome, and could probably be improved more without giving up personally identifiable information. Andre, could you please describe some recent scenarios you've run into where WebGL failed to initialize? -Ken On Thu, Sep 17, 2015 at 8:40 PM, Vladimir Vukicevic wrote: > Actually, thinking about this.. we could include a context creation flag > that would indicate to the UA that the page wants the user to be told if > and why context creation failed. The browser would do it itself, so no > information leakage, and the content has to opt-in, so content that has > silent fallback can still work. > > Thoughts? > > - Vlad > On Sep 17, 2015 7:27 PM, "Jeff Gilbert" wrote: > >> It's something we've talked about in the past. Sometimes, we decide a >> user's drivers aren't reliable enough to run on, and that they should >> update. However, there's not currently a way to surface this to the app, so >> the app can recommend updating drivers to the user. >> >> It would also be fantastic from a statistics point of view, being able to >> get stats on why WebGL is failing to load for a more general audience. >> >> On Thu, Sep 17, 2015 at 4:03 PM, Kenneth Russell wrote: >> >>> In Chrome, the about:gpu page usually contains useful information about >>> why WebGL would have failed to start. >>> >>> We'd like to hear about situations where this happens, where it appears >>> the user's graphics drivers are correctly installed. >>> >>> -Ken >>> >>> >>> On Thu, Sep 17, 2015 at 2:35 PM, andre v wrote: >>> >>>> I am working on a webGL game, sometimes when I demo it on a user's >>>> computer the webGL does not work (fails to create context). It would be >>>> nice to know why. Is it incompatible graphics card? Black listed OS, >>>> drivers, bios? Is it disabled in the settings? Is it some sort of >>>> underlaying openGL error? >>>> >>>> I realize that exposing this to me as a programming might be a bad >>>> idea, leaking information it shouldn't have... although I disagree... I >>>> understand the fear. But can't we display that to a user? So that they can >>>> trouble shoot their own issue? So that they don't blame me saying: >>>> "Shouldn't have used webGL, Unity is better", "Write a real game in C++", >>>> "Browser will never be a medium for real games"... Instead oh, my drivers >>>> are not up to date, oh my WaterFox has it disabled, webGL driver caused an >>>> error restart computer... At least some sort of debug flag that can help >>>> trouble shooting it during demos. >>>> >>>> Automated way would be nice, but there is also no real manual way to >>>> trouble shoot it either. My checklist is: >>>> 1. WebGL failed to create context. >>>> 2. Restart computer. (clear any bad graphics hardware state) >>>> 3. Check for browser updates. >>>> 4. Check for graphics chard drivers updates. >>>> 5. Disable extensions like Adblock, try incognito mode. >>>> >>>> Thats it? Where would I check if the graphics card/os combo is black >>>> listed? Is there any debug flag that can tell me why webGL is failing? >>>> >>>> - Andre von Houck >>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Fri Sep 18 06:48:05 2015 From: ash...@ (Ashley Gullen) Date: Fri, 18 Sep 2015 14:48:05 +0100 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: One extra tip is if you are passing failIfMajorPerformanceCaveat: true to the context attributes and you fail to get a context, but you can with it set to 'false', that indicates the WebGL context has a "major performance caveat", which can mean a software-rendered context or some other significant performance implication. The software-rendered context may be used instead of hardware due to GPU blacklisting, so it may be worth notifying the user of this case, even though you did get a WebGL context. Ashley On 18 September 2015 at 09:18, Kenneth Russell wrote: > Sorry I didn't realize this before, but the webglcontextcreationerror > event already contains some of this information: > https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.15.4 . The > precision of the statusMessage in this event was improved somewhat recently > in Chrome, and could probably be improved more without giving up personally > identifiable information. > > Andre, could you please describe some recent scenarios you've run into > where WebGL failed to initialize? > > -Ken > > > > On Thu, Sep 17, 2015 at 8:40 PM, Vladimir Vukicevic > wrote: > >> Actually, thinking about this.. we could include a context creation flag >> that would indicate to the UA that the page wants the user to be told if >> and why context creation failed. The browser would do it itself, so no >> information leakage, and the content has to opt-in, so content that has >> silent fallback can still work. >> >> Thoughts? >> >> - Vlad >> On Sep 17, 2015 7:27 PM, "Jeff Gilbert" wrote: >> >>> It's something we've talked about in the past. Sometimes, we decide a >>> user's drivers aren't reliable enough to run on, and that they should >>> update. However, there's not currently a way to surface this to the app, so >>> the app can recommend updating drivers to the user. >>> >>> It would also be fantastic from a statistics point of view, being able >>> to get stats on why WebGL is failing to load for a more general audience. >>> >>> On Thu, Sep 17, 2015 at 4:03 PM, Kenneth Russell wrote: >>> >>>> In Chrome, the about:gpu page usually contains useful information about >>>> why WebGL would have failed to start. >>>> >>>> We'd like to hear about situations where this happens, where it appears >>>> the user's graphics drivers are correctly installed. >>>> >>>> -Ken >>>> >>>> >>>> On Thu, Sep 17, 2015 at 2:35 PM, andre v wrote: >>>> >>>>> I am working on a webGL game, sometimes when I demo it on a user's >>>>> computer the webGL does not work (fails to create context). It would be >>>>> nice to know why. Is it incompatible graphics card? Black listed OS, >>>>> drivers, bios? Is it disabled in the settings? Is it some sort of >>>>> underlaying openGL error? >>>>> >>>>> I realize that exposing this to me as a programming might be a bad >>>>> idea, leaking information it shouldn't have... although I disagree... I >>>>> understand the fear. But can't we display that to a user? So that they can >>>>> trouble shoot their own issue? So that they don't blame me saying: >>>>> "Shouldn't have used webGL, Unity is better", "Write a real game in C++", >>>>> "Browser will never be a medium for real games"... Instead oh, my drivers >>>>> are not up to date, oh my WaterFox has it disabled, webGL driver caused an >>>>> error restart computer... At least some sort of debug flag that can help >>>>> trouble shooting it during demos. >>>>> >>>>> Automated way would be nice, but there is also no real manual way to >>>>> trouble shoot it either. My checklist is: >>>>> 1. WebGL failed to create context. >>>>> 2. Restart computer. (clear any bad graphics hardware state) >>>>> 3. Check for browser updates. >>>>> 4. Check for graphics chard drivers updates. >>>>> 5. Disable extensions like Adblock, try incognito mode. >>>>> >>>>> Thats it? Where would I check if the graphics card/os combo is black >>>>> listed? Is there any debug flag that can tell me why webGL is failing? >>>>> >>>>> - Andre von Houck >>>>> >>>>> >>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emm...@ Fri Sep 18 07:30:18 2015 From: emm...@ (Emmanuel Gil Peyrot) Date: Fri, 18 Sep 2015 15:30:18 +0100 Subject: [Public WebGL] Proposal for the WEBGL_debug extension Message-ID: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> Hello, I just submitted a proposal for a WEBGL_debug extension, mirroring the KHR_debug GLES one, which you can find here: https://github.com/KhronosGroup/WebGL/pull/1224 I already have a draft implementation for WebKit, which I will update against this version soon, and hopefully publish it once it gets approved. I appreciate any feedback on this extension, which enables a much better debugging workflow than the current gl.getError()-based one. Thanks, -- Emmanuel Gil Peyrot Collabora Ltd. ----------------------------------------------------------- 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 dmi...@ Fri Sep 18 07:34:35 2015 From: dmi...@ (Kirill Dmitrenko) Date: Fri, 18 Sep 2015 17:34:35 +0300 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: <146341442586875@webcorp01g.yandex-team.ru> Is there somewhere a list of possible messages? And also the same kind of list for webglcontextlost event? It would be useful for statistics and implementing right fallback policies. For example, if webglcontext lost occurred, being able to infer, whether it's reasonable to wait for a restore event or it'll never happen in the current session and fallback to software rendering is needed, would be useful for my application. ----------------------------------------------------------- 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 Sep 18 08:47:37 2015 From: khr...@ (Mark Callow) Date: Fri, 18 Sep 2015 08:47:37 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: <687AA48E-2FFC-4CEB-8DE2-DBF9EB5F23EC@callow.im> > On Sep 17, 2015, at 8:40 PM, Vladimir Vukicevic wrote: > > Actually, thinking about this.. we could include a context creation flag that would indicate to the UA that the page wants the user to be told if and why context creation failed. The browser would do it itself, so no information leakage, and the content has to opt-in, so content that has silent fallback can still work. > > Thoughts? > I think this is a very good idea. An application that requests this service could then ask the user to send the information displayed to its maintainers. It will reduce the frequency of a frequently asked question which has a browser specific answer. 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 Raf...@ Fri Sep 18 10:24:45 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 18 Sep 2015 17:24:45 +0000 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: Andre, when running in IE or Edge, context creation should never fail unless you pass failIfMajorPerformanceCaveat as a context attribute and the browser intends to give you a software rendering context. If you find that is not the case, let me know and I will get to the bottom of it. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Ashley Gullen Sent: Friday, September 18, 2015 6:48 AM To: Kenneth Russell Cc: Vladimir Vukicevic ; Gilbert, Jeff ; andre v ; public_webgl...@ Subject: Re: [Public WebGL] Can the browser tell the user why webGL has failed to start? One extra tip is if you are passing failIfMajorPerformanceCaveat: true to the context attributes and you fail to get a context, but you can with it set to 'false', that indicates the WebGL context has a "major performance caveat", which can mean a software-rendered context or some other significant performance implication. The software-rendered context may be used instead of hardware due to GPU blacklisting, so it may be worth notifying the user of this case, even though you did get a WebGL context. Ashley On 18 September 2015 at 09:18, Kenneth Russell > wrote: Sorry I didn't realize this before, but the webglcontextcreationerror event already contains some of this information: https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.15.4 . The precision of the statusMessage in this event was improved somewhat recently in Chrome, and could probably be improved more without giving up personally identifiable information. Andre, could you please describe some recent scenarios you've run into where WebGL failed to initialize? -Ken On Thu, Sep 17, 2015 at 8:40 PM, Vladimir Vukicevic > wrote: Actually, thinking about this.. we could include a context creation flag that would indicate to the UA that the page wants the user to be told if and why context creation failed. The browser would do it itself, so no information leakage, and the content has to opt-in, so content that has silent fallback can still work. Thoughts? - Vlad On Sep 17, 2015 7:27 PM, "Jeff Gilbert" > wrote: It's something we've talked about in the past. Sometimes, we decide a user's drivers aren't reliable enough to run on, and that they should update. However, there's not currently a way to surface this to the app, so the app can recommend updating drivers to the user. It would also be fantastic from a statistics point of view, being able to get stats on why WebGL is failing to load for a more general audience. On Thu, Sep 17, 2015 at 4:03 PM, Kenneth Russell > wrote: In Chrome, the about:gpu page usually contains useful information about why WebGL would have failed to start. We'd like to hear about situations where this happens, where it appears the user's graphics drivers are correctly installed. -Ken On Thu, Sep 17, 2015 at 2:35 PM, andre v > wrote: I am working on a webGL game, sometimes when I demo it on a user's computer the webGL does not work (fails to create context). It would be nice to know why. Is it incompatible graphics card? Black listed OS, drivers, bios? Is it disabled in the settings? Is it some sort of underlaying openGL error? I realize that exposing this to me as a programming might be a bad idea, leaking information it shouldn't have... although I disagree... I understand the fear. But can't we display that to a user? So that they can trouble shoot their own issue? So that they don't blame me saying: "Shouldn't have used webGL, Unity is better", "Write a real game in C++", "Browser will never be a medium for real games"... Instead oh, my drivers are not up to date, oh my WaterFox has it disabled, webGL driver caused an error restart computer... At least some sort of debug flag that can help trouble shooting it during demos. Automated way would be nice, but there is also no real manual way to trouble shoot it either. My checklist is: 1. WebGL failed to create context. 2. Restart computer. (clear any bad graphics hardware state) 3. Check for browser updates. 4. Check for graphics chard drivers updates. 5. Disable extensions like Adblock, try incognito mode. Thats it? Where would I check if the graphics card/os combo is black listed? Is there any debug flag that can tell me why webGL is failing? - Andre von Houck -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Sep 18 11:38:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 18 Sep 2015 20:38:21 +0200 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: We had a discussion about the topic of user messages in relation to blacklisting in March 2012: https://www.khronos.org/webgl/public-mailing-list/archives/1203/msg00013.php which also discussed a lot more issues that can crop up. I can't summarize the whole discussion but here's the gist of the problem, you need to accurately identify why WebGL is not available, and then you need to devise an accurate actionable message to the user. These are two seperate things, for instance: - Reason: WebGL is not available because the driver is blacklisted - Frustrated action: The user cannot update the driver because his OEM has locked him out of his machines administrator account and updating a driver would void the warranty. The action can be frustrated for other reasons. For instance it is possible the UA ships a blacklist that blocks a driver due to a bug that a GPU vendor shipped. In the time that the very latest driver is blacklisted and the GPU vendor devises a better driver and propagates it to users, "updating the driver" is not a very helpful message. For this, a UA would have to know about if a driver is available for a user in the first place. The discussion in March ended without the Khronos WebGL WG taking any action and without further discussion up until today. Maybe the first problem to figure out is how not to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Sep 18 11:58:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 18 Sep 2015 20:58:33 +0200 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: On Fri, Sep 18, 2015 at 8:38 PM, Florian B?sch wrote: > Maybe the first problem to figure out is how not to do that. > Jeff suggested creating github issues in such cases: https://github.com/KhronosGroup/WebGL/issues/1225 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sta...@ Fri Sep 18 15:56:58 2015 From: sta...@ (andre v) Date: Fri, 18 Sep 2015 15:56:58 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: Sorry I don't have access to the machines that had webGL context creation failures. Armed with the knowledge in this thread I will better catalog such issues in the future. I could do some thing better with failIfMajorPerformanceCaveat too. I was not aware that statusMessage has any thing useful. So far I only managed to make it produce "Web page was not allowed to create a WebGL context." by disabling webGL in about://flags in chrome. I will be tracking other messages that it gets to see if its good enough. If it is - great - thats exactly what I want, maybe i was just missing documentation. Thank you every one! Get those messages reporting the correct behavior and that will be great. - Andre On Fri, Sep 18, 2015 at 11:58 AM, Florian B?sch wrote: > On Fri, Sep 18, 2015 at 8:38 PM, Florian B?sch wrote: > >> Maybe the first problem to figure out is how not to do that. >> > > Jeff suggested creating github issues in such cases: > https://github.com/KhronosGroup/WebGL/issues/1225 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sta...@ Sat Sep 19 08:06:18 2015 From: sta...@ (andre v) Date: Sat, 19 Sep 2015 08:06:18 -0700 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: Ken, I got one. Could not create a WebGL context. GPUInfoCollectionFailure: GPU initialization Failed. GPU Info not Collected.VendorId = 74101480, DeviceId = 3008244 Looks like that GPU is unlisted, unknown type? [image: Inline image 1] "Disabled Features: rasterization" looks scary but it means some thing else entirely... https://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization - Andre On Fri, Sep 18, 2015 at 3:56 PM, andre v wrote: > Sorry I don't have access to the machines that had webGL context creation > failures. Armed with the knowledge in this thread I will better catalog > such issues in the future. I could do some thing better with failIfMajorPerformanceCaveat > too. > > I was not aware that statusMessage has any thing useful. So far I only > managed to make it produce "Web page was not allowed to create a WebGL > context." by disabling webGL in about://flags in chrome. I will be tracking > other messages that it gets to see if its good enough. If it is - great - > thats exactly what I want, maybe i was just missing documentation. > > Thank you every one! Get those messages reporting the correct behavior and > that will be great. > > - Andre > > > > On Fri, Sep 18, 2015 at 11:58 AM, Florian B?sch wrote: > >> On Fri, Sep 18, 2015 at 8:38 PM, Florian B?sch wrote: >> >>> Maybe the first problem to figure out is how not to do that. >>> >> >> Jeff suggested creating github issues in such cases: >> https://github.com/KhronosGroup/WebGL/issues/1225 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chromegpu.jpg Type: image/jpeg Size: 271056 bytes Desc: not available URL: From pya...@ Sat Sep 19 09:35:22 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 19 Sep 2015 18:35:22 +0200 Subject: [Public WebGL] Can the browser tell the user why webGL has failed to start? In-Reply-To: References: Message-ID: On Sat, Sep 19, 2015 at 5:06 PM, andre v wrote: > Could not create a WebGL context. GPUInfoCollectionFailure: GPU initialization Failed. GPU Info not Collected.VendorId = 74101480, DeviceId = 3008244 > > The usefulness/actionableness of the messages could use a bit of work, ahem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Sep 20 09:52:04 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 20 Sep 2015 18:52:04 +0200 Subject: [Public WebGL] WebGL_debug_renderer_info IDs Message-ID: WEBGL_debug_renderer_info returns text strings. Here's a few examples: - ANGLE (Intel(R) HD Graphics P4600/P4700 Direct3D11 vs_5_0 ps_5_0) - NVIDIA GeForce GT 625 (OEM) - Gallium 0.4 on NVE7 - Intel(R) HD Graphics - ATI Radeon HD Verde XT Prototype OpenGL Engine - ANGLE (Intel(R) G45/G43 Express Chipset (Microsoft Corporation - WDDM 1.1) Direct3D9Ex vs_3_0 ps_3_0) - Mesa DRI Intel(R) Iris 6100 (Broadwell GT3) There's thousands of these strings accounting for every combination by any driver, backend and UA to assemble them. However, as far as I know, every vendor and GPU have a unique registered ID. Would it be possible to also communicate the vendor and GPU ID? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sun Sep 20 11:42:22 2015 From: kbr...@ (Kenneth Russell) Date: Sun, 20 Sep 2015 11:42:22 -0700 Subject: [Public WebGL] WebGL_debug_renderer_info IDs In-Reply-To: References: Message-ID: There were two primary reasons for not including the vendor and device PCI IDs in the WEBGL_debug_renderer_info queries: 1. They don't exist on non-PCI architectures, including basically every Android device in existence. 2. Their presence would make it easier to write device-specific code, which was an explicit non-goal of this extension. I'm not in favor of going back and adding them to the queries. This information is supposed to be used temporarily and sparingly by applications, generally to identify specific poorly performing devices. -Ken On Sun, Sep 20, 2015 at 9:52 AM, Florian B?sch wrote: > WEBGL_debug_renderer_info returns text strings. Here's a few examples: > > - ANGLE (Intel(R) HD Graphics P4600/P4700 Direct3D11 vs_5_0 ps_5_0) > - NVIDIA GeForce GT 625 (OEM) > - Gallium 0.4 on NVE7 > - Intel(R) HD Graphics > - ATI Radeon HD Verde XT Prototype OpenGL Engine > - ANGLE (Intel(R) G45/G43 Express Chipset (Microsoft Corporation - > WDDM 1.1) Direct3D9Ex vs_3_0 ps_3_0) > - Mesa DRI Intel(R) Iris 6100 (Broadwell GT3) > > There's thousands of these strings accounting for every combination by any > driver, backend and UA to assemble them. > > However, as far as I know, every vendor and GPU have a unique registered > ID. Would it be possible to also communicate the vendor and GPU ID? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Sep 20 13:51:56 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 20 Sep 2015 22:51:56 +0200 Subject: [Public WebGL] WebGL_debug_renderer_info IDs In-Reply-To: References: Message-ID: On Sun, Sep 20, 2015 at 8:42 PM, Kenneth Russell wrote: > I'm not in favor of going back and adding them to the queries. This > information is supposed to be used temporarily and sparingly by > applications, generally to identify specific poorly performing devices. > I can provide the vendor IDs and PCI IDs to lookup to anybody who's interested as a Web API. I just thought it would be nicer if the information wasn't made intentionally hard to read and interprete so that this wouldn't be necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Wed Sep 23 06:15:24 2015 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 23 Sep 2015 16:15:24 +0300 Subject: [Public WebGL] ARB_texture_storage for WebGL In-Reply-To: <245961441884617@webcorp02g.yandex-team.ru> References: <23731441722444@webcorp02f.yandex-team.ru> <64021441808740@webcorp01f.yandex-team.ru> <73601441810268@webcorp02f.yandex-team.ru> <245961441884617@webcorp02g.yandex-team.ru> Message-ID: <19161443014124@webcorp01e.yandex-team.ru> I've put together a proposal: https://www.khronos.org/registry/webgl/extensions/proposals/EXT_texture_storage/ 10.09.2015, 14:31, "Kirill Dmitrenko" : > I can give it a try. > > 10.09.2015, 02:09, "Zhenyao Mo" : >> ?We are working very hard to push out a working WebGL 2 prototype >> ?before the end of year. >> >> ?I agree it might be a good idea to expose TexStorage extension for >> ?WebGL 1. At least it can save memories on Windows with ANGLE backend, >> ?because to create a texture at draw time in ANGLE, we have to maintain >> ?a copy of the entire texture data in ram. >> >> ?If someone can help draft a extension spec, that could probably speed things up. >> >> ?On Wed, Sep 9, 2015 at 1:14 PM, Florian B?sch wrote: >>> ??On Wed, Sep 9, 2015 at 4:51 PM, Kirill Dmitrenko >>> ??wrote: >>>> ??Are there any arguments against keeping "copies" of WebGL 2 method as >>>> ??WebGL 1 extension method? >>> >>> ??The main arguments against are: >>> >>> ??The functionality will eventually arrive anyway with WebGL2 >>> ??Because 1. and resources are tight so lets concentrate on 1. >>> >>> ??WebGL2 will not arrive shortly to everywhere. As the year draws slowly to a >>> ??close, it becomes less likely we'll see any publicly released WebGL2 >>> ??implementation. WebGL2 implementations will arrive slowly, and updates to >>> ??UAs that implement them will appear slower on some platforms than on others >>> ??(Android, Edge and iOS will take forever). >>> >>> ??It is my estimate that it will take until 2020 before we'll see an >>> ??activation rate > 80% for WebGL2. > > -- > 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 > ----------------------------------------------------------- -- 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 kbr...@ Wed Sep 30 23:06:32 2015 From: kbr...@ (Kenneth Russell) Date: Wed, 30 Sep 2015 23:06:32 -0700 Subject: [Public WebGL] Proposal for the WEBGL_debug extension In-Reply-To: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> References: <20150918143018.GA11808@localhost.cbg.collabora.co.uk> Message-ID: Could you describe in more detail how you've used your prototype implementation of this extension and how it's improved your debugging workflow? There are many simple JavaScript frameworks like webgl-debug.js ( https://github.com/KhronosGroup/WebGLDeveloperTools ) that wrap the WebGLRenderingContext, calling getError() after each call, and throwing an exception if an error occurred, which can be caught in the browser's devtools debugger. -Ken On Fri, Sep 18, 2015 at 7:30 AM, Emmanuel Gil Peyrot wrote: > > Hello, > > I just submitted a proposal for a WEBGL_debug extension, mirroring the > KHR_debug GLES one, which you can find here: > https://github.com/KhronosGroup/WebGL/pull/1224 > > I already have a draft implementation for WebKit, which I will update > against this version soon, and hopefully publish it once it gets > approved. > > I appreciate any feedback on this extension, which enables a much > better debugging workflow than the current gl.getError()-based one. > > Thanks, > > -- > Emmanuel Gil Peyrot > Collabora Ltd. > > ----------------------------------------------------------- > 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 -----------------------------------------------------------