From pya...@ Wed Oct 1 23:29:34 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Oct 2014 08:29:34 +0200 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> Message-ID: After accessing the impact of adblocking (a loss of 25% to 50% of visitors) to the statistics, depending on demographic, I'm confident I can still derive statistically relevant information from webglstats which logged 7.5 million visitors last month, now also with the kind help of khronos.org, playcanvas.com and clara.io. I have previously observed issues where singular platforms or browsers would flatline or decline in support levels. The following listing puts a spotlight on the problematic areas: - *Windows Chrome:* down 16% since August from 95% (range held for 2 years) to 78%. No other browser on this platform shows a similar trend. - *OSX Safari:* Support levels still low and not advancing, down 2.6% from 9.6% in July to 7% today. - *Linux:* A good summer of rallied support levels now hit a peak at 74% on all browsers for that platform. - *Android Tablets:* Every browser on this platform shows a stagnation and retreat in support levels with the exception of Chrome Mobile. I'd also like to commend iOS support, which is now rapidly rising from zero to 41% on phones and 29% on tablets. I'm hopeful that this promising is sustained and support levels will plateau at substantial higher levels for this platform. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emm...@ Thu Oct 2 05:26:51 2014 From: emm...@ (Helmut Emmelmann) Date: Thu, 02 Oct 2014 14:26:51 +0200 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> Message-ID: <542D448B.7020703@taccgl.org> > > * *Windows Chrome:* down 16% since August from 95% (range held for 2 > years) to 78%. No other browser on this platform shows a similar trend. On one of my old computers WebGL stopped being detected after a recent chrome update (probably version 37). I just reported this as chrome issue 419694. There also was a similar issue 409430. -- ------------------------------------------------------------------------- H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim Germany | Ph:+49 621-795141 | Fax: +49 621-795161 | mailto:info...@ Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 Handelsregister: HRB 7273 | Amtsgericht Mannheim http://www.h-e-i.de | http://www.taccgl.org ------------------------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Oct 2 14:16:40 2014 From: kbr...@ (Kenneth Russell) Date: Thu, 2 Oct 2014 14:16:40 -0700 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: <542D448B.7020703@taccgl.org> References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> <542D448B.7020703@taccgl.org> Message-ID: An unfortunate regression affecting older graphics cards on Windows made it into Chrome 37 and will be fixed in Chrome 38. This was somewhat described in crbug.com/412221. It's unfortunate this breakage made it to stable. The community can help browser developers avoid these breakages by testing the early access builds ("beta", "dev", "nightly", etc.) of their favorite browsers and reporting bugs early. Another issue https://code.google.com/p/angleproject/issues/detail?id=750 was fixed in Chrome 38 and will prevent breakage of WebGL apps in that upcoming release. -Ken On Thu, Oct 2, 2014 at 5:26 AM, Helmut Emmelmann wrote: > >> >> * *Windows Chrome:* down 16% since August from 95% (range held for 2 >> years) to 78%. No other browser on this platform shows a similar >> trend. > > On one of my old computers WebGL stopped being detected after a recent > chrome update (probably version 37). I just reported this as chrome issue > 419694. There also was a similar issue 409430. > > -- > > ------------------------------------------------------------------------- > H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim > Germany | Ph:+49 621-795141 | Fax: +49 621-795161 | mailto:info...@ > Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 > Handelsregister: HRB 7273 | Amtsgericht Mannheim > http://www.h-e-i.de | http://www.taccgl.org > ------------------------------------------------------------------------- > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Oct 2 14:28:24 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 2 Oct 2014 23:28:24 +0200 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> <542D448B.7020703@taccgl.org> Message-ID: Hey Ken, thanks for the info, I'm glad this'll be rectified soon. I believe automated test runner farms with a salad of hardware installed would help catching those regressions. I'm not sure if this is run by anybody. I do know that Unity3D runs every code change against an extensive test farm from an interivew they gave a couple of years ago. I also believe that GPU vendors run extensive testfarms, but I'm not sure they're running WebGL tests, or put focus on regressions like that. On Thu, Oct 2, 2014 at 11:16 PM, Kenneth Russell wrote: > > An unfortunate regression affecting older graphics cards on Windows > made it into Chrome 37 and will be fixed in Chrome 38. This was > somewhat described in crbug.com/412221. It's unfortunate this breakage > made it to stable. The community can help browser developers avoid > these breakages by testing the early access builds ("beta", "dev", > "nightly", etc.) of their favorite browsers and reporting bugs early. > > Another issue https://code.google.com/p/angleproject/issues/detail?id=750 > was fixed in Chrome 38 and will prevent breakage of WebGL apps in that > upcoming release. > > -Ken > > > On Thu, Oct 2, 2014 at 5:26 AM, Helmut Emmelmann wrote: > > > >> > >> * *Windows Chrome:* down 16% since August from 95% (range held for 2 > >> years) to 78%. No other browser on this platform shows a similar > >> trend. > > > > On one of my old computers WebGL stopped being detected after a recent > > chrome update (probably version 37). I just reported this as chrome issue > > 419694. There also was a similar issue 409430. > > > > -- > > > > ------------------------------------------------------------------------- > > H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim > > Germany | Ph:+49 621-795141 | Fax: +49 621-795161 | mailto:info...@ > > Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 > > Handelsregister: HRB 7273 | Amtsgericht Mannheim > > http://www.h-e-i.de | http://www.taccgl.org > > ------------------------------------------------------------------------- > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Oct 2 14:33:49 2014 From: kbr...@ (Kenneth Russell) Date: Thu, 2 Oct 2014 14:33:49 -0700 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> <542D448B.7020703@taccgl.org> Message-ID: On the Chrome project we've recently enabled an automated test farm of physical hardware with real GPUs that run the WebGL conformance suite against every incoming CL to the browser. See http://www.chromium.org/developers/testing/gpu-testing for more details. However, and unfortunately, we don't have the resources to test on the huge range of hardware required to catch regressions like this. We rely on the community for help in this area. -Ken On Thu, Oct 2, 2014 at 2:28 PM, Florian B?sch wrote: > Hey Ken, thanks for the info, I'm glad this'll be rectified soon. > > I believe automated test runner farms with a salad of hardware installed > would help catching those regressions. I'm not sure if this is run by > anybody. I do know that Unity3D runs every code change against an extensive > test farm from an interivew they gave a couple of years ago. I also believe > that GPU vendors run extensive testfarms, but I'm not sure they're running > WebGL tests, or put focus on regressions like that. > > On Thu, Oct 2, 2014 at 11:16 PM, Kenneth Russell wrote: >> >> >> An unfortunate regression affecting older graphics cards on Windows >> made it into Chrome 37 and will be fixed in Chrome 38. This was >> somewhat described in crbug.com/412221. It's unfortunate this breakage >> made it to stable. The community can help browser developers avoid >> these breakages by testing the early access builds ("beta", "dev", >> "nightly", etc.) of their favorite browsers and reporting bugs early. >> >> Another issue https://code.google.com/p/angleproject/issues/detail?id=750 >> was fixed in Chrome 38 and will prevent breakage of WebGL apps in that >> upcoming release. >> >> -Ken >> >> >> On Thu, Oct 2, 2014 at 5:26 AM, Helmut Emmelmann wrote: >> > >> >> >> >> * *Windows Chrome:* down 16% since August from 95% (range held for 2 >> >> years) to 78%. No other browser on this platform shows a similar >> >> trend. >> > >> > On one of my old computers WebGL stopped being detected after a recent >> > chrome update (probably version 37). I just reported this as chrome >> > issue >> > 419694. There also was a similar issue 409430. >> > >> > -- >> > >> > >> > ------------------------------------------------------------------------- >> > H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim >> > Germany | Ph:+49 621-795141 | Fax: +49 621-795161 | mailto:info...@ >> > Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 >> > Handelsregister: HRB 7273 | Amtsgericht Mannheim >> > http://www.h-e-i.de | http://www.taccgl.org >> > >> > ------------------------------------------------------------------------- >> > >> > ----------------------------------------------------------- >> > You are currently subscribed to public_webgl...@ >> > To unsubscribe, send an email to majordomo...@ with >> > the following command in the body of your email: >> > unsubscribe public_webgl >> > ----------------------------------------------------------- >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Oct 3 00:45:54 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 3 Oct 2014 09:45:54 +0200 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> <542D448B.7020703@taccgl.org> Message-ID: Maybe Unity 3D and Epic who are now also targeting WebGL as well as GPU vendors could run these testbots on their existing testfarms. I think it'd help if the results of those tests where published automatically so other parties (like browser vendors or gpu vendors) could scan them for emerging issues. On Thu, Oct 2, 2014 at 11:33 PM, Kenneth Russell wrote: > On the Chrome project we've recently enabled an automated test farm of > physical hardware with real GPUs that run the WebGL conformance suite > against every incoming CL to the browser. See > http://www.chromium.org/developers/testing/gpu-testing for more > details. However, and unfortunately, we don't have the resources to > test on the huge range of hardware required to catch regressions like > this. We rely on the community for help in this area. > > -Ken > > > On Thu, Oct 2, 2014 at 2:28 PM, Florian B?sch wrote: > > Hey Ken, thanks for the info, I'm glad this'll be rectified soon. > > > > I believe automated test runner farms with a salad of hardware installed > > would help catching those regressions. I'm not sure if this is run by > > anybody. I do know that Unity3D runs every code change against an > extensive > > test farm from an interivew they gave a couple of years ago. I also > believe > > that GPU vendors run extensive testfarms, but I'm not sure they're > running > > WebGL tests, or put focus on regressions like that. > > > > On Thu, Oct 2, 2014 at 11:16 PM, Kenneth Russell wrote: > >> > >> > >> An unfortunate regression affecting older graphics cards on Windows > >> made it into Chrome 37 and will be fixed in Chrome 38. This was > >> somewhat described in crbug.com/412221. It's unfortunate this breakage > >> made it to stable. The community can help browser developers avoid > >> these breakages by testing the early access builds ("beta", "dev", > >> "nightly", etc.) of their favorite browsers and reporting bugs early. > >> > >> Another issue > https://code.google.com/p/angleproject/issues/detail?id=750 > >> was fixed in Chrome 38 and will prevent breakage of WebGL apps in that > >> upcoming release. > >> > >> -Ken > >> > >> > >> On Thu, Oct 2, 2014 at 5:26 AM, Helmut Emmelmann > wrote: > >> > > >> >> > >> >> * *Windows Chrome:* down 16% since August from 95% (range held for > 2 > >> >> years) to 78%. No other browser on this platform shows a similar > >> >> trend. > >> > > >> > On one of my old computers WebGL stopped being detected after a recent > >> > chrome update (probably version 37). I just reported this as chrome > >> > issue > >> > 419694. There also was a similar issue 409430. > >> > > >> > -- > >> > > >> > > >> > > ------------------------------------------------------------------------- > >> > H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 > Mannheim > >> > Germany | Ph:+49 621-795141 | Fax: +49 621-795161 | mailto: > info...@ > >> > Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId > DE185233091 > >> > Handelsregister: HRB 7273 | Amtsgericht Mannheim > >> > http://www.h-e-i.de | http://www.taccgl.org > >> > > >> > > ------------------------------------------------------------------------- > >> > > >> > ----------------------------------------------------------- > >> > You are currently subscribed to public_webgl...@ > >> > To unsubscribe, send an email to majordomo...@ with > >> > the following command in the body of your email: > >> > unsubscribe public_webgl > >> > ----------------------------------------------------------- > >> > > >> > >> ----------------------------------------------------------- > >> You are currently subscribed to public_webgl...@ > >> To unsubscribe, send an email to majordomo...@ with > >> the following command in the body of your email: > >> unsubscribe public_webgl > >> ----------------------------------------------------------- > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Fri Oct 3 06:30:44 2014 From: ash...@ (Ashley Gullen) Date: Fri, 3 Oct 2014 14:30:44 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> Message-ID: I think you're doing a great job with webglstats.com and I check it regularly. But I did notice that most of the contributor sites are tech/early adopter related, or even directly WebGL related, which will probably bias your results towards users with high-end machines with latest drivers and WebGL-enabled browsers. As your visitor count starts reaching a broader audience you will probably start to see your numbers converge on more representative numbers of the wider install base, which is likely to be lower. So I think bugs aside some fall in numbers could be attributed solely to the audience you're reaching. On 2 October 2014 07:29, Florian B?sch wrote: > After accessing the impact of adblocking (a loss of 25% to 50% of > visitors) to the statistics, depending on demographic, I'm confident I can > still derive statistically relevant information from webglstats which > logged 7.5 million visitors last month, now also with the kind help of > khronos.org, playcanvas.com and clara.io. > > I have previously observed issues where singular platforms or browsers > would flatline or decline in support levels. The following listing puts a > spotlight on the problematic areas: > > - *Windows Chrome:* down 16% since August from 95% (range held for 2 > years) to 78%. No other browser on this platform shows a similar trend. > - *OSX Safari:* Support levels still low and not advancing, down 2.6% > from 9.6% in July to 7% today. > - *Linux:* A good summer of rallied support levels now hit a peak at > 74% on all browsers for that platform. > - *Android Tablets:* Every browser on this platform shows a stagnation > and retreat in support levels with the exception of Chrome Mobile. > > I'd also like to commend iOS support, which is now rapidly rising from > zero to 41% on phones and 29% on tablets. I'm hopeful that this promising > is sustained and support levels will plateau at substantial higher levels > for this platform. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Oct 3 06:36:10 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 3 Oct 2014 15:36:10 +0200 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <5367859D.6030708@mozilla.com> <5367CCF6.4070706@mozilla.com> <5368E886.2020300@mozilla.com> Message-ID: On Fri, Oct 3, 2014 at 3:30 PM, Ashley Gullen wrote: > I think you're doing a great job with webglstats.com and I check it > regularly. But I did notice that most of the contributor sites are > tech/early adopter related, or even directly WebGL related, which will > probably bias your results towards users with high-end machines with latest > drivers and WebGL-enabled browsers. As your visitor count starts reaching a > broader audience you will probably start to see your numbers converge on > more representative numbers of the wider install base, which is likely to > be lower. So I think bugs aside some fall in numbers could be attributed > solely to the audience you're reaching. > That's somewhat true, but that is also why I often keep a keen eye on changes in support levels that are odd. Such as chromes support levels collapsing, but not other browsers, or a particular OS being affected. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Oct 4 01:10:45 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 4 Oct 2014 10:10:45 +0200 Subject: [Public WebGL] EXT_frag_depth ratification Message-ID: As EXT_frag_depth is now implemented by multiple UAs (Chrome and Firefox) on multiple platforms (Windows, OSX, Android and Linux), and is covered by conformance tests, I'd like to propose the ratification for this extension. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjc...@ Sat Oct 4 07:04:39 2014 From: pjc...@ (Patrick Cozzi) Date: Sat, 4 Oct 2014 10:04:39 -0400 Subject: [Public WebGL] EXT_frag_depth ratification In-Reply-To: References: Message-ID: +1 This is a very important extension for Cesium. Patrick On Sat, Oct 4, 2014 at 4:10 AM, Florian B?sch wrote: > As EXT_frag_depth is now implemented by multiple UAs (Chrome and Firefox) > on multiple platforms (Windows, OSX, Android and Linux), and is covered by > conformance tests, I'd like to propose the ratification for this extension. > > > -- twitter.com/pjcozzi -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Sat Oct 4 09:18:26 2014 From: baj...@ (Brandon Jones) Date: Sat, 04 Oct 2014 16:18:26 +0000 Subject: [Public WebGL] EXT_frag_depth ratification References: Message-ID: +1! This extension enables a range of effects not possible without it. On Sat Oct 04 2014 at 7:05:21 AM Patrick Cozzi wrote: > +1 > > This is a very important extension for Cesium. > > Patrick > > On Sat, Oct 4, 2014 at 4:10 AM, Florian B?sch wrote: > >> As EXT_frag_depth is now implemented by multiple UAs (Chrome and Firefox) >> on multiple platforms (Windows, OSX, Android and Linux), and is covered by >> conformance tests, I'd like to propose the ratification for this extension. >> >> >> > > > -- > twitter.com/pjcozzi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 5 02:09:54 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 5 Oct 2014 11:09:54 +0200 Subject: [Public WebGL] Extensions with few implementations Message-ID: EXT_sRGB (community approved) - 2.1% presence - Implemented in Firefox and only for osx and linux. - Can be implemented since early 2013 - Implementations missing and possible for Android/Windows and Chrome/Safari/IE EXT_blend_minmax (community approved) - 0.8% presence - Implemented in Chrome on desktops - Can be implemented since early 2014 - Implementations missing and possible for Android/iOS and Firefox/Safari/IE EXT_shader_texture_lod (community approved) - 4% presence overall, 1.3% on desktops, 46% on mobiles. - Implemented in Crhome on desktops (low presence here too) - Can be implemented since early 2014 - Implementations missing and possible for Android/iOS and Firefox/Safari/IE EXT_disjoint_timer_query (draft) - Not implemented so far - Can be implemented since early 2014 - Implementations missing and possible for Windows/OSX/Linux/Android and Firefox/Safari/Chrome/IE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 5 09:54:35 2014 From: jda...@ (John Davis) Date: Sun, 5 Oct 2014 12:54:35 -0400 Subject: [Public WebGL] IE11 Message-ID: Is there a changelog where we can follow webgl updates for IE11? From what I can tell, on the GPU side of things, IE11 is surpassing chrome and firefox. Javascript is still slower in IE11, but the webgl/gpu thing definitely appears to be leap frogging the others. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pjc...@ Sun Oct 5 14:13:42 2014 From: pjc...@ (Patrick Cozzi) Date: Sun, 5 Oct 2014 17:13:42 -0400 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: There may be other places, but there is at least this: http://msdn.microsoft.com/en-us/library/ie/dn725046(v=vs.85).aspx Patrick On Sun, Oct 5, 2014 at 12:54 PM, John Davis wrote: > Is there a changelog where we can follow webgl updates for IE11? From > what I can tell, on the GPU side of things, IE11 is surpassing chrome and > firefox. > > Javascript is still slower in IE11, but the webgl/gpu thing definitely > appears to be leap frogging the others. > > -- twitter.com/pjcozzi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jer...@ Sun Oct 5 15:16:03 2014 From: jer...@ (Jerry Richards) Date: Sun, 5 Oct 2014 15:16:03 -0700 Subject: [Public WebGL] IE11 In-Reply-To: References: , Message-ID: www.babylonjs.com Not IE11 specific but it is used to test IE11 and others. Date: Sun, 5 Oct 2014 17:13:42 -0400 Subject: Re: [Public WebGL] IE11 From: pjcozzi...@ To: jdavis...@ CC: public_webgl...@ There may be other places, but there is at least this: http://msdn.microsoft.com/en-us/library/ie/dn725046(v=vs.85).aspx Patrick On Sun, Oct 5, 2014 at 12:54 PM, John Davis wrote: Is there a changelog where we can follow webgl updates for IE11? From what I can tell, on the GPU side of things, IE11 is surpassing chrome and firefox. Javascript is still slower in IE11, but the webgl/gpu thing definitely appears to be leap frogging the others. -- twitter.com/pjcozzi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fra...@ Mon Oct 6 09:48:40 2014 From: Fra...@ (Frank Olivier) Date: Mon, 6 Oct 2014 16:48:40 +0000 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: Hi John Wrt: ?Javascript is still slower in IE11? ? We?re very interested in scenarios where we can improve Javascript performance; if you can point us to scenarios, we?d appreciate it. Wrt resources: IE Blog: http://blogs.msdn.com/b/ie/; we?ll be posting more about WebGL soon. MSDN reference: http://msdn.microsoft.com/en-us/library/ie/bg182648(v=vs.85).aspx; we update this continuously. Our recent updates: IE11 v0.93 WebGL renderer aka ?Spring 2014 Update? Compressed textures Stencil buffers Standard derivatives extension Anti-aliasing More GLSL conformance (structs, inout, constructors) GLSL Point-size support (DX10+ only) GLSL Frontfacing support Support for alpha WebGLContextAttribute Non-float vertices Support for LUMINANCE, LUMINANCE_ALPHA, ALPHA textures vertexAttrib{1,2,3,4}f[v] methods IE11 v0.94 WebGL renderer aka ?Summer 2014 Update? Instancing extension failIfMajorPerformanceCaveat context attribute Triangle fans and line loops (emulated) 16-bit textures support (emulated) UNSIGNED_BYTE element arrays (emulated) We?re at ~97% compliance with Khronos test suites now, and we are working on the remaining gaps. Thanks Frank Olivier Internet Explorer WebGL team From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of John Davis Sent: Sunday, October 5, 2014 9:55 AM To: public webgl Subject: [Public WebGL] IE11 Is there a changelog where we can follow webgl updates for IE11? From what I can tell, on the GPU side of things, IE11 is surpassing chrome and firefox. Javascript is still slower in IE11, but the webgl/gpu thing definitely appears to be leap frogging the others. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Mon Oct 6 10:07:12 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Mon, 6 Oct 2014 20:07:12 +0300 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: Hi Frank, I posted one such bug item about IE11 performance to connect.microsoft.com, but it was closed without action and later deleted. It was numbered 810215 and the title was "IE11 performance is worse than FF, Chrome or Opera in Emscripten WebGL benchmark.". At the time when I did the benchmarks, the results looked like this: https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_benchmark/10kCubes_results_20130312.html . Perhaps things have changed since then. You can run the benchmark in one of the links on the page. Also, here is more recent interactive version of the same application: https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes.html (It starts out with setTimeout(0)-based rendering, tap B once to get requestAnimationFrame-based rendering). For your convenience, here is a zipped build of the interactive version: https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes_vsync.zip . Best, Jukka 2014-10-06 19:48 GMT+03:00 Frank Olivier : > > > Wrt: ?Javascript is still slower in IE11? ? We?re very interested in > scenarios where we can improve Javascript performance; if you can point us > to scenarios, we?d appreciate it. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Oct 6 12:53:26 2014 From: kbr...@ (Kenneth Russell) Date: Mon, 6 Oct 2014 12:53:26 -0700 Subject: [Public WebGL] Extensions with few implementations In-Reply-To: References: Message-ID: Hi Florian, On Sun, Oct 5, 2014 at 2:09 AM, Florian B?sch wrote: > EXT_sRGB (community approved) > > 2.1% presence > Implemented in Firefox and only for osx and linux. > Can be implemented since early 2013 > Implementations missing and possible for Android/Windows and > Chrome/Safari/IE Thanks for pointing out this oversight. We'll fix crbug.com/386048 in Chrome. > EXT_blend_minmax (community approved) > > 0.8% presence > Implemented in Chrome on desktops > Can be implemented since early 2014 > Implementations missing and possible for Android/iOS and Firefox/Safari/IE > > EXT_shader_texture_lod (community approved) > > 4% presence overall, 1.3% on desktops, 46% on mobiles. > Implemented in Crhome on desktops (low presence here too) > Can be implemented since early 2014 > Implementations missing and possible for Android/iOS and Firefox/Safari/IE > > EXT_disjoint_timer_query (draft) > > Not implemented so far > Can be implemented since early 2014 > Implementations missing and possible for Windows/OSX/Linux/Android and > Firefox/Safari/Chrome/IE Yes, we need to get on this and fix crbug.com/345227. -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...@ Mon Oct 6 12:54:10 2014 From: kbr...@ (Kenneth Russell) Date: Mon, 6 Oct 2014 12:54:10 -0700 Subject: [Public WebGL] EXT_frag_depth ratification In-Reply-To: References: Message-ID: Thanks for the feedback. We'll include this in the next round of extensions proposed for ratification. On Sat, Oct 4, 2014 at 9:18 AM, Brandon Jones wrote: > +1! > > This extension enables a range of effects not possible without it. > > On Sat Oct 04 2014 at 7:05:21 AM Patrick Cozzi wrote: >> >> +1 >> >> This is a very important extension for Cesium. >> >> Patrick >> >> On Sat, Oct 4, 2014 at 4:10 AM, Florian B?sch wrote: >>> >>> As EXT_frag_depth is now implemented by multiple UAs (Chrome and Firefox) >>> on multiple platforms (Windows, OSX, Android and Linux), and is covered by >>> conformance tests, I'd like to propose the ratification for this extension. >>> >>> >> >> >> >> -- >> twitter.com/pjcozzi ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Mon Oct 6 13:11:00 2014 From: jgi...@ (Jeff Gilbert) Date: Mon, 6 Oct 2014 13:11:00 -0700 (PDT) Subject: [Public WebGL] Extensions with few implementations In-Reply-To: References: Message-ID: <445986616.24657016.1412626260527.JavaMail.zimbra@mozilla.com> I'll take a look at Firefox's implementation, though I will say that sometimes there are unfortunate reasons for low activation rates. Failing anything else, we should be able to report why activations rates are low. -Jeff ----- Original Message ----- From: "Florian B?sch" To: "public webgl" Sent: Sunday, October 5, 2014 2:09:54 AM Subject: [Public WebGL] Extensions with few implementations EXT_sRGB (community approved) - 2.1% presence - Implemented in Firefox and only for osx and linux. - Can be implemented since early 2013 - Implementations missing and possible for Android/Windows and Chrome/Safari/IE EXT_blend_minmax (community approved) - 0.8% presence - Implemented in Chrome on desktops - Can be implemented since early 2014 - Implementations missing and possible for Android/iOS and Firefox/Safari/IE EXT_shader_texture_lod (community approved) - 4% presence overall, 1.3% on desktops, 46% on mobiles. - Implemented in Crhome on desktops (low presence here too) - Can be implemented since early 2014 - Implementations missing and possible for Android/iOS and Firefox/Safari/IE EXT_disjoint_timer_query (draft) - Not implemented so far - Can be implemented since early 2014 - Implementations missing and possible for Windows/OSX/Linux/Android and Firefox/Safari/Chrome/IE ----------------------------------------------------------- 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 dgl...@ Mon Oct 6 18:36:10 2014 From: dgl...@ (Dan Glastonbury) Date: Tue, 07 Oct 2014 11:36:10 +1000 Subject: [Public WebGL] Extensions with few implementations In-Reply-To: <445986616.24657016.1412626260527.JavaMail.zimbra@mozilla.com> References: <445986616.24657016.1412626260527.JavaMail.zimbra@mozilla.com> Message-ID: <5433438A.5040807@mozilla.com> On 7/10/2014 6:11 am, Jeff Gilbert wrote: > I'll take a look at Firefox's implementation, though I will say that sometimes there are unfortunate reasons for low activation rates. Failing anything else, we should be able to report why activations rates are low. I implemented EXT_sRGB for Firefox as my first task on WebGL. It's entirely possible that it doesn't detect support on top of ANGLE correctly. ----------------------------------------------------------- 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 Raf...@ Tue Oct 7 10:40:35 2014 From: Raf...@ (Rafael Cintron) Date: Tue, 7 Oct 2014 17:40:35 +0000 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: Hello Jukka. Thank you very much for your feedback. The IE build on the results page is not the latest released version. You should re-run your benchmark with the latest released version available on Windows Update. While IE has improved compared to where we once were, we are still not better than Chrome when you throw a large number of objects at the benchmark. On an ATI FirePro V card, I get 23fps with 5000 objects on IE. Chrome yields 30fps with the same workload. There is definitely more work for us to do here. If you find any more issues, please let myself or Frank know. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Jukka Jyl?nki Sent: Monday, October 6, 2014 10:07 AM To: Frank Olivier Cc: jdavis...@; public webgl Subject: Re: [Public WebGL] IE11 Hi Frank, I posted one such bug item about IE11 performance to connect.microsoft.com, but it was closed without action and later deleted. It was numbered 810215 and the title was "IE11 performance is worse than FF, Chrome or Opera in Emscripten WebGL benchmark.". At the time when I did the benchmarks, the results looked like this: https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_benchmark/10kCubes_results_20130312.html . Perhaps things have changed since then. You can run the benchmark in one of the links on the page. Also, here is more recent interactive version of the same application: https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes.html (It starts out with setTimeout(0)-based rendering, tap B once to get requestAnimationFrame-based rendering). For your convenience, here is a zipped build of the interactive version: https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes_vsync.zip . Best, Jukka 2014-10-06 19:48 GMT+03:00 Frank Olivier >: Wrt: ?Javascript is still slower in IE11? ? We?re very interested in scenarios where we can improve Javascript performance; if you can point us to scenarios, we?d appreciate it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Oct 10 01:14:15 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 10 Oct 2014 10:14:15 +0200 Subject: [Public WebGL] experimental and prefixes still prevalent Message-ID: WebGL is still shown with the experimental flag on some platforms, where it probably shouldn't. To illustrate the issue, below are some of the select cases: - Opera is entirely experimental, though it is based on Webkit (or Blink?) which is in use by Chrome, which generally has a very low experimental webgl status. - Firefox has started to go out of experimental, but the rate of change has slowed and seems to be flat now, this would indicate that browser update isn't working satisfactory. - Safari on OSX is experimental 30% of the time, though it is based on WebKit, as is Chrome which for the same platform is almost never experimental. - Chrome on Linux shows 6% as experimental, although Chromium on Linux only shows about 2% as experimental (this seems strange) - Android Browser on phones is 61% experimental, but Chrome Mobile is 0% and the Android Browser on tablets is - Android Browser on phones is 61% experimental (Chrome Mobile is 0% experimental, Android browser on tablets is 6%) - Mobile Firefox on Android is almost completely experimental (but has recently started to go out of experimental) There are also still some extensions being listed with vendor prefixes (but are declining), but more importantly, some extensions seem to start out their life again with vendor prefixes, and I thought the policy was not to do that anymore. Below are cases where this happens: - WEBGL_compressed_texture_atc: with prefix on Android by Chrome and Android browser. - WEBGL_compressed_texture_pvrtc: with prefix on iOS - EXT_texture_filter_anisotropic: with prefix on iOS. You can inspect the current state of these on http://webglstats.com/ for each platform, operating system and browser using the selection tree on the side. I'd encourage all vendors to have a look at situations like this, and see if it can be improved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From web...@ Fri Oct 10 07:10:25 2014 From: web...@ (James Riordon) Date: Fri, 10 Oct 2014 10:10:25 -0400 Subject: [Public WebGL] Second WebGL Widget Contest up and running Message-ID: NVIDIA has co-sponsored the Second WebGL Widget contest by contributing a new Shield Gaming Tablet as one of the prizes. This is in addition to two WebGL books Toni Parisi by sponsored by O?Reilly media; and the WebGL book by Sumeet Arora sponsored by Packt Publishing. Submit your best WebGL Widget by November 25 for a chance to win! We've recently increased the size limit from 30K to 200K. What can you create? Important Dates: ? Starts at 9:00 a.m. Pacific Time PST on Tuesday, September 2, 2014 ? Ends at 5:00 p.m. PST on Tuesday, November 25, 2014 ? Winner will be notified on or before December 2, 2014 WebGL Web Widget Requirements: ? The WebGL widget must use the WebGL API for its rendering. ? The appearance of the winning WebGL widget must be such that it is suitable for promoting and marketing WebGL. It should look Cool! This is subjective and will be decided at the discretion of the Judges. ? Must be original work and not contain any copyright material (You may use third-party libraries, however you must have the right to redistribute them, and the Khronos Group must be granted the same rights.) ? Bonus points for interactivity: show off what WebGL can do! ? The WebGL widget must be allowed to be presented on the Khronos website. ? The widget must use the WebGL API for its rendering. ? Should look good within a space of 200 x 200 pixels. ? The WebGL widget must come in under 200K for both code and resources, gzip-compressed. ? The WebGL widget must run on at least 8 WebGL implementations: 2 on each of Windows, Mac, Linux, and Android. Please test before you submit! ? One entry per person (in the case of multiple entries, only the final one will be considered). Prizes: ? Programming 3D Applications - Author: Tony Parisi ? WebGL: Up and Running - Author: Tony Parisi ? "WebGL Game Development" - Author: Sumeet Arora ? Shield Gaming Tablet - 16G - Courtesy: NVIDIA Cheers James Riordon Khronos Group Webmaster www.khronos.org | www.opengl.org | collada.org This confidential message is sent exclusively to the persons named above. If you received this message by mistake, please notify us immediately and delete all copies. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Fri Oct 10 10:25:17 2014 From: baj...@ (Brandon Jones) Date: Fri, 10 Oct 2014 17:25:17 +0000 Subject: [Public WebGL] experimental and prefixes still prevalent References: Message-ID: If you don't mind clarifying: What do you mean by "shown with the experimental flag?" Does this mean: - The browser will accept "experimental-webgl" as a valid context type? (I think all WebGL enabled browser match this description) - The browser ONLY accepts "experimental-webgl"? (This sound like what you're talking about) - WebGL support in any form must be enabled with a flag on those browsers? In the case of prefixed extensions, Chrome's policy is to no longer launch extensions with prefixes, though we will keep the prefixed versions around for older extensions. That doesn't necessarily apply to other browsers, however. I think Firefox said they would do the same as Chrome, but in Apple's case if they don't want to introduce a flag mechanism into the browser (which I'm sure they don't on iOS) prefixed extensions may be the only way they can expose draft extensions. Not that either of the cases you mentioned are still in draft status, I'm just saying there's still valid reasons to launch with a prefix. I think in the case of ATC textures we had implemented the extension back when prefixing was a thing, but there may have been some errors in the implementation that prevented it from showing up in the stats till more recently. --Brandon On Fri Oct 10 2014 at 1:15:00 AM Florian B?sch wrote: > WebGL is still shown with the experimental flag on some platforms, where > it probably shouldn't. To illustrate the issue, below are some of the > select cases: > > > - Opera is entirely experimental, though it is based on Webkit (or > Blink?) which is in use by Chrome, which generally has a very low > experimental webgl status. > - Firefox has started to go out of experimental, but the rate of > change has slowed and seems to be flat now, this would indicate that > browser update isn't working satisfactory. > - Safari on OSX is experimental 30% of the time, though it is based on > WebKit, as is Chrome which for the same platform is almost never > experimental. > - Chrome on Linux shows 6% as experimental, although Chromium on Linux > only shows about 2% as experimental (this seems strange) > - Android Browser on phones is 61% experimental, but Chrome Mobile is > 0% and the Android Browser on tablets is > - Android Browser on phones is 61% experimental (Chrome Mobile is 0% > experimental, Android browser on tablets is 6%) > - Mobile Firefox on Android is almost completely experimental (but has > recently started to go out of experimental) > > There are also still some extensions being listed with vendor prefixes > (but are declining), but more importantly, some extensions seem to start > out their life again with vendor prefixes, and I thought the policy was not > to do that anymore. Below are cases where this happens: > > - WEBGL_compressed_texture_atc: with prefix on Android by Chrome and > Android browser. > - WEBGL_compressed_texture_pvrtc: with prefix on iOS > - EXT_texture_filter_anisotropic: with prefix on iOS. > > You can inspect the current state of these on http://webglstats.com/ for > each platform, operating system and browser using the selection tree on the > side. I'd encourage all vendors to have a look at situations like this, and > see if it can be improved. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Oct 10 12:24:24 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 10 Oct 2014 21:24:24 +0200 Subject: [Public WebGL] experimental and prefixes still prevalent In-Reply-To: References: Message-ID: On Fri, Oct 10, 2014 at 7:25 PM, Brandon Jones wrote: > If you don't mind clarifying: What do you mean by "shown with the > experimental flag?" Does this mean: > > - The browser will accept "experimental-webgl" as a valid context type? > (I think all WebGL enabled browser match this description) > - The browser ONLY accepts "experimental-webgl"? (This sound like what > you're talking about) > - WebGL support in any form must be enabled with a flag on those browsers? > The context is first tried to be obtained via canvas.getContext('webgl'). If that returns no context, then canvas.getContext('experimental-webgl') is tried. If that does return a context, webgl is marked as supported, and the experimental name is noted, and that's what you see on webglstats. In the case of prefixed extensions, Chrome's policy is to no longer launch > extensions with prefixes, though we will keep the prefixed versions around > for older extensions. That doesn't necessarily apply to other browsers, > however. I think Firefox said they would do the same as Chrome, but in > Apple's case if they don't want to introduce a flag mechanism into the > browser (which I'm sure they don't on iOS) prefixed extensions may be the > only way they can expose draft extensions. Not that either of the cases you > mentioned are still in draft status, I'm just saying there's still valid > reasons to launch with a prefix. > > I think in the case of ATC textures we had implemented the extension back > when prefixing was a thing, but there may have been some errors in the > implementation that prevented it from showing up in the stats till more > recently. > The extension name is surmised from gl.getSupportedExtensions() and it's only counted as prefixed, if only a prefixed name is present. If both prefixed and unprefixed names are present, the unprefixed name is counted. Is an experimental WebGL extension flag a bad idea on iOS? -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Mon Oct 13 12:13:44 2014 From: din...@ (Dean Jackson) Date: Tue, 14 Oct 2014 06:13:44 +1100 Subject: [Public WebGL] experimental and prefixes still prevalent In-Reply-To: References: Message-ID: <3FAAFA24-0E94-4BED-A278-C59834DCD65F@apple.com> > On 11 Oct 2014, at 6:24 am, Florian B?sch wrote: > > Is an experimental WebGL extension flag a bad idea on iOS? There is an extremely high bar for exposing a feature switch on iOS, across the system. That bar would be exponentially higher for an experimental feature that is exposed to arbitrary Web content. In general, users can't be asked to make a decision about these things - there is too much to explain and a lot of risk. The same applies on OS X, although there we have WebKit nightly builds that expose experimental features. We're working towards getting this for iOS too. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Oct 13 12:23:28 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 13 Oct 2014 21:23:28 +0200 Subject: [Public WebGL] experimental and prefixes still prevalent In-Reply-To: <3FAAFA24-0E94-4BED-A278-C59834DCD65F@apple.com> References: <3FAAFA24-0E94-4BED-A278-C59834DCD65F@apple.com> Message-ID: On Mon, Oct 13, 2014 at 9:13 PM, Dean Jackson wrote: > The same applies on OS X, although there we have WebKit nightly builds > that expose experimental features. We're working towards getting this for > iOS too. > I love it. +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Mon Oct 13 15:31:22 2014 From: baj...@ (Brandon Jones) Date: Mon, 13 Oct 2014 22:31:22 +0000 Subject: [Public WebGL] experimental and prefixes still prevalent References: <3FAAFA24-0E94-4BED-A278-C59834DCD65F@apple.com> Message-ID: +1 here too! I would love to see WebKit nightlies on iOS! On Mon Oct 13 2014 at 12:23:28 PM Florian B?sch wrote: > On Mon, Oct 13, 2014 at 9:13 PM, Dean Jackson wrote: > >> The same applies on OS X, although there we have WebKit nightly builds >> that expose experimental features. We're working towards getting this for >> iOS too. >> > > I love it. +1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Mon Oct 13 15:46:24 2014 From: din...@ (Dean Jackson) Date: Tue, 14 Oct 2014 09:46:24 +1100 Subject: [Public WebGL] experimental and prefixes still prevalent In-Reply-To: References: <3FAAFA24-0E94-4BED-A278-C59834DCD65F@apple.com> Message-ID: <9021D2CF-9D0E-44BE-AB9D-54C3528D7BB6@apple.com> > On 14 Oct 2014, at 9:31 am, Brandon Jones wrote: > > +1 here too! I would love to see WebKit nightlies on iOS! I better curb some enthusiasm then :) That's an ultimate goal, but the first steps are getting iOS WebKit to build with the public SDK for the simulator, then for devices (which requires signing, etc), and so on. Each of these steps is a bit tricky, but also each one should really help external developers to contribute and test. Alas, I don't have a timeframe, but we are definitely working hard on it. Dean > > On Mon Oct 13 2014 at 12:23:28 PM Florian B?sch > wrote: > On Mon, Oct 13, 2014 at 9:13 PM, Dean Jackson > wrote: > The same applies on OS X, although there we have WebKit nightly builds that expose experimental features. We're working towards getting this for iOS too. > > I love it. +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue Oct 14 00:39:27 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 14 Oct 2014 10:39:27 +0300 Subject: [Public WebGL] Removal of glTexImage3D entry point? Message-ID: Hi, in the current form, WebGL 2 spec is planning to remove a GLES3 entry point it finds to be of "bad form" and use in modern code should be avoided. See https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and https://github.com/KhronosGroup/WebGL/issues/542 . While one can agree that calling glTexStorage3D is of more modern form than calling glTexImage3D, I don't agree that it is correct that WebGL 2 should start deprecating/erasing API functionality on its own. Especially when reading the comments in the issue tracker, the rationale seems to not be technical, but only for cleaning and peace of mind purposes. However, these kind of changes would break existing GLES3 code that is compiled over to the web via Emscripten. Therefore I would recommend that WebGL 2 did not arbitrate API cleanups like this, unless the emulation path is a trivial one that can be documented in the spec itself. What do you think? Jukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Tue Oct 14 01:56:50 2014 From: flo...@ (Floh) Date: Tue, 14 Oct 2014 10:56:50 +0200 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: Message-ID: I agree (disclaimer, my main use of WebGL is through emscripten). WebGL should continue to map to a respective OpenGLES version as closely as possible, unless a feature doesn't make technical sense in a browser environment (like mapping buffers). If providing a 'cleaned up' API is one of WebGL's goals, then at least an 'mandatory extension' should exist which implements the missing functions. But as long as it only about removing one or two functions for aesthetical reasons my vote would be to keep the function(s) in the core API. The subtle differences between OpenGLES and OpenGL are confusing enough already (and with modern mobile GPUs mostly obsolete I think). Cheers, -Floh. On Tue, Oct 14, 2014 at 9:39 AM, Jukka Jyl?nki wrote: > Hi, > > in the current form, WebGL 2 spec is planning to remove a GLES3 entry point > it finds to be of "bad form" and use in modern code should be avoided. See > https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and > https://github.com/KhronosGroup/WebGL/issues/542 . > > While one can agree that calling glTexStorage3D is of more modern form than > calling glTexImage3D, I don't agree that it is correct that WebGL 2 should > start deprecating/erasing API functionality on its own. Especially when > reading the comments in the issue tracker, the rationale seems to not be > technical, but only for cleaning and peace of mind purposes. However, these > kind of changes would break existing GLES3 code that is compiled over to the > web via Emscripten. Therefore I would recommend that WebGL 2 did not > arbitrate API cleanups like this, unless the emulation path is a trivial one > that can be documented in the spec itself. What do you think? > > 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 bja...@ Tue Oct 14 05:19:15 2014 From: bja...@ (Benoit Jacob) Date: Tue, 14 Oct 2014 05:19:15 -0700 (PDT) Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: Message-ID: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> I concur about the difficulty / impossibility of implementing texImage3D in full generality on top of just texStorage3D and texSubImage3D. If the first texture image specification call on a texture is a texImage3D call with level=1 and width=3, then we can't know whether the level 0 image will have width 6 or width 7, which we need to know immediately in order to call texStorage3D. In the short term, I'm hoping that the only application code that we have to worry about in the short term will always upload the level 0 image first. Then, we still have to assume that a mipmap will be wanted, but that's not a big deal because 1) the mipmap memory usage overhead for a cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of the level 0 image, and 2) when using texImage3D, a similar memory allocation problem is handed over to the OpenGL implementation anyway. So I'm confident that for Emscripten we can do something that will support the majority of reasonable applications in the short term, but in the long term, it's unfortunate to have to give up implementing all of ES3. Think emscriptening test suites, etc. So while this isn't a short-term emergency, I think that if we stick to the removal of texImage3D, it's going to haunt us. Benoit ----- Original Message ----- > Hi, > in the current form, WebGL 2 spec is planning to remove a GLES3 entry point > it finds to be of "bad form" and use in modern code should be avoided. See > https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and > https://github.com/KhronosGroup/WebGL/issues/542 . > While one can agree that calling glTexStorage3D is of more modern form than > calling glTexImage3D, I don't agree that it is correct that WebGL 2 should > start deprecating/erasing API functionality on its own. Especially when > reading the comments in the issue tracker, the rationale seems to not be > technical, but only for cleaning and peace of mind purposes. However, these > kind of changes would break existing GLES3 code that is compiled over to the > web via Emscripten. Therefore I would recommend that WebGL 2 did not > arbitrate API cleanups like this, unless the emulation path is a trivial one > that can be documented in the spec itself. What do you think? > Jukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Oct 14 11:02:31 2014 From: kbr...@ (Kenneth Russell) Date: Tue, 14 Oct 2014 11:02:31 -0700 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> Message-ID: You make good points about not arbitrarily subsetting OpenGL ES 3. The thought in the WebGL working group at the time was something along the lines of: it would have been far better if mutable texture allocation functions had not been present in the first place (far simpler texture validation logic, etc.); and since 3D textures were being newly introduced, there was an opportunity to avoid widespread usage of an undesirable entry point. (We considered dropping TexImage2D in WebGL 2, but that would have broken basically all applications.) You're correct that it isn't simple to emulate TexImage3D on top of TexStorage3D and TexSubImage3D. However, one point is that it should not be difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead of TexImage3D. For the long term, it still might be a good idea to push developers in the direction of using the immutable allocation functions, and not providing TexImage3D in Emscripten's emulation layer. More opinions please? Thanks, -Ken On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob wrote: > I concur about the difficulty / impossibility of implementing texImage3D > in full generality on top of just texStorage3D and texSubImage3D. > > If the first texture image specification call on a texture is a texImage3D > call with level=1 and width=3, then we can't know whether the level 0 image > will have width 6 or width 7, which we need to know immediately in order to > call texStorage3D. > > In the short term, I'm hoping that the only application code that we have > to worry about in the short term will always upload the level 0 image > first. Then, we still have to assume that a mipmap will be wanted, but > that's not a big deal because 1) the mipmap memory usage overhead for a > cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of > the level 0 image, and 2) when using texImage3D, a similar memory > allocation problem is handed over to the OpenGL implementation anyway. > > So I'm confident that for Emscripten we can do something that will support > the majority of reasonable applications in the short term, but in the long > term, it's unfortunate to have to give up implementing all of ES3. Think > emscriptening test suites, etc. So while this isn't a short-term emergency, > I think that if we stick to the removal of texImage3D, it's going to haunt > us. > > Benoit > > ------------------------------ > > Hi, > > in the current form, WebGL 2 spec is planning to remove a GLES3 entry > point it finds to be of "bad form" and use in modern code should be > avoided. See https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 > and https://github.com/KhronosGroup/WebGL/issues/542 . > > While one can agree that calling glTexStorage3D is of more modern form > than calling glTexImage3D, I don't agree that it is correct that WebGL 2 > should start deprecating/erasing API functionality on its own. Especially > when reading the comments in the issue tracker, the rationale seems to not > be technical, but only for cleaning and peace of mind purposes. However, > these kind of changes would break existing GLES3 code that is compiled over > to the web via Emscripten. Therefore I would recommend that WebGL 2 did not > arbitrate API cleanups like this, unless the emulation path is a trivial > one that can be documented in the spec itself. What do you think? > > Jukka > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Wed Oct 15 03:43:27 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Wed, 15 Oct 2014 13:43:27 +0300 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> Message-ID: I agree that there are a lot of bad things in OpenGL that should not have been present in the first place. Still, I think it's premature if WebGL 2 working group starts calling these out before Khronos deprecates the functions on GLES3/Desktop GL land, which it has not done. For WebGL 2, parity and compatibility with GLES3 is critical, since there is a large number of native codebases that are looking at JavaScript+WebGL2 as a deployment platform. The proper procedure here should be first to get TexImage3D deprecated in desktop GL and GLES before these kind of decisions are made to WebGL. 2014-10-14 21:02 GMT+03:00 Kenneth Russell : > You make good points about not arbitrarily subsetting OpenGL ES 3. The > thought in the WebGL working group at the time was something along the > lines of: it would have been far better if mutable texture allocation > functions had not been present in the first place (far simpler texture > validation logic, etc.); and since 3D textures were being newly introduced, > there was an opportunity to avoid widespread usage of an undesirable entry > point. (We considered dropping TexImage2D in WebGL 2, but that would have > broken basically all applications.) > > You're correct that it isn't simple to emulate TexImage3D on top of > TexStorage3D and TexSubImage3D. However, one point is that it should not be > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead > of TexImage3D. For the long term, it still might be a good idea to push > developers in the direction of using the immutable allocation functions, > and not providing TexImage3D in Emscripten's emulation layer. > > More opinions please? > > Thanks, > > -Ken > > > > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob wrote: > >> I concur about the difficulty / impossibility of implementing texImage3D >> in full generality on top of just texStorage3D and texSubImage3D. >> >> If the first texture image specification call on a texture is a >> texImage3D call with level=1 and width=3, then we can't know whether the >> level 0 image will have width 6 or width 7, which we need to know >> immediately in order to call texStorage3D. >> >> In the short term, I'm hoping that the only application code that we have >> to worry about in the short term will always upload the level 0 image >> first. Then, we still have to assume that a mipmap will be wanted, but >> that's not a big deal because 1) the mipmap memory usage overhead for a >> cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of >> the level 0 image, and 2) when using texImage3D, a similar memory >> allocation problem is handed over to the OpenGL implementation anyway. >> >> So I'm confident that for Emscripten we can do something that will >> support the majority of reasonable applications in the short term, but in >> the long term, it's unfortunate to have to give up implementing all of ES3. >> Think emscriptening test suites, etc. So while this isn't a short-term >> emergency, I think that if we stick to the removal of texImage3D, it's >> going to haunt us. >> >> Benoit >> >> ------------------------------ >> >> Hi, >> >> in the current form, WebGL 2 spec is planning to remove a GLES3 entry >> point it finds to be of "bad form" and use in modern code should be >> avoided. See >> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and >> https://github.com/KhronosGroup/WebGL/issues/542 . >> >> While one can agree that calling glTexStorage3D is of more modern form >> than calling glTexImage3D, I don't agree that it is correct that WebGL 2 >> should start deprecating/erasing API functionality on its own. Especially >> when reading the comments in the issue tracker, the rationale seems to not >> be technical, but only for cleaning and peace of mind purposes. However, >> these kind of changes would break existing GLES3 code that is compiled over >> to the web via Emscripten. Therefore I would recommend that WebGL 2 did not >> arbitrate API cleanups like this, unless the emulation path is a trivial >> one that can be documented in the spec itself. What do you think? >> >> Jukka >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Oct 15 15:31:29 2014 From: bja...@ (Benoit Jacob) Date: Wed, 15 Oct 2014 15:31:29 -0700 (PDT) Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> Message-ID: <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> I just ran into another, maybe deeper problem with the removal of texImage3D: if my understanding of the spec is correct, it removes functionality. I have an OpenGL ES 3 application that uses a 3D texture with ALPHA format. Is there any way to get that with texStorage3D? texStorage3D only accepts sized internalformats (indeed, it does not take a type parameter, so an unsized internalformat would remain ambiguous). But there is no sized internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F and ALPHA32F are not listed among valid sized internalformats anywhere in the ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly described as a dummy effective internalformat not corresponding to any GLenum constant, in the ES3 spec (Table 3.2). The same issue also with LUMINANCE_ALPHA. I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but does there exist any reasonably simple, automatic porting path for ES3 applications relying on them? Something that would be reasonable to implement in a place like Emscripten's OpenGL-to-WebGL layer? Benoit ----- Original Message ----- > You make good points about not arbitrarily subsetting OpenGL ES 3. The > thought in the WebGL working group at the time was something along the lines > of: it would have been far better if mutable texture allocation functions > had not been present in the first place (far simpler texture validation > logic, etc.); and since 3D textures were being newly introduced, there was > an opportunity to avoid widespread usage of an undesirable entry point. (We > considered dropping TexImage2D in WebGL 2, but that would have broken > basically all applications.) > You're correct that it isn't simple to emulate TexImage3D on top of > TexStorage3D and TexSubImage3D. However, one point is that it should not be > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead > of TexImage3D. For the long term, it still might be a good idea to push > developers in the direction of using the immutable allocation functions, and > not providing TexImage3D in Emscripten's emulation layer. > More opinions please? > Thanks, > -Ken > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob < bjacob...@ > wrote: > > I concur about the difficulty / impossibility of implementing texImage3D in > > full generality on top of just texStorage3D and texSubImage3D. > > > If the first texture image specification call on a texture is a texImage3D > > call with level=1 and width=3, then we can't know whether the level 0 image > > will have width 6 or width 7, which we need to know immediately in order to > > call texStorage3D. > > > In the short term, I'm hoping that the only application code that we have > > to > > worry about in the short term will always upload the level 0 image first. > > Then, we still have to assume that a mipmap will be wanted, but that's not > > a > > big deal because 1) the mipmap memory usage overhead for a cubic 3D texture > > is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of the level 0 > > image, > > and 2) when using texImage3D, a similar memory allocation problem is handed > > over to the OpenGL implementation anyway. > > > So I'm confident that for Emscripten we can do something that will support > > the majority of reasonable applications in the short term, but in the long > > term, it's unfortunate to have to give up implementing all of ES3. Think > > emscriptening test suites, etc. So while this isn't a short-term emergency, > > I think that if we stick to the removal of texImage3D, it's going to haunt > > us. > > > Benoit > > > > Hi, > > > > > > in the current form, WebGL 2 spec is planning to remove a GLES3 entry > > > point > > > it finds to be of "bad form" and use in modern code should be avoided. > > > See > > > https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and > > > https://github.com/KhronosGroup/WebGL/issues/542 . > > > > > > While one can agree that calling glTexStorage3D is of more modern form > > > than > > > calling glTexImage3D, I don't agree that it is correct that WebGL 2 > > > should > > > start deprecating/erasing API functionality on its own. Especially when > > > reading the comments in the issue tracker, the rationale seems to not be > > > technical, but only for cleaning and peace of mind purposes. However, > > > these > > > kind of changes would break existing GLES3 code that is compiled over to > > > the > > > web via Emscripten. Therefore I would recommend that WebGL 2 did not > > > arbitrate API cleanups like this, unless the emulation path is a trivial > > > one > > > that can be documented in the spec itself. What do you think? > > > > > > Jukka > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Oct 15 16:02:16 2014 From: kbr...@ (Kenneth Russell) Date: Wed, 15 Oct 2014 16:02:16 -0700 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> Message-ID: This is a good point. Thanks for catching it. It looks like the RED format is the preferred way to get a single-channel texture going forward, but switching to that format requires updating shaders, or using texture swizzling -- and if the application's using texture swizzling, that would require significant bookkeeping behind the scenes. Since there hasn't been any other feedback from WebGL implementers, I'll bring up this topic on the next working group conference call. Out of curiosity is it not feasible to ask the developer of this application to update it to not use this deprecated texture format? -Ken On Wed, Oct 15, 2014 at 3:31 PM, Benoit Jacob wrote: > I just ran into another, maybe deeper problem with the removal of > texImage3D: if my understanding of the spec is correct, it removes > functionality. > > I have an OpenGL ES 3 application that uses a 3D texture with ALPHA > format. Is there any way to get that with texStorage3D? texStorage3D only > accepts sized internalformats (indeed, it does not take a type parameter, > so an unsized internalformat would remain ambiguous). But there is no sized > internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F and > ALPHA32F are not listed among valid sized internalformats anywhere in the > ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly > described as a dummy effective internalformat not corresponding to any > GLenum constant, in the ES3 spec (Table 3.2). > > The same issue also with LUMINANCE_ALPHA. > > I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but > does there exist any reasonably simple, automatic porting path for ES3 > applications relying on them? Something that would be reasonable to > implement in a place like Emscripten's OpenGL-to-WebGL layer? > > Benoit > > ------------------------------ > > You make good points about not arbitrarily subsetting OpenGL ES 3. The > thought in the WebGL working group at the time was something along the > lines of: it would have been far better if mutable texture allocation > functions had not been present in the first place (far simpler texture > validation logic, etc.); and since 3D textures were being newly introduced, > there was an opportunity to avoid widespread usage of an undesirable entry > point. (We considered dropping TexImage2D in WebGL 2, but that would have > broken basically all applications.) > > You're correct that it isn't simple to emulate TexImage3D on top of > TexStorage3D and TexSubImage3D. However, one point is that it should not be > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead > of TexImage3D. For the long term, it still might be a good idea to push > developers in the direction of using the immutable allocation functions, > and not providing TexImage3D in Emscripten's emulation layer. > > More opinions please? > > Thanks, > > -Ken > > > > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob wrote: > >> I concur about the difficulty / impossibility of implementing texImage3D >> in full generality on top of just texStorage3D and texSubImage3D. >> >> If the first texture image specification call on a texture is a >> texImage3D call with level=1 and width=3, then we can't know whether the >> level 0 image will have width 6 or width 7, which we need to know >> immediately in order to call texStorage3D. >> >> In the short term, I'm hoping that the only application code that we have >> to worry about in the short term will always upload the level 0 image >> first. Then, we still have to assume that a mipmap will be wanted, but >> that's not a big deal because 1) the mipmap memory usage overhead for a >> cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of >> the level 0 image, and 2) when using texImage3D, a similar memory >> allocation problem is handed over to the OpenGL implementation anyway. >> >> So I'm confident that for Emscripten we can do something that will >> support the majority of reasonable applications in the short term, but in >> the long term, it's unfortunate to have to give up implementing all of ES3. >> Think emscriptening test suites, etc. So while this isn't a short-term >> emergency, I think that if we stick to the removal of texImage3D, it's >> going to haunt us. >> >> Benoit >> >> ------------------------------ >> >> Hi, >> >> in the current form, WebGL 2 spec is planning to remove a GLES3 entry >> point it finds to be of "bad form" and use in modern code should be >> avoided. See >> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and >> https://github.com/KhronosGroup/WebGL/issues/542 . >> >> While one can agree that calling glTexStorage3D is of more modern form >> than calling glTexImage3D, I don't agree that it is correct that WebGL 2 >> should start deprecating/erasing API functionality on its own. Especially >> when reading the comments in the issue tracker, the rationale seems to not >> be technical, but only for cleaning and peace of mind purposes. However, >> these kind of changes would break existing GLES3 code that is compiled over >> to the web via Emscripten. Therefore I would recommend that WebGL 2 did not >> arbitrate API cleanups like this, unless the emulation path is a trivial >> one that can be documented in the spec itself. What do you think? >> >> Jukka >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Oct 15 16:29:42 2014 From: jgi...@ (Jeff Gilbert) Date: Wed, 15 Oct 2014 16:29:42 -0700 (PDT) Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> Message-ID: <442928014.26110171.1413415782391.JavaMail.zimbra@mozilla.com> It sounds like if we want to track GLES3, we should more closely do so, even if we disagree with components of it. Yes, it would be better if no one ever used texImage3d, but if we count soon-to-be-ported apps as 'existing code', then we unfortunately have a pretty good reason not to remove texImage3d. ----- Original Message ----- From: "Kenneth Russell" To: "Benoit Jacob" Cc: "Jukka Jyl?nki" , "public webgl" Sent: Wednesday, October 15, 2014 4:02:16 PM Subject: Re: [Public WebGL] Removal of glTexImage3D entry point? This is a good point. Thanks for catching it. It looks like the RED format is the preferred way to get a single-channel texture going forward, but switching to that format requires updating shaders, or using texture swizzling -- and if the application's using texture swizzling, that would require significant bookkeeping behind the scenes. Since there hasn't been any other feedback from WebGL implementers, I'll bring up this topic on the next working group conference call. Out of curiosity is it not feasible to ask the developer of this application to update it to not use this deprecated texture format? -Ken On Wed, Oct 15, 2014 at 3:31 PM, Benoit Jacob wrote: > I just ran into another, maybe deeper problem with the removal of > texImage3D: if my understanding of the spec is correct, it removes > functionality. > > I have an OpenGL ES 3 application that uses a 3D texture with ALPHA > format. Is there any way to get that with texStorage3D? texStorage3D only > accepts sized internalformats (indeed, it does not take a type parameter, > so an unsized internalformat would remain ambiguous). But there is no sized > internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F and > ALPHA32F are not listed among valid sized internalformats anywhere in the > ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly > described as a dummy effective internalformat not corresponding to any > GLenum constant, in the ES3 spec (Table 3.2). > > The same issue also with LUMINANCE_ALPHA. > > I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but > does there exist any reasonably simple, automatic porting path for ES3 > applications relying on them? Something that would be reasonable to > implement in a place like Emscripten's OpenGL-to-WebGL layer? > > Benoit > > ------------------------------ > > You make good points about not arbitrarily subsetting OpenGL ES 3. The > thought in the WebGL working group at the time was something along the > lines of: it would have been far better if mutable texture allocation > functions had not been present in the first place (far simpler texture > validation logic, etc.); and since 3D textures were being newly introduced, > there was an opportunity to avoid widespread usage of an undesirable entry > point. (We considered dropping TexImage2D in WebGL 2, but that would have > broken basically all applications.) > > You're correct that it isn't simple to emulate TexImage3D on top of > TexStorage3D and TexSubImage3D. However, one point is that it should not be > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D instead > of TexImage3D. For the long term, it still might be a good idea to push > developers in the direction of using the immutable allocation functions, > and not providing TexImage3D in Emscripten's emulation layer. > > More opinions please? > > Thanks, > > -Ken > > > > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob wrote: > >> I concur about the difficulty / impossibility of implementing texImage3D >> in full generality on top of just texStorage3D and texSubImage3D. >> >> If the first texture image specification call on a texture is a >> texImage3D call with level=1 and width=3, then we can't know whether the >> level 0 image will have width 6 or width 7, which we need to know >> immediately in order to call texStorage3D. >> >> In the short term, I'm hoping that the only application code that we have >> to worry about in the short term will always upload the level 0 image >> first. Then, we still have to assume that a mipmap will be wanted, but >> that's not a big deal because 1) the mipmap memory usage overhead for a >> cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size of >> the level 0 image, and 2) when using texImage3D, a similar memory >> allocation problem is handed over to the OpenGL implementation anyway. >> >> So I'm confident that for Emscripten we can do something that will >> support the majority of reasonable applications in the short term, but in >> the long term, it's unfortunate to have to give up implementing all of ES3. >> Think emscriptening test suites, etc. So while this isn't a short-term >> emergency, I think that if we stick to the removal of texImage3D, it's >> going to haunt us. >> >> Benoit >> >> ------------------------------ >> >> Hi, >> >> in the current form, WebGL 2 spec is planning to remove a GLES3 entry >> point it finds to be of "bad form" and use in modern code should be >> avoided. See >> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and >> https://github.com/KhronosGroup/WebGL/issues/542 . >> >> While one can agree that calling glTexStorage3D is of more modern form >> than calling glTexImage3D, I don't agree that it is correct that WebGL 2 >> should start deprecating/erasing API functionality on its own. Especially >> when reading the comments in the issue tracker, the rationale seems to not >> be technical, but only for cleaning and peace of mind purposes. However, >> these kind of changes would break existing GLES3 code that is compiled over >> to the web via Emscripten. Therefore I would recommend that WebGL 2 did not >> arbitrate API cleanups like this, unless the emulation path is a trivial >> one that can be documented in the spec itself. What do you think? >> >> 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 jda...@ Sat Oct 18 09:21:47 2014 From: jda...@ (John Davis) Date: Sat, 18 Oct 2014 12:21:47 -0400 Subject: [Public WebGL] 3D textures Message-ID: Since WebGL 2.0 is still a ways out, could we pleeeeeeze add the 3D texture extension to IE, FireFox, Chrome and IOS 8/Safari? https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt For those of us looking to save bandwidth by using tiled procedural textures, this is a big deal. https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sat Oct 18 09:26:29 2014 From: jda...@ (John Davis) Date: Sat, 18 Oct 2014 12:26:29 -0400 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> <4D9C02C8.3050707@hicorp.co.jp> <4D9D1A47.3060903@hicorp.co.jp> Message-ID: Years have gone by, and look were we're at!? For heaven sake, let's just add it. https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt On Thu, Apr 7, 2011 at 11:35 PM, John Davis wrote: > I'll be anxiously waiting :) > > > On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell wrote: > >> On Thu, Apr 7, 2011 at 3:23 AM, John Davis >> wrote: >> > Ken, >> > Vlad mentioned he would like to see the same thing. My perception is >> that >> > he was summarily ignored. Didn't he get this whole thing started? Dan >> > Ginsburg, OES 2.0 Bible, also ignored. >> > Forgive me for singling out Chris, but he seems to have final say on >> just >> > about everything, which seems to fly in the face of an "open standard". >> > Perhaps I should start addressing all members of the working group. >> Who >> > all is on the working group? Are they even seeing this dialogue? >> >> I'm pretty sure that most of the people on the WebGL working group are >> on this list. I am the chair of the working group (as of last >> Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob and >> Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as an >> outside expert. >> >> All open standards have (or should have) leaders and decision makers. >> Chris's opinion is just that, one opinion. We aim to get consensus in >> the WG. There are Khronos practices for voting on contentious topics. >> In this case, where the WG seems divided, the path of least resistance >> forward would be to propose a browser vendor-specific extension rather >> than incorporating the OES version of the extension. The latter is >> considered "more official" but any browser vendor can put forth the >> former. >> >> > I truly believe this spec is going to change everything. It's >> special. But >> > the handling of it's evolution seems to have some conflicts of interest. >> > Earlier Chris sited support of IOS devices, which I found frightening. >> > WebGL should not be limited/dictated by caps in IOS devices. >> >> It isn't. However iOS is a major force in the mobile market and we do >> not want to cause fragmentation of WebGL content early in its >> lifetime. So far the extensions we have specified and plan to specify >> work on desktop, iOS and Android. For the moment we would like to try >> to keep it that way. >> >> Also please keep in mind that the spec will continue to evolve. If you >> can work around the limitations of the current spec for a few more >> months I think you will be pleased with forthcoming revisions. >> >> -Ken >> >> > JD >> > >> > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell wrote: >> >> >> >> (off-list) >> >> >> >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis >> >> wrote: >> >> > My bad, you're right. Again I site the stats from multiple sources >> at >> >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >> >> > Doesn't matter though, I guess we won't see volume textures until >> Chris >> >> > says >> >> > we can have them. Unless of course Gregg would be willing to have >> >> > Transgaming add it to Angle w/o it being in the official extension >> >> > registry. >> >> >> >> John, >> >> >> >> Please be polite. Singling out Chris and blaming him on the public >> >> mailing list is inappropriate behavior. Additionally, I believe >> >> Chris's opinion is the majority opinion in the WebGL working group at >> >> this time. >> >> >> >> If you could convince a browser vendor to add the extension in their >> >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in one of >> >> the browsers and submit patches -- then perhaps others would add >> >> support for the same extension. >> >> >> >> -Ken >> >> >> >> P.S. The WebGL spec will continue to evolve. The current set of >> >> functionality is not all that will ever be supported. >> >> >> >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < >> callow_mark...@> >> >> > wrote: >> >> >> >> >> >> I think you have that backwards. It's a 4:1 ratio mobile to desktop. >> >> >> >> >> >> Regards >> >> >> >> >> >> -Mark >> >> >> >> >> >> >> >> >> >> >> >> On 06/04/2011 20:05, John Davis wrote: >> >> >> >> >> >> That's still a 1:4 ratio, the tail is wagging the dog. >> >> >> >> >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < >> callow_mark...@> >> >> >> wrote: >> >> >>> >> >> >>> Those stat's are deeply suspicious. >> >> >>> >> >> >>> It is widely reported that in Japan the majority of people access >> the >> >> >>> internet from their mobile devices. A large number of these >> devices do >> >> >>> not >> >> >>> have identifiable operation systems. >> >> >>> >> >> >>> Another pointer is that when I visited http://whatsmyuseragent.com >> , >> >> >>> only >> >> >>> 4 of the most recent 15 visitors came from desktop devices. >> >> >>> >> >> >>> Regards >> >> >>> >> >> >>> -Mark >> >> >>> >> >> >>> >> >> >>> >> >> >>> On 06/04/2011 11:56, John Davis wrote: >> >> >>> >> >> >>> I'm frustrated we are hamstringing the spec due to limitations on >> the >> >> >>> mobile side. The majority of web browsers out there are not being >> >> >>> used on >> >> >>> mobile devices. Call me nuts, but this just doesn't make sense. >> >> >>> Look at the Web clients table. >> >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >> >> >>> Percentage-wise mobile web clients don't amount to squat. >> >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin >> >> >>> wrote: >> >> >>>> >> >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >> >> >>>> >> >> >>>> > >all of the extensions there are available on at least one >> OpenGL >> >> >>>> > > ES >> >> >>>> > > implementation on mobile devices (iPhone). >> >> >>>> > >> >> >>>> > Chris, >> >> >>>> > >> >> >>>> > Why does the above matter if WebGL is never going to be >> available >> >> >>>> > on >> >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS available? >> >> >>>> >> >> >>>> Are you just making a fatalistic complaint that you're unhappy >> with >> >> >>>> the >> >> >>>> fact that iOS devices don't publicly support WebGL today? Or did >> you >> >> >>>> get the >> >> >>>> impression from me or someone else that iOS will never support >> WebGL? >> >> >>>> If you >> >> >>>> interpreted something I said in that way, then I apologize. No >> one at >> >> >>>> Apple >> >> >>>> can comment on if or when WebGL will be available on iOS. If >> you've >> >> >>>> gotten >> >> >>>> that information from a blog somewhere then you should ignore it >> (as >> >> >>>> is a >> >> >>>> general rule about bloggers and Apple rumors). >> >> >>>> >> >> >>>> ----- >> >> >>>> ~Chris >> >> >>>> cmarrin...@ >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>> >> >> >> >> >> > >> >> > >> >> >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sat Oct 18 10:19:47 2014 From: jda...@ (John Davis) Date: Sat, 18 Oct 2014 13:19:47 -0400 Subject: [Public WebGL] Volume Textures In-Reply-To: <4062493.7726.1302090549202.JavaMail.root@zimbra.off.net> References: <4D9C02C8.3050707@hicorp.co.jp> <4062493.7726.1302090549202.JavaMail.root@zimbra.off.net> Message-ID: Vlad, Can we get some "push" from your side on this one? ie 3D textures extension. JD On Wed, Apr 6, 2011 at 7:49 AM, Vladimir Vukicevic wrote: > Yeah, the numbers are pretty hard to quantify, especially if you try to > toss in something like "modern web browser" in there. The *trend* is that > people are accessing the "full modern web" more and more from phones, but > nowhere near as much as from desktops right this moment. So WebGL can > either follow the trend and have it become the absolute standard way of > doing 3D on the web on both desktop and mobile, or it can sacrifice some > mobile compat now, with the expectation that mobile will "catch up" > hardware capability wise soon... but that opens the door to having some > other technology come in and grow with mobile from day one. > > However, that's an argument for baseline capabilities. I'd personally > like to see a broader set of extensions, including 3D textures. Their > usage should also provide useful information for mobile hardware > manufacturers' future silicon plans. > > - Vlad > > ----- Original Message ----- > > Those stat's are deeply suspicious. > > > > > > It is widely reported that in Japan the majority of people access the > > internet from their mobile devices. A large number of these devices do > > not have identifiable operation systems. > > > > > > Another pointer is that when I visited http://whatsmyuseragent.com , > > only 4 of the most recent 15 visitors came from desktop devices. > > > > > > Regards > > > > > > > > -Mark > > > > > > > > On 06/04/2011 11:56, John Davis wrote: > > > > I'm frustrated we are hamstringing the spec due to limitations on the > > mobile side. The majority of web browsers out there are not being used > > on mobile devices. Call me nuts, but this just doesn't make sense. > > > > > > Look at the Web clients table. > > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > > > > > Percentage-wise mobile web clients don't amount to squat. > > > > > > On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin < cmarrin...@ > > > wrote: > > > > > > > > > > On Apr 2, 2011, at 5:46 AM, John Davis wrote: > > > > > >all of the extensions there are available on at least one OpenGL ES > > > >implementation on mobile devices (iPhone). > > > > > > Chris, > > > > > > Why does the above matter if WebGL is never going to be available on > > > iPhone/iPad/AppleTV? Why don't we focus on what IS available? > > > > Are you just making a fatalistic complaint that you're unhappy with > > the fact that iOS devices don't publicly support WebGL today? Or did > > you get the impression from me or someone else that iOS will never > > support WebGL? If you interpreted something I said in that way, then I > > apologize. No one at Apple can comment on if or when WebGL will be > > available on iOS. If you've gotten that information from a blog > > somewhere then you should ignore it (as is a general rule about > > bloggers and Apple rumors). > > > > ----- ~Chris > > cmarrin...@ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Oct 18 12:04:13 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 18 Oct 2014 21:04:13 +0200 Subject: [Public WebGL] 3D textures In-Reply-To: References: Message-ID: There was some pushback in earlier discussions against introducing extensions for things that'll come with WebGL2. Is this still an issue, or is it ok to propose extensions for stuff that's in WebGL2? On Sat, Oct 18, 2014 at 6:21 PM, John Davis wrote: > Since WebGL 2.0 is still a ways out, could we pleeeeeeze add the 3D > texture extension to IE, FireFox, Chrome and IOS 8/Safari? > > https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt > > For those of us looking to save bandwidth by using tiled procedural > textures, this is a big deal. > > https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Oct 18 14:53:57 2014 From: kbr...@ (Kenneth Russell) Date: Sat, 18 Oct 2014 14:53:57 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> <4D9C02C8.3050707@hicorp.co.jp> <4D9D1A47.3060903@hicorp.co.jp> Message-ID: John, Try Mozilla's WebGL 2.0 prototype -- see https://wiki.mozilla.org/Platform/GFX/WebGL2 . It contains 3D texture support, and targeting that version of the API will ensure your code is portable as more WebGL 2 implementations become available. -Ken On Sat, Oct 18, 2014 at 9:26 AM, John Davis wrote: > Years have gone by, and look were we're at!? For heaven sake, let's just > add it. > > https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt > > > On Thu, Apr 7, 2011 at 11:35 PM, John Davis > wrote: > >> I'll be anxiously waiting :) >> >> >> On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell wrote: >> >>> On Thu, Apr 7, 2011 at 3:23 AM, John Davis >>> wrote: >>> > Ken, >>> > Vlad mentioned he would like to see the same thing. My perception is >>> that >>> > he was summarily ignored. Didn't he get this whole thing started? Dan >>> > Ginsburg, OES 2.0 Bible, also ignored. >>> > Forgive me for singling out Chris, but he seems to have final say on >>> just >>> > about everything, which seems to fly in the face of an "open standard". >>> > Perhaps I should start addressing all members of the working group. >>> Who >>> > all is on the working group? Are they even seeing this dialogue? >>> >>> I'm pretty sure that most of the people on the WebGL working group are >>> on this list. I am the chair of the working group (as of last >>> Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob and >>> Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as an >>> outside expert. >>> >>> All open standards have (or should have) leaders and decision makers. >>> Chris's opinion is just that, one opinion. We aim to get consensus in >>> the WG. There are Khronos practices for voting on contentious topics. >>> In this case, where the WG seems divided, the path of least resistance >>> forward would be to propose a browser vendor-specific extension rather >>> than incorporating the OES version of the extension. The latter is >>> considered "more official" but any browser vendor can put forth the >>> former. >>> >>> > I truly believe this spec is going to change everything. It's >>> special. But >>> > the handling of it's evolution seems to have some conflicts of >>> interest. >>> > Earlier Chris sited support of IOS devices, which I found frightening. >>> > WebGL should not be limited/dictated by caps in IOS devices. >>> >>> It isn't. However iOS is a major force in the mobile market and we do >>> not want to cause fragmentation of WebGL content early in its >>> lifetime. So far the extensions we have specified and plan to specify >>> work on desktop, iOS and Android. For the moment we would like to try >>> to keep it that way. >>> >>> Also please keep in mind that the spec will continue to evolve. If you >>> can work around the limitations of the current spec for a few more >>> months I think you will be pleased with forthcoming revisions. >>> >>> -Ken >>> >>> > JD >>> > >>> > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell >>> wrote: >>> >> >>> >> (off-list) >>> >> >>> >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis >>> >> wrote: >>> >> > My bad, you're right. Again I site the stats from multiple sources >>> at >>> >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >>> >> > Doesn't matter though, I guess we won't see volume textures until >>> Chris >>> >> > says >>> >> > we can have them. Unless of course Gregg would be willing to have >>> >> > Transgaming add it to Angle w/o it being in the official extension >>> >> > registry. >>> >> >>> >> John, >>> >> >>> >> Please be polite. Singling out Chris and blaming him on the public >>> >> mailing list is inappropriate behavior. Additionally, I believe >>> >> Chris's opinion is the majority opinion in the WebGL working group at >>> >> this time. >>> >> >>> >> If you could convince a browser vendor to add the extension in their >>> >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in one of >>> >> the browsers and submit patches -- then perhaps others would add >>> >> support for the same extension. >>> >> >>> >> -Ken >>> >> >>> >> P.S. The WebGL spec will continue to evolve. The current set of >>> >> functionality is not all that will ever be supported. >>> >> >>> >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < >>> callow_mark...@> >>> >> > wrote: >>> >> >> >>> >> >> I think you have that backwards. It's a 4:1 ratio mobile to >>> desktop. >>> >> >> >>> >> >> Regards >>> >> >> >>> >> >> -Mark >>> >> >> >>> >> >> >>> >> >> >>> >> >> On 06/04/2011 20:05, John Davis wrote: >>> >> >> >>> >> >> That's still a 1:4 ratio, the tail is wagging the dog. >>> >> >> >>> >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < >>> callow_mark...@> >>> >> >> wrote: >>> >> >>> >>> >> >>> Those stat's are deeply suspicious. >>> >> >>> >>> >> >>> It is widely reported that in Japan the majority of people access >>> the >>> >> >>> internet from their mobile devices. A large number of these >>> devices do >>> >> >>> not >>> >> >>> have identifiable operation systems. >>> >> >>> >>> >> >>> Another pointer is that when I visited >>> http://whatsmyuseragent.com, >>> >> >>> only >>> >> >>> 4 of the most recent 15 visitors came from desktop devices. >>> >> >>> >>> >> >>> Regards >>> >> >>> >>> >> >>> -Mark >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> On 06/04/2011 11:56, John Davis wrote: >>> >> >>> >>> >> >>> I'm frustrated we are hamstringing the spec due to limitations on >>> the >>> >> >>> mobile side. The majority of web browsers out there are not being >>> >> >>> used on >>> >> >>> mobile devices. Call me nuts, but this just doesn't make sense. >>> >> >>> Look at the Web clients table. >>> >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >>> >> >>> Percentage-wise mobile web clients don't amount to squat. >>> >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >>> >> >>>> >>> >> >>>> > >all of the extensions there are available on at least one >>> OpenGL >>> >> >>>> > > ES >>> >> >>>> > > implementation on mobile devices (iPhone). >>> >> >>>> > >>> >> >>>> > Chris, >>> >> >>>> > >>> >> >>>> > Why does the above matter if WebGL is never going to be >>> available >>> >> >>>> > on >>> >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS available? >>> >> >>>> >>> >> >>>> Are you just making a fatalistic complaint that you're unhappy >>> with >>> >> >>>> the >>> >> >>>> fact that iOS devices don't publicly support WebGL today? Or did >>> you >>> >> >>>> get the >>> >> >>>> impression from me or someone else that iOS will never support >>> WebGL? >>> >> >>>> If you >>> >> >>>> interpreted something I said in that way, then I apologize. No >>> one at >>> >> >>>> Apple >>> >> >>>> can comment on if or when WebGL will be available on iOS. If >>> you've >>> >> >>>> gotten >>> >> >>>> that information from a blog somewhere then you should ignore it >>> (as >>> >> >>>> is a >>> >> >>>> general rule about bloggers and Apple rumors). >>> >> >>>> >>> >> >>>> ----- >>> >> >>>> ~Chris >>> >> >>>> cmarrin...@ >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>> >>> >> >> >>> >> > >>> >> > >>> >> >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sat Oct 18 15:05:49 2014 From: jda...@ (John Davis) Date: Sat, 18 Oct 2014 18:05:49 -0400 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> <4D9C02C8.3050707@hicorp.co.jp> <4D9D1A47.3060903@hicorp.co.jp> Message-ID: Waving your finger in the air, what's the ETA on WebGL 2 implementations across all existing webgl browsers? On Sat, Oct 18, 2014 at 5:53 PM, Kenneth Russell wrote: > John, > > Try Mozilla's WebGL 2.0 prototype -- see > https://wiki.mozilla.org/Platform/GFX/WebGL2 . It contains 3D texture > support, and targeting that version of the API will ensure your code is > portable as more WebGL 2 implementations become available. > > -Ken > > > On Sat, Oct 18, 2014 at 9:26 AM, John Davis > wrote: > >> Years have gone by, and look were we're at!? For heaven sake, let's just >> add it. >> >> https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt >> >> >> On Thu, Apr 7, 2011 at 11:35 PM, John Davis >> wrote: >> >>> I'll be anxiously waiting :) >>> >>> >>> On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell wrote: >>> >>>> On Thu, Apr 7, 2011 at 3:23 AM, John Davis >>>> wrote: >>>> > Ken, >>>> > Vlad mentioned he would like to see the same thing. My perception is >>>> that >>>> > he was summarily ignored. Didn't he get this whole thing started? >>>> Dan >>>> > Ginsburg, OES 2.0 Bible, also ignored. >>>> > Forgive me for singling out Chris, but he seems to have final say on >>>> just >>>> > about everything, which seems to fly in the face of an "open >>>> standard". >>>> > Perhaps I should start addressing all members of the working group. >>>> Who >>>> > all is on the working group? Are they even seeing this dialogue? >>>> >>>> I'm pretty sure that most of the people on the WebGL working group are >>>> on this list. I am the chair of the working group (as of last >>>> Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob and >>>> Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as an >>>> outside expert. >>>> >>>> All open standards have (or should have) leaders and decision makers. >>>> Chris's opinion is just that, one opinion. We aim to get consensus in >>>> the WG. There are Khronos practices for voting on contentious topics. >>>> In this case, where the WG seems divided, the path of least resistance >>>> forward would be to propose a browser vendor-specific extension rather >>>> than incorporating the OES version of the extension. The latter is >>>> considered "more official" but any browser vendor can put forth the >>>> former. >>>> >>>> > I truly believe this spec is going to change everything. It's >>>> special. But >>>> > the handling of it's evolution seems to have some conflicts of >>>> interest. >>>> > Earlier Chris sited support of IOS devices, which I found >>>> frightening. >>>> > WebGL should not be limited/dictated by caps in IOS devices. >>>> >>>> It isn't. However iOS is a major force in the mobile market and we do >>>> not want to cause fragmentation of WebGL content early in its >>>> lifetime. So far the extensions we have specified and plan to specify >>>> work on desktop, iOS and Android. For the moment we would like to try >>>> to keep it that way. >>>> >>>> Also please keep in mind that the spec will continue to evolve. If you >>>> can work around the limitations of the current spec for a few more >>>> months I think you will be pleased with forthcoming revisions. >>>> >>>> -Ken >>>> >>>> > JD >>>> > >>>> > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell >>>> wrote: >>>> >> >>>> >> (off-list) >>>> >> >>>> >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis >>> > >>>> >> wrote: >>>> >> > My bad, you're right. Again I site the stats from multiple >>>> sources at >>>> >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >>>> >> > Doesn't matter though, I guess we won't see volume textures until >>>> Chris >>>> >> > says >>>> >> > we can have them. Unless of course Gregg would be willing to have >>>> >> > Transgaming add it to Angle w/o it being in the official extension >>>> >> > registry. >>>> >> >>>> >> John, >>>> >> >>>> >> Please be polite. Singling out Chris and blaming him on the public >>>> >> mailing list is inappropriate behavior. Additionally, I believe >>>> >> Chris's opinion is the majority opinion in the WebGL working group at >>>> >> this time. >>>> >> >>>> >> If you could convince a browser vendor to add the extension in their >>>> >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in one of >>>> >> the browsers and submit patches -- then perhaps others would add >>>> >> support for the same extension. >>>> >> >>>> >> -Ken >>>> >> >>>> >> P.S. The WebGL spec will continue to evolve. The current set of >>>> >> functionality is not all that will ever be supported. >>>> >> >>>> >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < >>>> callow_mark...@> >>>> >> > wrote: >>>> >> >> >>>> >> >> I think you have that backwards. It's a 4:1 ratio mobile to >>>> desktop. >>>> >> >> >>>> >> >> Regards >>>> >> >> >>>> >> >> -Mark >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> On 06/04/2011 20:05, John Davis wrote: >>>> >> >> >>>> >> >> That's still a 1:4 ratio, the tail is wagging the dog. >>>> >> >> >>>> >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < >>>> callow_mark...@> >>>> >> >> wrote: >>>> >> >>> >>>> >> >>> Those stat's are deeply suspicious. >>>> >> >>> >>>> >> >>> It is widely reported that in Japan the majority of people >>>> access the >>>> >> >>> internet from their mobile devices. A large number of these >>>> devices do >>>> >> >>> not >>>> >> >>> have identifiable operation systems. >>>> >> >>> >>>> >> >>> Another pointer is that when I visited >>>> http://whatsmyuseragent.com, >>>> >> >>> only >>>> >> >>> 4 of the most recent 15 visitors came from desktop devices. >>>> >> >>> >>>> >> >>> Regards >>>> >> >>> >>>> >> >>> -Mark >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> On 06/04/2011 11:56, John Davis wrote: >>>> >> >>> >>>> >> >>> I'm frustrated we are hamstringing the spec due to limitations >>>> on the >>>> >> >>> mobile side. The majority of web browsers out there are not >>>> being >>>> >> >>> used on >>>> >> >>> mobile devices. Call me nuts, but this just doesn't make sense. >>>> >> >>> Look at the Web clients table. >>>> >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >>>> >> >>> Percentage-wise mobile web clients don't amount to squat. >>>> >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin >>> > >>>> >> >>> wrote: >>>> >> >>>> >>>> >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >>>> >> >>>> >>>> >> >>>> > >all of the extensions there are available on at least one >>>> OpenGL >>>> >> >>>> > > ES >>>> >> >>>> > > implementation on mobile devices (iPhone). >>>> >> >>>> > >>>> >> >>>> > Chris, >>>> >> >>>> > >>>> >> >>>> > Why does the above matter if WebGL is never going to be >>>> available >>>> >> >>>> > on >>>> >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS available? >>>> >> >>>> >>>> >> >>>> Are you just making a fatalistic complaint that you're unhappy >>>> with >>>> >> >>>> the >>>> >> >>>> fact that iOS devices don't publicly support WebGL today? Or >>>> did you >>>> >> >>>> get the >>>> >> >>>> impression from me or someone else that iOS will never support >>>> WebGL? >>>> >> >>>> If you >>>> >> >>>> interpreted something I said in that way, then I apologize. No >>>> one at >>>> >> >>>> Apple >>>> >> >>>> can comment on if or when WebGL will be available on iOS. If >>>> you've >>>> >> >>>> gotten >>>> >> >>>> that information from a blog somewhere then you should ignore >>>> it (as >>>> >> >>>> is a >>>> >> >>>> general rule about bloggers and Apple rumors). >>>> >> >>>> >>>> >> >>>> ----- >>>> >> >>>> ~Chris >>>> >> >>>> cmarrin...@ >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>> >>>> >> >> >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Sat Oct 18 15:08:47 2014 From: bja...@ (Benoit Jacob) Date: Sat, 18 Oct 2014 15:08:47 -0700 (PDT) Subject: [Public WebGL] Volume Textures In-Reply-To: References: Message-ID: <2124564507.18012871.1413670127587.JavaMail.zimbra@mozilla.com> Thanks for linking to our WebGL2 prototype implementation. This wiki page was actually out of date, I have just updated (and shortened!) it. Benoit ----- Original Message ----- > John, > Try Mozilla's WebGL 2.0 prototype -- see > https://wiki.mozilla.org/Platform/GFX/WebGL2 . It contains 3D texture > support, and targeting that version of the API will ensure your code is > portable as more WebGL 2 implementations become available. > -Ken > On Sat, Oct 18, 2014 at 9:26 AM, John Davis < jdavis...@ > > wrote: > > Years have gone by, and look were we're at!? For heaven sake, let's just > > add > > it. > > > https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt > > > On Thu, Apr 7, 2011 at 11:35 PM, John Davis < jdavis...@ > > > wrote: > > > > I'll be anxiously waiting :) > > > > > > On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell < kbr...@ > wrote: > > > > > > > On Thu, Apr 7, 2011 at 3:23 AM, John Davis < jdavis...@ > > > > > wrote: > > > > > > > > > > > Ken, > > > > > > > > > > > Vlad mentioned he would like to see the same thing. My perception is > > > > > that > > > > > > > > > > > he was summarily ignored. Didn't he get this whole thing started? Dan > > > > > > > > > > > Ginsburg, OES 2.0 Bible, also ignored. > > > > > > > > > > > Forgive me for singling out Chris, but he seems to have final say on > > > > > just > > > > > > > > > > > about everything, which seems to fly in the face of an "open > > > > > standard". > > > > > > > > > > > Perhaps I should start addressing all members of the working group. > > > > > Who > > > > > > > > > > > all is on the working group? Are they even seeing this dialogue? > > > > > > > > > > I'm pretty sure that most of the people on the WebGL working group are > > > > > > > > > > on this list. I am the chair of the working group (as of last > > > > > > > > > > Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob and > > > > > > > > > > Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as an > > > > > > > > > > outside expert. > > > > > > > > > > All open standards have (or should have) leaders and decision makers. > > > > > > > > > > Chris's opinion is just that, one opinion. We aim to get consensus in > > > > > > > > > > the WG. There are Khronos practices for voting on contentious topics. > > > > > > > > > > In this case, where the WG seems divided, the path of least resistance > > > > > > > > > > forward would be to propose a browser vendor-specific extension rather > > > > > > > > > > than incorporating the OES version of the extension. The latter is > > > > > > > > > > considered "more official" but any browser vendor can put forth the > > > > > > > > > > former. > > > > > > > > > > > I truly believe this spec is going to change everything. It's > > > > > special. > > > > > But > > > > > > > > > > > the handling of it's evolution seems to have some conflicts of > > > > > interest. > > > > > > > > > > > Earlier Chris sited support of IOS devices, which I found > > > > > frightening. > > > > > > > > > > > WebGL should not be limited/dictated by caps in IOS devices. > > > > > > > > > > It isn't. However iOS is a major force in the mobile market and we do > > > > > > > > > > not want to cause fragmentation of WebGL content early in its > > > > > > > > > > lifetime. So far the extensions we have specified and plan to specify > > > > > > > > > > work on desktop, iOS and Android. For the moment we would like to try > > > > > > > > > > to keep it that way. > > > > > > > > > > Also please keep in mind that the spec will continue to evolve. If you > > > > > > > > > > can work around the limitations of the current spec for a few more > > > > > > > > > > months I think you will be pleased with forthcoming revisions. > > > > > > > > > > -Ken > > > > > > > > > > > JD > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell < kbr...@ > > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > >> (off-list) > > > > > > > > > > >> > > > > > > > > > > >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis < > > > > >> jdavis...@ > > > > >> > > > > > > > > > > > >> wrote: > > > > > > > > > > >> > My bad, you're right. Again I site the stats from multiple sources > > > > >> > at > > > > > > > > > > >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > > > > > > > > > >> > Doesn't matter though, I guess we won't see volume textures until > > > > >> > Chris > > > > > > > > > > >> > says > > > > > > > > > > >> > we can have them. Unless of course Gregg would be willing to have > > > > > > > > > > >> > Transgaming add it to Angle w/o it being in the official extension > > > > > > > > > > >> > registry. > > > > > > > > > > >> > > > > > > > > > > >> John, > > > > > > > > > > >> > > > > > > > > > > >> Please be polite. Singling out Chris and blaming him on the public > > > > > > > > > > >> mailing list is inappropriate behavior. Additionally, I believe > > > > > > > > > > >> Chris's opinion is the majority opinion in the WebGL working group > > > > >> at > > > > > > > > > > >> this time. > > > > > > > > > > >> > > > > > > > > > > >> If you could convince a browser vendor to add the extension in their > > > > > > > > > > >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in one > > > > >> of > > > > > > > > > > >> the browsers and submit patches -- then perhaps others would add > > > > > > > > > > >> support for the same extension. > > > > > > > > > > >> > > > > > > > > > > >> -Ken > > > > > > > > > > >> > > > > > > > > > > >> P.S. The WebGL spec will continue to evolve. The current set of > > > > > > > > > > >> functionality is not all that will ever be supported. > > > > > > > > > > >> > > > > > > > > > > >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < > > > > >> > callow_mark...@ > > > > >> > > > > > > > > > > > > >> > wrote: > > > > > > > > > > >> >> > > > > > > > > > > >> >> I think you have that backwards. It's a 4:1 ratio mobile to > > > > >> >> desktop. > > > > > > > > > > >> >> > > > > > > > > > > >> >> Regards > > > > > > > > > > >> >> > > > > > > > > > > >> >> -Mark > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> > > > > > > > > > > >> >> On 06/04/2011 20:05, John Davis wrote: > > > > > > > > > > >> >> > > > > > > > > > > >> >> That's still a 1:4 ratio, the tail is wagging the dog. > > > > > > > > > > >> >> > > > > > > > > > > >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < > > > > >> >> callow_mark...@ > > > > >> >> > > > > > > > > > > > >> >> wrote: > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> Those stat's are deeply suspicious. > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> It is widely reported that in Japan the majority of people > > > > >> >>> access > > > > >> >>> the > > > > > > > > > > >> >>> internet from their mobile devices. A large number of these > > > > >> >>> devices > > > > >> >>> do > > > > > > > > > > >> >>> not > > > > > > > > > > >> >>> have identifiable operation systems. > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> Another pointer is that when I visited > > > > >> >>> http://whatsmyuseragent.com > > > > >> >>> , > > > > > > > > > > >> >>> only > > > > > > > > > > >> >>> 4 of the most recent 15 visitors came from desktop devices. > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> Regards > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> -Mark > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> On 06/04/2011 11:56, John Davis wrote: > > > > > > > > > > >> >>> > > > > > > > > > > >> >>> I'm frustrated we are hamstringing the spec due to limitations > > > > >> >>> on > > > > >> >>> the > > > > > > > > > > >> >>> mobile side. The majority of web browsers out there are not > > > > >> >>> being > > > > > > > > > > >> >>> used on > > > > > > > > > > >> >>> mobile devices. Call me nuts, but this just doesn't make sense. > > > > > > > > > > >> >>> Look at the Web clients table. > > > > > > > > > > >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > > > > > > > > > >> >>> Percentage-wise mobile web clients don't amount to squat. > > > > > > > > > > >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin < > > > > >> >>> cmarrin...@ > > > > >> >>> > > > > > > > > > > > >> >>> wrote: > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> > >all of the extensions there are available on at least one > > > > >> >>>> > >OpenGL > > > > > > > > > > >> >>>> > > ES > > > > > > > > > > >> >>>> > > implementation on mobile devices (iPhone). > > > > > > > > > > >> >>>> > > > > > > > > > > > >> >>>> > Chris, > > > > > > > > > > >> >>>> > > > > > > > > > > > >> >>>> > Why does the above matter if WebGL is never going to be > > > > >> >>>> > available > > > > > > > > > > >> >>>> > on > > > > > > > > > > >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS available? > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> Are you just making a fatalistic complaint that you're unhappy > > > > >> >>>> with > > > > > > > > > > >> >>>> the > > > > > > > > > > >> >>>> fact that iOS devices don't publicly support WebGL today? Or > > > > >> >>>> did > > > > >> >>>> you > > > > > > > > > > >> >>>> get the > > > > > > > > > > >> >>>> impression from me or someone else that iOS will never support > > > > >> >>>> WebGL? > > > > > > > > > > >> >>>> If you > > > > > > > > > > >> >>>> interpreted something I said in that way, then I apologize. No > > > > >> >>>> one > > > > >> >>>> at > > > > > > > > > > >> >>>> Apple > > > > > > > > > > >> >>>> can comment on if or when WebGL will be available on iOS. If > > > > >> >>>> you've > > > > > > > > > > >> >>>> gotten > > > > > > > > > > >> >>>> that information from a blog somewhere then you should ignore > > > > >> >>>> it > > > > >> >>>> (as > > > > > > > > > > >> >>>> is a > > > > > > > > > > >> >>>> general rule about bloggers and Apple rumors). > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> ----- > > > > > > > > > > >> >>>> ~Chris > > > > > > > > > > >> >>>> cmarrin...@ > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>>> > > > > > > > > > > >> >>> > > > > > > > > > > >> >> > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Oct 18 15:12:07 2014 From: kbr...@ (Kenneth Russell) Date: Sat, 18 Oct 2014 15:12:07 -0700 Subject: [Public WebGL] 3D textures In-Reply-To: References: Message-ID: 3D texture support in particular is difficult to add as an extension to WebGL 1.0 both on Windows and on iOS. For Chrome and Firefox on Windows, ANGLE would have to implement the OES_texture_3D extension, which is a distraction at this point. On iOS, the ES 2.0 context doesn't support OES_texture_3D. The only way to provide it as a WebGL 1.0 extension would be to use an ES 3.0 context for WebGL 1.0 behind the scenes, and this would have surprising side-effects such as breaking WEBGL_draw_buffers. WebGL 2 implementations are underway, as is development of the conformance suite. Please bear with browser implementers as we focus on this. Please see https://wiki.mozilla.org/Platform/GFX/WebGL2 and try that prototype. -Ken On Sat, Oct 18, 2014 at 12:04 PM, Florian B?sch wrote: > There was some pushback in earlier discussions against introducing > extensions for things that'll come with WebGL2. Is this still an issue, or > is it ok to propose extensions for stuff that's in WebGL2? > > On Sat, Oct 18, 2014 at 6:21 PM, John Davis > wrote: > >> Since WebGL 2.0 is still a ways out, could we pleeeeeeze add the 3D >> texture extension to IE, FireFox, Chrome and IOS 8/Safari? >> >> https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt >> >> For those of us looking to save bandwidth by using tiled procedural >> textures, this is a big deal. >> >> https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Sat Oct 18 15:13:19 2014 From: jgi...@ (Jeff Gilbert) Date: Sat, 18 Oct 2014 15:13:19 -0700 (PDT) Subject: [Public WebGL] Volume Textures In-Reply-To: References: Message-ID: <60426103.26548500.1413670399049.JavaMail.zimbra@mozilla.com> All browsers? That's really hard to say. I think we could see implementations start popping up in the first half of next year, though. -Jeff ----- Original Message ----- From: "John Davis" To: "Kenneth Russell" Cc: "public webgl" Sent: Saturday, October 18, 2014 3:05:49 PM Subject: Re: [Public WebGL] Volume Textures Waving your finger in the air, what's the ETA on WebGL 2 implementations across all existing webgl browsers? On Sat, Oct 18, 2014 at 5:53 PM, Kenneth Russell wrote: > John, > > Try Mozilla's WebGL 2.0 prototype -- see > https://wiki.mozilla.org/Platform/GFX/WebGL2 . It contains 3D texture > support, and targeting that version of the API will ensure your code is > portable as more WebGL 2 implementations become available. > > -Ken > > > On Sat, Oct 18, 2014 at 9:26 AM, John Davis > wrote: > >> Years have gone by, and look were we're at!? For heaven sake, let's just >> add it. >> >> https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt >> >> >> On Thu, Apr 7, 2011 at 11:35 PM, John Davis >> wrote: >> >>> I'll be anxiously waiting :) >>> >>> >>> On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell wrote: >>> >>>> On Thu, Apr 7, 2011 at 3:23 AM, John Davis >>>> wrote: >>>> > Ken, >>>> > Vlad mentioned he would like to see the same thing. My perception is >>>> that >>>> > he was summarily ignored. Didn't he get this whole thing started? >>>> Dan >>>> > Ginsburg, OES 2.0 Bible, also ignored. >>>> > Forgive me for singling out Chris, but he seems to have final say on >>>> just >>>> > about everything, which seems to fly in the face of an "open >>>> standard". >>>> > Perhaps I should start addressing all members of the working group. >>>> Who >>>> > all is on the working group? Are they even seeing this dialogue? >>>> >>>> I'm pretty sure that most of the people on the WebGL working group are >>>> on this list. I am the chair of the working group (as of last >>>> Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob and >>>> Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as an >>>> outside expert. >>>> >>>> All open standards have (or should have) leaders and decision makers. >>>> Chris's opinion is just that, one opinion. We aim to get consensus in >>>> the WG. There are Khronos practices for voting on contentious topics. >>>> In this case, where the WG seems divided, the path of least resistance >>>> forward would be to propose a browser vendor-specific extension rather >>>> than incorporating the OES version of the extension. The latter is >>>> considered "more official" but any browser vendor can put forth the >>>> former. >>>> >>>> > I truly believe this spec is going to change everything. It's >>>> special. But >>>> > the handling of it's evolution seems to have some conflicts of >>>> interest. >>>> > Earlier Chris sited support of IOS devices, which I found >>>> frightening. >>>> > WebGL should not be limited/dictated by caps in IOS devices. >>>> >>>> It isn't. However iOS is a major force in the mobile market and we do >>>> not want to cause fragmentation of WebGL content early in its >>>> lifetime. So far the extensions we have specified and plan to specify >>>> work on desktop, iOS and Android. For the moment we would like to try >>>> to keep it that way. >>>> >>>> Also please keep in mind that the spec will continue to evolve. If you >>>> can work around the limitations of the current spec for a few more >>>> months I think you will be pleased with forthcoming revisions. >>>> >>>> -Ken >>>> >>>> > JD >>>> > >>>> > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell >>>> wrote: >>>> >> >>>> >> (off-list) >>>> >> >>>> >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis >>> > >>>> >> wrote: >>>> >> > My bad, you're right. Again I site the stats from multiple >>>> sources at >>>> >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >>>> >> > Doesn't matter though, I guess we won't see volume textures until >>>> Chris >>>> >> > says >>>> >> > we can have them. Unless of course Gregg would be willing to have >>>> >> > Transgaming add it to Angle w/o it being in the official extension >>>> >> > registry. >>>> >> >>>> >> John, >>>> >> >>>> >> Please be polite. Singling out Chris and blaming him on the public >>>> >> mailing list is inappropriate behavior. Additionally, I believe >>>> >> Chris's opinion is the majority opinion in the WebGL working group at >>>> >> this time. >>>> >> >>>> >> If you could convince a browser vendor to add the extension in their >>>> >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in one of >>>> >> the browsers and submit patches -- then perhaps others would add >>>> >> support for the same extension. >>>> >> >>>> >> -Ken >>>> >> >>>> >> P.S. The WebGL spec will continue to evolve. The current set of >>>> >> functionality is not all that will ever be supported. >>>> >> >>>> >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < >>>> callow_mark...@> >>>> >> > wrote: >>>> >> >> >>>> >> >> I think you have that backwards. It's a 4:1 ratio mobile to >>>> desktop. >>>> >> >> >>>> >> >> Regards >>>> >> >> >>>> >> >> -Mark >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> On 06/04/2011 20:05, John Davis wrote: >>>> >> >> >>>> >> >> That's still a 1:4 ratio, the tail is wagging the dog. >>>> >> >> >>>> >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < >>>> callow_mark...@> >>>> >> >> wrote: >>>> >> >>> >>>> >> >>> Those stat's are deeply suspicious. >>>> >> >>> >>>> >> >>> It is widely reported that in Japan the majority of people >>>> access the >>>> >> >>> internet from their mobile devices. A large number of these >>>> devices do >>>> >> >>> not >>>> >> >>> have identifiable operation systems. >>>> >> >>> >>>> >> >>> Another pointer is that when I visited >>>> http://whatsmyuseragent.com, >>>> >> >>> only >>>> >> >>> 4 of the most recent 15 visitors came from desktop devices. >>>> >> >>> >>>> >> >>> Regards >>>> >> >>> >>>> >> >>> -Mark >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> On 06/04/2011 11:56, John Davis wrote: >>>> >> >>> >>>> >> >>> I'm frustrated we are hamstringing the spec due to limitations >>>> on the >>>> >> >>> mobile side. The majority of web browsers out there are not >>>> being >>>> >> >>> used on >>>> >> >>> mobile devices. Call me nuts, but this just doesn't make sense. >>>> >> >>> Look at the Web clients table. >>>> >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >>>> >> >>> Percentage-wise mobile web clients don't amount to squat. >>>> >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin >>> > >>>> >> >>> wrote: >>>> >> >>>> >>>> >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >>>> >> >>>> >>>> >> >>>> > >all of the extensions there are available on at least one >>>> OpenGL >>>> >> >>>> > > ES >>>> >> >>>> > > implementation on mobile devices (iPhone). >>>> >> >>>> > >>>> >> >>>> > Chris, >>>> >> >>>> > >>>> >> >>>> > Why does the above matter if WebGL is never going to be >>>> available >>>> >> >>>> > on >>>> >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS available? >>>> >> >>>> >>>> >> >>>> Are you just making a fatalistic complaint that you're unhappy >>>> with >>>> >> >>>> the >>>> >> >>>> fact that iOS devices don't publicly support WebGL today? Or >>>> did you >>>> >> >>>> get the >>>> >> >>>> impression from me or someone else that iOS will never support >>>> WebGL? >>>> >> >>>> If you >>>> >> >>>> interpreted something I said in that way, then I apologize. No >>>> one at >>>> >> >>>> Apple >>>> >> >>>> can comment on if or when WebGL will be available on iOS. If >>>> you've >>>> >> >>>> gotten >>>> >> >>>> that information from a blog somewhere then you should ignore >>>> it (as >>>> >> >>>> is a >>>> >> >>>> general rule about bloggers and Apple rumors). >>>> >> >>>> >>>> >> >>>> ----- >>>> >> >>>> ~Chris >>>> >> >>>> cmarrin...@ >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>> >>>> >> >> >>>> >> > >>>> >> > >>>> >> >>>> > >>>> > >>>> >>>> >>> >> > ----------------------------------------------------------- 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 jda...@ Sat Oct 18 15:22:45 2014 From: jda...@ (John Davis) Date: Sat, 18 Oct 2014 18:22:45 -0400 Subject: [Public WebGL] Volume Textures In-Reply-To: <60426103.26548500.1413670399049.JavaMail.zimbra@mozilla.com> References: <60426103.26548500.1413670399049.JavaMail.zimbra@mozilla.com> Message-ID: Is ANGLE going to continue, or is this a fresh implementation? On Saturday, October 18, 2014, Jeff Gilbert wrote: > All browsers? That's really hard to say. I think we could see > implementations start popping up in the first half of next year, though. > > -Jeff > > ----- Original Message ----- > From: "John Davis" > > To: "Kenneth Russell" > > Cc: "public webgl" > > Sent: Saturday, October 18, 2014 3:05:49 PM > Subject: Re: [Public WebGL] Volume Textures > > Waving your finger in the air, what's the ETA on WebGL 2 implementations > across all existing webgl browsers? > > On Sat, Oct 18, 2014 at 5:53 PM, Kenneth Russell > wrote: > > > John, > > > > Try Mozilla's WebGL 2.0 prototype -- see > > https://wiki.mozilla.org/Platform/GFX/WebGL2 . It contains 3D texture > > support, and targeting that version of the API will ensure your code is > > portable as more WebGL 2 implementations become available. > > > > -Ken > > > > > > On Sat, Oct 18, 2014 at 9:26 AM, John Davis > > > wrote: > > > >> Years have gone by, and look were we're at!? For heaven sake, let's > just > >> add it. > >> > >> https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt > >> > >> > >> On Thu, Apr 7, 2011 at 11:35 PM, John Davis > > >> wrote: > >> > >>> I'll be anxiously waiting :) > >>> > >>> > >>> On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell > wrote: > >>> > >>>> On Thu, Apr 7, 2011 at 3:23 AM, John Davis > > >>>> wrote: > >>>> > Ken, > >>>> > Vlad mentioned he would like to see the same thing. My perception > is > >>>> that > >>>> > he was summarily ignored. Didn't he get this whole thing started? > >>>> Dan > >>>> > Ginsburg, OES 2.0 Bible, also ignored. > >>>> > Forgive me for singling out Chris, but he seems to have final say on > >>>> just > >>>> > about everything, which seems to fly in the face of an "open > >>>> standard". > >>>> > Perhaps I should start addressing all members of the working group. > >>>> Who > >>>> > all is on the working group? Are they even seeing this dialogue? > >>>> > >>>> I'm pretty sure that most of the people on the WebGL working group are > >>>> on this list. I am the chair of the working group (as of last > >>>> Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob and > >>>> Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as an > >>>> outside expert. > >>>> > >>>> All open standards have (or should have) leaders and decision makers. > >>>> Chris's opinion is just that, one opinion. We aim to get consensus in > >>>> the WG. There are Khronos practices for voting on contentious topics. > >>>> In this case, where the WG seems divided, the path of least resistance > >>>> forward would be to propose a browser vendor-specific extension rather > >>>> than incorporating the OES version of the extension. The latter is > >>>> considered "more official" but any browser vendor can put forth the > >>>> former. > >>>> > >>>> > I truly believe this spec is going to change everything. It's > >>>> special. But > >>>> > the handling of it's evolution seems to have some conflicts of > >>>> interest. > >>>> > Earlier Chris sited support of IOS devices, which I found > >>>> frightening. > >>>> > WebGL should not be limited/dictated by caps in IOS devices. > >>>> > >>>> It isn't. However iOS is a major force in the mobile market and we do > >>>> not want to cause fragmentation of WebGL content early in its > >>>> lifetime. So far the extensions we have specified and plan to specify > >>>> work on desktop, iOS and Android. For the moment we would like to try > >>>> to keep it that way. > >>>> > >>>> Also please keep in mind that the spec will continue to evolve. If you > >>>> can work around the limitations of the current spec for a few more > >>>> months I think you will be pleased with forthcoming revisions. > >>>> > >>>> -Ken > >>>> > >>>> > JD > >>>> > > >>>> > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell > > >>>> wrote: > >>>> >> > >>>> >> (off-list) > >>>> >> > >>>> >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis < > jdavis...@ > >>>> > > >>>> >> wrote: > >>>> >> > My bad, you're right. Again I site the stats from multiple > >>>> sources at > >>>> >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > >>>> >> > Doesn't matter though, I guess we won't see volume textures until > >>>> Chris > >>>> >> > says > >>>> >> > we can have them. Unless of course Gregg would be willing to > have > >>>> >> > Transgaming add it to Angle w/o it being in the official > extension > >>>> >> > registry. > >>>> >> > >>>> >> John, > >>>> >> > >>>> >> Please be polite. Singling out Chris and blaming him on the public > >>>> >> mailing list is inappropriate behavior. Additionally, I believe > >>>> >> Chris's opinion is the majority opinion in the WebGL working group > at > >>>> >> this time. > >>>> >> > >>>> >> If you could convince a browser vendor to add the extension in > their > >>>> >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in one > of > >>>> >> the browsers and submit patches -- then perhaps others would add > >>>> >> support for the same extension. > >>>> >> > >>>> >> -Ken > >>>> >> > >>>> >> P.S. The WebGL spec will continue to evolve. The current set of > >>>> >> functionality is not all that will ever be supported. > >>>> >> > >>>> >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < > >>>> callow_mark...@ > > >>>> >> > wrote: > >>>> >> >> > >>>> >> >> I think you have that backwards. It's a 4:1 ratio mobile to > >>>> desktop. > >>>> >> >> > >>>> >> >> Regards > >>>> >> >> > >>>> >> >> -Mark > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> On 06/04/2011 20:05, John Davis wrote: > >>>> >> >> > >>>> >> >> That's still a 1:4 ratio, the tail is wagging the dog. > >>>> >> >> > >>>> >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < > >>>> callow_mark...@ > > >>>> >> >> wrote: > >>>> >> >>> > >>>> >> >>> Those stat's are deeply suspicious. > >>>> >> >>> > >>>> >> >>> It is widely reported that in Japan the majority of people > >>>> access the > >>>> >> >>> internet from their mobile devices. A large number of these > >>>> devices do > >>>> >> >>> not > >>>> >> >>> have identifiable operation systems. > >>>> >> >>> > >>>> >> >>> Another pointer is that when I visited > >>>> http://whatsmyuseragent.com, > >>>> >> >>> only > >>>> >> >>> 4 of the most recent 15 visitors came from desktop devices. > >>>> >> >>> > >>>> >> >>> Regards > >>>> >> >>> > >>>> >> >>> -Mark > >>>> >> >>> > >>>> >> >>> > >>>> >> >>> > >>>> >> >>> On 06/04/2011 11:56, John Davis wrote: > >>>> >> >>> > >>>> >> >>> I'm frustrated we are hamstringing the spec due to limitations > >>>> on the > >>>> >> >>> mobile side. The majority of web browsers out there are not > >>>> being > >>>> >> >>> used on > >>>> >> >>> mobile devices. Call me nuts, but this just doesn't make > sense. > >>>> >> >>> Look at the Web clients table. > >>>> >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > >>>> >> >>> Percentage-wise mobile web clients don't amount to squat. > >>>> >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin < > cmarrin...@ > >>>> > > >>>> >> >>> wrote: > >>>> >> >>>> > >>>> >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: > >>>> >> >>>> > >>>> >> >>>> > >all of the extensions there are available on at least one > >>>> OpenGL > >>>> >> >>>> > > ES > >>>> >> >>>> > > implementation on mobile devices (iPhone). > >>>> >> >>>> > > >>>> >> >>>> > Chris, > >>>> >> >>>> > > >>>> >> >>>> > Why does the above matter if WebGL is never going to be > >>>> available > >>>> >> >>>> > on > >>>> >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS > available? > >>>> >> >>>> > >>>> >> >>>> Are you just making a fatalistic complaint that you're unhappy > >>>> with > >>>> >> >>>> the > >>>> >> >>>> fact that iOS devices don't publicly support WebGL today? Or > >>>> did you > >>>> >> >>>> get the > >>>> >> >>>> impression from me or someone else that iOS will never support > >>>> WebGL? > >>>> >> >>>> If you > >>>> >> >>>> interpreted something I said in that way, then I apologize. No > >>>> one at > >>>> >> >>>> Apple > >>>> >> >>>> can comment on if or when WebGL will be available on iOS. If > >>>> you've > >>>> >> >>>> gotten > >>>> >> >>>> that information from a blog somewhere then you should ignore > >>>> it (as > >>>> >> >>>> is a > >>>> >> >>>> general rule about bloggers and Apple rumors). > >>>> >> >>>> > >>>> >> >>>> ----- > >>>> >> >>>> ~Chris > >>>> >> >>>> cmarrin...@ > >>>> >> >>>> > >>>> >> >>>> > >>>> >> >>>> > >>>> >> >>>> > >>>> >> >>>> > >>>> >> >>> > >>>> >> >> > >>>> >> > > >>>> >> > > >>>> >> > >>>> > > >>>> > > >>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Oct 18 15:27:57 2014 From: kbr...@ (Kenneth Russell) Date: Sat, 18 Oct 2014 15:27:57 -0700 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: <442928014.26110171.1413415782391.JavaMail.zimbra@mozilla.com> References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> <442928014.26110171.1413415782391.JavaMail.zimbra@mozilla.com> Message-ID: After discussion in the working group this week texImage3D has been added back to the spec: https://www.khronos.org/registry/webgl/specs/latest/2.0/ . -Ken On Wed, Oct 15, 2014 at 4:29 PM, Jeff Gilbert wrote: > It sounds like if we want to track GLES3, we should more closely do so, > even if we disagree with components of it. Yes, it would be better if no > one ever used texImage3d, but if we count soon-to-be-ported apps as > 'existing code', then we unfortunately have a pretty good reason not to > remove texImage3d. > > ----- Original Message ----- > From: "Kenneth Russell" > To: "Benoit Jacob" > Cc: "Jukka Jyl?nki" , "public webgl" < > public_webgl...@> > Sent: Wednesday, October 15, 2014 4:02:16 PM > Subject: Re: [Public WebGL] Removal of glTexImage3D entry point? > > This is a good point. Thanks for catching it. It looks like the RED format > is the preferred way to get a single-channel texture going forward, but > switching to that format requires updating shaders, or using texture > swizzling -- and if the application's using texture swizzling, that would > require significant bookkeeping behind the scenes. > > Since there hasn't been any other feedback from WebGL implementers, I'll > bring up this topic on the next working group conference call. > > Out of curiosity is it not feasible to ask the developer of this > application to update it to not use this deprecated texture format? > > -Ken > > > On Wed, Oct 15, 2014 at 3:31 PM, Benoit Jacob wrote: > > > I just ran into another, maybe deeper problem with the removal of > > texImage3D: if my understanding of the spec is correct, it removes > > functionality. > > > > I have an OpenGL ES 3 application that uses a 3D texture with ALPHA > > format. Is there any way to get that with texStorage3D? texStorage3D only > > accepts sized internalformats (indeed, it does not take a type parameter, > > so an unsized internalformat would remain ambiguous). But there is no > sized > > internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F > and > > ALPHA32F are not listed among valid sized internalformats anywhere in the > > ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly > > described as a dummy effective internalformat not corresponding to any > > GLenum constant, in the ES3 spec (Table 3.2). > > > > The same issue also with LUMINANCE_ALPHA. > > > > I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but > > does there exist any reasonably simple, automatic porting path for ES3 > > applications relying on them? Something that would be reasonable to > > implement in a place like Emscripten's OpenGL-to-WebGL layer? > > > > Benoit > > > > ------------------------------ > > > > You make good points about not arbitrarily subsetting OpenGL ES 3. The > > thought in the WebGL working group at the time was something along the > > lines of: it would have been far better if mutable texture allocation > > functions had not been present in the first place (far simpler texture > > validation logic, etc.); and since 3D textures were being newly > introduced, > > there was an opportunity to avoid widespread usage of an undesirable > entry > > point. (We considered dropping TexImage2D in WebGL 2, but that would have > > broken basically all applications.) > > > > You're correct that it isn't simple to emulate TexImage3D on top of > > TexStorage3D and TexSubImage3D. However, one point is that it should not > be > > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D > instead > > of TexImage3D. For the long term, it still might be a good idea to push > > developers in the direction of using the immutable allocation functions, > > and not providing TexImage3D in Emscripten's emulation layer. > > > > More opinions please? > > > > Thanks, > > > > -Ken > > > > > > > > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob > wrote: > > > >> I concur about the difficulty / impossibility of implementing texImage3D > >> in full generality on top of just texStorage3D and texSubImage3D. > >> > >> If the first texture image specification call on a texture is a > >> texImage3D call with level=1 and width=3, then we can't know whether the > >> level 0 image will have width 6 or width 7, which we need to know > >> immediately in order to call texStorage3D. > >> > >> In the short term, I'm hoping that the only application code that we > have > >> to worry about in the short term will always upload the level 0 image > >> first. Then, we still have to assume that a mipmap will be wanted, but > >> that's not a big deal because 1) the mipmap memory usage overhead for a > >> cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the size > of > >> the level 0 image, and 2) when using texImage3D, a similar memory > >> allocation problem is handed over to the OpenGL implementation anyway. > >> > >> So I'm confident that for Emscripten we can do something that will > >> support the majority of reasonable applications in the short term, but > in > >> the long term, it's unfortunate to have to give up implementing all of > ES3. > >> Think emscriptening test suites, etc. So while this isn't a short-term > >> emergency, I think that if we stick to the removal of texImage3D, it's > >> going to haunt us. > >> > >> Benoit > >> > >> ------------------------------ > >> > >> Hi, > >> > >> in the current form, WebGL 2 spec is planning to remove a GLES3 entry > >> point it finds to be of "bad form" and use in modern code should be > >> avoided. See > >> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and > >> https://github.com/KhronosGroup/WebGL/issues/542 . > >> > >> While one can agree that calling glTexStorage3D is of more modern form > >> than calling glTexImage3D, I don't agree that it is correct that WebGL 2 > >> should start deprecating/erasing API functionality on its own. > Especially > >> when reading the comments in the issue tracker, the rationale seems to > not > >> be technical, but only for cleaning and peace of mind purposes. However, > >> these kind of changes would break existing GLES3 code that is compiled > over > >> to the web via Emscripten. Therefore I would recommend that WebGL 2 did > not > >> arbitrate API cleanups like this, unless the emulation path is a trivial > >> one that can be documented in the spec itself. What do you think? > >> > >> Jukka > >> > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sat Oct 18 15:30:20 2014 From: jda...@ (John Davis) Date: Sat, 18 Oct 2014 18:30:20 -0400 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> <442928014.26110171.1413415782391.JavaMail.zimbra@mozilla.com> Message-ID: Great! On Saturday, October 18, 2014, Kenneth Russell wrote: > After discussion in the working group this week texImage3D has been added > back to the spec: https://www.khronos.org/registry/webgl/specs/latest/2.0/ > . > > -Ken > > > On Wed, Oct 15, 2014 at 4:29 PM, Jeff Gilbert > wrote: > >> It sounds like if we want to track GLES3, we should more closely do so, >> even if we disagree with components of it. Yes, it would be better if no >> one ever used texImage3d, but if we count soon-to-be-ported apps as >> 'existing code', then we unfortunately have a pretty good reason not to >> remove texImage3d. >> >> ----- Original Message ----- >> From: "Kenneth Russell" > > >> To: "Benoit Jacob" > > >> Cc: "Jukka Jyl?nki" > >, "public webgl" < >> public_webgl...@ >> > >> Sent: Wednesday, October 15, 2014 4:02:16 PM >> Subject: Re: [Public WebGL] Removal of glTexImage3D entry point? >> >> This is a good point. Thanks for catching it. It looks like the RED format >> is the preferred way to get a single-channel texture going forward, but >> switching to that format requires updating shaders, or using texture >> swizzling -- and if the application's using texture swizzling, that would >> require significant bookkeeping behind the scenes. >> >> Since there hasn't been any other feedback from WebGL implementers, I'll >> bring up this topic on the next working group conference call. >> >> Out of curiosity is it not feasible to ask the developer of this >> application to update it to not use this deprecated texture format? >> >> -Ken >> >> >> On Wed, Oct 15, 2014 at 3:31 PM, Benoit Jacob > > wrote: >> >> > I just ran into another, maybe deeper problem with the removal of >> > texImage3D: if my understanding of the spec is correct, it removes >> > functionality. >> > >> > I have an OpenGL ES 3 application that uses a 3D texture with ALPHA >> > format. Is there any way to get that with texStorage3D? texStorage3D >> only >> > accepts sized internalformats (indeed, it does not take a type >> parameter, >> > so an unsized internalformat would remain ambiguous). But there is no >> sized >> > internalformat value for any ALPHA format in the spec: ALPHA8, ALPHA16F >> and >> > ALPHA32F are not listed among valid sized internalformats anywhere in >> the >> > ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly >> > described as a dummy effective internalformat not corresponding to any >> > GLenum constant, in the ES3 spec (Table 3.2). >> > >> > The same issue also with LUMINANCE_ALPHA. >> > >> > I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, but >> > does there exist any reasonably simple, automatic porting path for ES3 >> > applications relying on them? Something that would be reasonable to >> > implement in a place like Emscripten's OpenGL-to-WebGL layer? >> > >> > Benoit >> > >> > ------------------------------ >> > >> > You make good points about not arbitrarily subsetting OpenGL ES 3. The >> > thought in the WebGL working group at the time was something along the >> > lines of: it would have been far better if mutable texture allocation >> > functions had not been present in the first place (far simpler texture >> > validation logic, etc.); and since 3D textures were being newly >> introduced, >> > there was an opportunity to avoid widespread usage of an undesirable >> entry >> > point. (We considered dropping TexImage2D in WebGL 2, but that would >> have >> > broken basically all applications.) >> > >> > You're correct that it isn't simple to emulate TexImage3D on top of >> > TexStorage3D and TexSubImage3D. However, one point is that it should >> not be >> > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D >> instead >> > of TexImage3D. For the long term, it still might be a good idea to push >> > developers in the direction of using the immutable allocation functions, >> > and not providing TexImage3D in Emscripten's emulation layer. >> > >> > More opinions please? >> > >> > Thanks, >> > >> > -Ken >> > >> > >> > >> > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob > > wrote: >> > >> >> I concur about the difficulty / impossibility of implementing >> texImage3D >> >> in full generality on top of just texStorage3D and texSubImage3D. >> >> >> >> If the first texture image specification call on a texture is a >> >> texImage3D call with level=1 and width=3, then we can't know whether >> the >> >> level 0 image will have width 6 or width 7, which we need to know >> >> immediately in order to call texStorage3D. >> >> >> >> In the short term, I'm hoping that the only application code that we >> have >> >> to worry about in the short term will always upload the level 0 image >> >> first. Then, we still have to assume that a mipmap will be wanted, but >> >> that's not a big deal because 1) the mipmap memory usage overhead for a >> >> cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the >> size of >> >> the level 0 image, and 2) when using texImage3D, a similar memory >> >> allocation problem is handed over to the OpenGL implementation anyway. >> >> >> >> So I'm confident that for Emscripten we can do something that will >> >> support the majority of reasonable applications in the short term, but >> in >> >> the long term, it's unfortunate to have to give up implementing all of >> ES3. >> >> Think emscriptening test suites, etc. So while this isn't a short-term >> >> emergency, I think that if we stick to the removal of texImage3D, it's >> >> going to haunt us. >> >> >> >> Benoit >> >> >> >> ------------------------------ >> >> >> >> Hi, >> >> >> >> in the current form, WebGL 2 spec is planning to remove a GLES3 entry >> >> point it finds to be of "bad form" and use in modern code should be >> >> avoided. See >> >> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and >> >> https://github.com/KhronosGroup/WebGL/issues/542 . >> >> >> >> While one can agree that calling glTexStorage3D is of more modern form >> >> than calling glTexImage3D, I don't agree that it is correct that WebGL >> 2 >> >> should start deprecating/erasing API functionality on its own. >> Especially >> >> when reading the comments in the issue tracker, the rationale seems to >> not >> >> be technical, but only for cleaning and peace of mind purposes. >> However, >> >> these kind of changes would break existing GLES3 code that is compiled >> over >> >> to the web via Emscripten. Therefore I would recommend that WebGL 2 >> did not >> >> arbitrate API cleanups like this, unless the emulation path is a >> trivial >> >> one that can be documented in the spec itself. What do you think? >> >> >> >> Jukka >> >> >> >> >> >> >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Oct 18 15:36:36 2014 From: kbr...@ (Kenneth Russell) Date: Sat, 18 Oct 2014 15:36:36 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <60426103.26548500.1413670399049.JavaMail.zimbra@mozilla.com> Message-ID: ANGLE -- in a new multi-platform incarnation -- will be the basis of Chrome's WebGL 2.0 implementation on all platforms. See https://code.google.com/p/angleproject/wiki/MANGLE for a detailed design doc. -Ken On Sat, Oct 18, 2014 at 3:22 PM, John Davis wrote: > Is ANGLE going to continue, or is this a fresh implementation? > > > On Saturday, October 18, 2014, Jeff Gilbert wrote: > >> All browsers? That's really hard to say. I think we could see >> implementations start popping up in the first half of next year, though. >> >> -Jeff >> >> ----- Original Message ----- >> From: "John Davis" >> To: "Kenneth Russell" >> Cc: "public webgl" >> Sent: Saturday, October 18, 2014 3:05:49 PM >> Subject: Re: [Public WebGL] Volume Textures >> >> Waving your finger in the air, what's the ETA on WebGL 2 implementations >> across all existing webgl browsers? >> >> On Sat, Oct 18, 2014 at 5:53 PM, Kenneth Russell wrote: >> >> > John, >> > >> > Try Mozilla's WebGL 2.0 prototype -- see >> > https://wiki.mozilla.org/Platform/GFX/WebGL2 . It contains 3D texture >> > support, and targeting that version of the API will ensure your code is >> > portable as more WebGL 2 implementations become available. >> > >> > -Ken >> > >> > >> > On Sat, Oct 18, 2014 at 9:26 AM, John Davis >> > wrote: >> > >> >> Years have gone by, and look were we're at!? For heaven sake, let's >> just >> >> add it. >> >> >> >> >> https://www.khronos.org/registry/gles/extensions/OES/OES_texture_3D.txt >> >> >> >> >> >> On Thu, Apr 7, 2011 at 11:35 PM, John Davis >> >> wrote: >> >> >> >>> I'll be anxiously waiting :) >> >>> >> >>> >> >>> On Thu, Apr 7, 2011 at 3:33 PM, Kenneth Russell >> wrote: >> >>> >> >>>> On Thu, Apr 7, 2011 at 3:23 AM, John Davis > > >> >>>> wrote: >> >>>> > Ken, >> >>>> > Vlad mentioned he would like to see the same thing. My perception >> is >> >>>> that >> >>>> > he was summarily ignored. Didn't he get this whole thing started? >> >>>> Dan >> >>>> > Ginsburg, OES 2.0 Bible, also ignored. >> >>>> > Forgive me for singling out Chris, but he seems to have final say >> on >> >>>> just >> >>>> > about everything, which seems to fly in the face of an "open >> >>>> standard". >> >>>> > Perhaps I should start addressing all members of the working >> group. >> >>>> Who >> >>>> > all is on the working group? Are they even seeing this dialogue? >> >>>> >> >>>> I'm pretty sure that most of the people on the WebGL working group >> are >> >>>> on this list. I am the chair of the working group (as of last >> >>>> Thursday, taking over from Vlad). Chris, Mark Callow, Benoit Jacob >> and >> >>>> Zhenyao Mo are all on the WG, and Vlad will likely be re-invited as >> an >> >>>> outside expert. >> >>>> >> >>>> All open standards have (or should have) leaders and decision makers. >> >>>> Chris's opinion is just that, one opinion. We aim to get consensus in >> >>>> the WG. There are Khronos practices for voting on contentious topics. >> >>>> In this case, where the WG seems divided, the path of least >> resistance >> >>>> forward would be to propose a browser vendor-specific extension >> rather >> >>>> than incorporating the OES version of the extension. The latter is >> >>>> considered "more official" but any browser vendor can put forth the >> >>>> former. >> >>>> >> >>>> > I truly believe this spec is going to change everything. It's >> >>>> special. But >> >>>> > the handling of it's evolution seems to have some conflicts of >> >>>> interest. >> >>>> > Earlier Chris sited support of IOS devices, which I found >> >>>> frightening. >> >>>> > WebGL should not be limited/dictated by caps in IOS devices. >> >>>> >> >>>> It isn't. However iOS is a major force in the mobile market and we do >> >>>> not want to cause fragmentation of WebGL content early in its >> >>>> lifetime. So far the extensions we have specified and plan to specify >> >>>> work on desktop, iOS and Android. For the moment we would like to try >> >>>> to keep it that way. >> >>>> >> >>>> Also please keep in mind that the spec will continue to evolve. If >> you >> >>>> can work around the limitations of the current spec for a few more >> >>>> months I think you will be pleased with forthcoming revisions. >> >>>> >> >>>> -Ken >> >>>> >> >>>> > JD >> >>>> > >> >>>> > On Wed, Apr 6, 2011 at 9:47 PM, Kenneth Russell >> >>>> wrote: >> >>>> >> >> >>>> >> (off-list) >> >>>> >> >> >>>> >> On Wed, Apr 6, 2011 at 7:18 PM, John Davis < >> jdavis...@ >> >>>> > >> >>>> >> wrote: >> >>>> >> > My bad, you're right. Again I site the stats from multiple >> >>>> sources at >> >>>> >> > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >> >>>> >> > Doesn't matter though, I guess we won't see volume textures >> until >> >>>> Chris >> >>>> >> > says >> >>>> >> > we can have them. Unless of course Gregg would be willing to >> have >> >>>> >> > Transgaming add it to Angle w/o it being in the official >> extension >> >>>> >> > registry. >> >>>> >> >> >>>> >> John, >> >>>> >> >> >>>> >> Please be polite. Singling out Chris and blaming him on the public >> >>>> >> mailing list is inappropriate behavior. Additionally, I believe >> >>>> >> Chris's opinion is the majority opinion in the WebGL working >> group at >> >>>> >> this time. >> >>>> >> >> >>>> >> If you could convince a browser vendor to add the extension in >> their >> >>>> >> namespace (MOZ_texture_3D?) -- or perhaps even implement it in >> one of >> >>>> >> the browsers and submit patches -- then perhaps others would add >> >>>> >> support for the same extension. >> >>>> >> >> >>>> >> -Ken >> >>>> >> >> >>>> >> P.S. The WebGL spec will continue to evolve. The current set of >> >>>> >> functionality is not all that will ever be supported. >> >>>> >> >> >>>> >> > On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow < >> >>>> callow_mark...@> >> >>>> >> > wrote: >> >>>> >> >> >> >>>> >> >> I think you have that backwards. It's a 4:1 ratio mobile to >> >>>> desktop. >> >>>> >> >> >> >>>> >> >> Regards >> >>>> >> >> >> >>>> >> >> -Mark >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> >> >>>> >> >> On 06/04/2011 20:05, John Davis wrote: >> >>>> >> >> >> >>>> >> >> That's still a 1:4 ratio, the tail is wagging the dog. >> >>>> >> >> >> >>>> >> >> On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow < >> >>>> callow_mark...@> >> >>>> >> >> wrote: >> >>>> >> >>> >> >>>> >> >>> Those stat's are deeply suspicious. >> >>>> >> >>> >> >>>> >> >>> It is widely reported that in Japan the majority of people >> >>>> access the >> >>>> >> >>> internet from their mobile devices. A large number of these >> >>>> devices do >> >>>> >> >>> not >> >>>> >> >>> have identifiable operation systems. >> >>>> >> >>> >> >>>> >> >>> Another pointer is that when I visited >> >>>> http://whatsmyuseragent.com, >> >>>> >> >>> only >> >>>> >> >>> 4 of the most recent 15 visitors came from desktop devices. >> >>>> >> >>> >> >>>> >> >>> Regards >> >>>> >> >>> >> >>>> >> >>> -Mark >> >>>> >> >>> >> >>>> >> >>> >> >>>> >> >>> >> >>>> >> >>> On 06/04/2011 11:56, John Davis wrote: >> >>>> >> >>> >> >>>> >> >>> I'm frustrated we are hamstringing the spec due to limitations >> >>>> on the >> >>>> >> >>> mobile side. The majority of web browsers out there are not >> >>>> being >> >>>> >> >>> used on >> >>>> >> >>> mobile devices. Call me nuts, but this just doesn't make >> sense. >> >>>> >> >>> Look at the Web clients table. >> >>>> >> >>> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >> >>>> >> >>> Percentage-wise mobile web clients don't amount to squat. >> >>>> >> >>> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin < >> cmarrin...@ >> >>>> > >> >>>> >> >>> wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >> >>>> >> >>>> >> >>>> >> >>>> > >all of the extensions there are available on at least one >> >>>> OpenGL >> >>>> >> >>>> > > ES >> >>>> >> >>>> > > implementation on mobile devices (iPhone). >> >>>> >> >>>> > >> >>>> >> >>>> > Chris, >> >>>> >> >>>> > >> >>>> >> >>>> > Why does the above matter if WebGL is never going to be >> >>>> available >> >>>> >> >>>> > on >> >>>> >> >>>> > iPhone/iPad/AppleTV? Why don't we focus on what IS >> available? >> >>>> >> >>>> >> >>>> >> >>>> Are you just making a fatalistic complaint that you're >> unhappy >> >>>> with >> >>>> >> >>>> the >> >>>> >> >>>> fact that iOS devices don't publicly support WebGL today? Or >> >>>> did you >> >>>> >> >>>> get the >> >>>> >> >>>> impression from me or someone else that iOS will never >> support >> >>>> WebGL? >> >>>> >> >>>> If you >> >>>> >> >>>> interpreted something I said in that way, then I apologize. >> No >> >>>> one at >> >>>> >> >>>> Apple >> >>>> >> >>>> can comment on if or when WebGL will be available on iOS. If >> >>>> you've >> >>>> >> >>>> gotten >> >>>> >> >>>> that information from a blog somewhere then you should ignore >> >>>> it (as >> >>>> >> >>>> is a >> >>>> >> >>>> general rule about bloggers and Apple rumors). >> >>>> >> >>>> >> >>>> >> >>>> ----- >> >>>> >> >>>> ~Chris >> >>>> >> >>>> cmarrin...@ >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>> >> >>>> >> >> >> >>>> >> > >> >>>> >> > >> >>>> >> >> >>>> > >> >>>> > >> >>>> >> >>>> >> >>> >> >> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 02:59:27 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 05:59:27 -0400 Subject: [Public WebGL] compute shaders Message-ID: Will webgl2 include compute shaders? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 03:27:34 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 06:27:34 -0400 Subject: [Public WebGL] compute shaders In-Reply-To: References: Message-ID: ie Will it be webgl 2.1? Is there a spec yet? On Sun, Oct 19, 2014 at 5:59 AM, John Davis wrote: > Will webgl2 include compute shaders? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 03:45:37 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 12:45:37 +0200 Subject: [Public WebGL] compute shaders In-Reply-To: References: Message-ID: WebGL 2.0 will be an implementation of OpenGL ES 3.0. OpenGL ES 3.0 does not contain compute shaders. OpenGL ES 3.1 contains compute shaders. WebGL 2.1 (afaik) is supposed to be OpenGL ES 3.1. There is no specification for that version of WebGL yet. On Sun, Oct 19, 2014 at 12:27 PM, John Davis wrote: > ie Will it be webgl 2.1? Is there a spec yet? > > > On Sun, Oct 19, 2014 at 5:59 AM, John Davis > wrote: > >> Will webgl2 include compute shaders? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 03:47:42 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 06:47:42 -0400 Subject: [Public WebGL] WebGL working group - leadership Message-ID: Ken, Nothing personal. As chairman of the webgl working group, for over three years, what has been achieved thus far? My perception is the standard progressed much faster under Vlad. If he's willing, why don't we put Vlad back in the driver's seat? JD -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Sun Oct 19 05:36:19 2014 From: khr...@ (Mark Callow) Date: Sun, 19 Oct 2014 21:36:19 +0900 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: <111F718A-A42B-4578-99FD-4B9D35A2CAB6@callow.im> On Oct 19, 2014, at 7:47 PM, John Davis wrote: > Ken, > > Nothing personal. As chairman of the webgl working group, for over three years, what has been achieved thus far? > > My perception is the standard progressed much faster under Vlad. If he's willing, why don't we put Vlad back in the driver's seat? > > JD > When you start from nothing, progress is much easier to see. There is a saying along the lines that the last 10% of a project takes 50% of the time. Well we?ve been in that last 10%, getting robust implementations that pass conformance on all popular OSes. Getting such uniformity of behaviour across implementations and devices is a huge achievement. For some time now work has been underway to turn ANGLE into an OpenGL ES 3.0 implementation, a fairly substantial project. That work is nearing completion so we should start seeing WebGL 2.0 implementations appearing soon. Regards -Mark ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Sun Oct 19 05:46:15 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 14:46:15 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: I'm happy with Kens leadership. Things could always move quicker, but ultimately WebGL will only move as fast as the implementations will. On Sun, Oct 19, 2014 at 12:47 PM, John Davis wrote: > > Nothing personal. As chairman of the webgl working group, for over three > years, what has been achieved thus far? > - 15 ratified extensions - 7 community approved extensions - 5 draft extensions - 4 proposed extensions - Comprehensive conformance test coverage - Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 mobile browsers (native android, Chrome Mobile and Safari) - Advancement of WebGL overall from 60% to 73%, 62% -> 77% on desktops, 2.4% -> 48% on mobiles. - 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), 1 revision of of the WebGL 2.0 standard. - Implementations getting more robust - Microsoft has joined the WG There are things that have happened in the last 3 years, a lot of things. My perception is the standard progressed much faster under Vlad. If he's > willing, why don't we put Vlad back in the driver's seat? > Have you discussed this proposal with Ken and Vlad privately? -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Sun Oct 19 06:14:34 2014 From: flo...@ (Floh) Date: Sun, 19 Oct 2014 15:14:34 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: I'm mostly a quiet lurker here, but I'll have to agree with Florian and Mark. WebGL can and should only progress as fast as GLES, but has to cover a much broader 'ecosystem' then any single OpenGL implementation (all platforms, all GPUs (desktop and mobile), all operating systems, all browsers, combined!), and WebGL programs are expected to 'just run'. It must be like herding cats, and it would have been much more likely that WebGL would have become a failed platform. The WebGL process is the most transparent of all 3D APIs, everything is open, and in 20 years in the games industry I have never seen faster response and fix times when reporting (Chrome or Firefox) WebGL bugs. Ok, that praise goes mostly to the browser teams, but WebGL is a child of that open development philosophy, and this is a very good thing (and it creates pressure on the IE and Safari teams to be more open and 'agile' as well). I'm much more interested in stability and painless multi-platform support with a solid base feature-set which also runs on older devices(!) then having dozens of extensions, where none of them works on more then 20% of all devices. Thumbs up, Ken :) -Floh. On Sun, Oct 19, 2014 at 2:46 PM, Florian B?sch wrote: > I'm happy with Kens leadership. Things could always move quicker, but > ultimately WebGL will only move as fast as the implementations will. > > On Sun, Oct 19, 2014 at 12:47 PM, John Davis > wrote: >> >> Nothing personal. As chairman of the webgl working group, for over three >> years, what has been achieved thus far? > > 15 ratified extensions > 7 community approved extensions > 5 draft extensions > 4 proposed extensions > Comprehensive conformance test coverage > Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 mobile browsers > (native android, Chrome Mobile and Safari) > Advancement of WebGL overall from 60% to 73%, 62% -> 77% on desktops, 2.4% > -> 48% on mobiles. > 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), 1 revision of > of the WebGL 2.0 standard. > Implementations getting more robust > Microsoft has joined the WG > > There are things that have happened in the last 3 years, a lot of things. > >> My perception is the standard progressed much faster under Vlad. If he's >> willing, why don't we put Vlad back in the driver's seat? > > > Have you discussed this proposal with Ken and Vlad privately? ----------------------------------------------------------- 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 jda...@ Sun Oct 19 06:42:57 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 09:42:57 -0400 Subject: Fwd: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: +webgl ---------- Forwarded message ---------- From: John Davis Date: Sun, Oct 19, 2014 at 9:39 AM Subject: Re: [Public WebGL] WebGL working group - leadership To: Florian B?sch Exactly, couldn't have said it better myself. MANGLE is a monstrous undertaking. However, it should not be allowed to slow down webgl for ES 3.1. For ES 3.1, webgl on IOS and Android, the implementation should be straightforward. The priority should be on these devices, the desktop can then catch up later. To me, WebGL is highly disruptive, and has the potential to take humankind to a whole new level. Allowing information to be created/assimilated in 3D as opposed to 2D, the implications for learning are MASSIVE. Throw in Occulus and things get really interesting. By being too 'pragmatic' we are holding back the realization of an amazing future. On Sun, Oct 19, 2014 at 9:26 AM, Florian B?sch wrote: > Well the major roadblock to shaking things up is WebGL 2.0. And it's true > that this is taking an abysmally long time. But that's not a problem of the > standard really, it's the implementations that're difficult. Once an > implementation has achieved the move (to mangle, ES3/D3D11 etc.) it should > be much easier to move forward to the next one (ES 3.1). > > On Sun, Oct 19, 2014 at 3:14 PM, John Davis > wrote: > >> Agree, what's happening is wonderful. But while the market is digesting, >> the committee should be leading. There is always a balance between being >> too pragmatic and too passionate. My perception is that we're erring on >> the side of being too pragmatic. Three years is a long time, why not shake >> things up a bit? >> >> On Sun, Oct 19, 2014 at 9:04 AM, Florian B?sch wrote: >> >>> I'd always like to see capabilities emerge faster. And WebGL 2.0 will be >>> a nice jump. The past 3 years I've made my living almost exclusively >>> implementing WebGL projects. There might not have happened terribly much in >>> terms of capabilities (although don't overlook the extensions that did get >>> approved and implemented, those help a lot). >>> >>> What I did observe trough the last 3 years was that the demand for WebGL >>> (from a freelancers perspective) is rising meteorically, in line with its >>> uses in non-demo applications. I don't think that a bit of stability in the >>> standard is a bad thing, it allows the market to consolidate and for >>> implementations to get better and more robust. After all, native support >>> for HW accelerated rendering is still buggy and unreliable, and WebGL has >>> to deal with that too. >>> >>> On Sun, Oct 19, 2014 at 2:57 PM, John Davis >>> wrote: >>> >>>> Over three years ... feels like we're running in place. Closing the >>>> gap between what the hardware can do, and what can be done in the browser, >>>> we haven't come very far. IE11 and IOS8 are fantastic news, luckily they >>>> decided to jump on board. >>>> >>>> >>>> On Sun, Oct 19, 2014 at 8:46 AM, Florian B?sch >>>> wrote: >>>> >>>>> I'm happy with Kens leadership. Things could always move quicker, but >>>>> ultimately WebGL will only move as fast as the implementations will. >>>>> >>>>> On Sun, Oct 19, 2014 at 12:47 PM, John Davis >>>> > wrote: >>>>>> >>>>>> Nothing personal. As chairman of the webgl working group, for over >>>>>> three years, what has been achieved thus far? >>>>>> >>>>> >>>>> - 15 ratified extensions >>>>> - 7 community approved extensions >>>>> - 5 draft extensions >>>>> - 4 proposed extensions >>>>> - Comprehensive conformance test coverage >>>>> - Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 >>>>> mobile browsers (native android, Chrome Mobile and Safari) >>>>> - Advancement of WebGL overall from 60% to 73%, 62% -> 77% on >>>>> desktops, 2.4% -> 48% on mobiles. >>>>> - 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), 1 >>>>> revision of of the WebGL 2.0 standard. >>>>> - Implementations getting more robust >>>>> - Microsoft has joined the WG >>>>> >>>>> There are things that have happened in the last 3 years, a lot of >>>>> things. >>>>> >>>>> My perception is the standard progressed much faster under Vlad. If >>>>>> he's willing, why don't we put Vlad back in the driver's seat? >>>>>> >>>>> >>>>> Have you discussed this proposal with Ken and Vlad privately? >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 06:52:14 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 09:52:14 -0400 Subject: [Public WebGL] ES 3.1 Message-ID: To summarize my rant, the current priority should be webgl for ES 3.1 on IOS, Android, and any other hardware with native ES 3.1 support. Let go of MANGLE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 07:02:46 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 16:02:46 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: I'm fairly confident that no vendor, at this time, will require the WebGL 2.1 standard because there's enough work to get WebGL 1.0 and WebGL 2.0 out the door. I'll also trust that vendors will give advance warning if they feel they're running out of work and are lacking a standard to do next. On Sun, Oct 19, 2014 at 3:42 PM, John Davis wrote: > +webgl > > ---------- Forwarded message ---------- > From: John Davis > Date: Sun, Oct 19, 2014 at 9:39 AM > Subject: Re: [Public WebGL] WebGL working group - leadership > To: Florian B?sch > > > Exactly, couldn't have said it better myself. MANGLE is a monstrous > undertaking. However, it should not be allowed to slow down webgl for ES > 3.1. For ES 3.1, webgl on IOS and Android, the implementation should be > straightforward. The priority should be on these devices, the desktop can > then catch up later. > > To me, WebGL is highly disruptive, and has the potential to take humankind > to a whole new level. Allowing information to be created/assimilated in 3D > as opposed to 2D, the implications for learning are MASSIVE. Throw in > Occulus and things get really interesting. > > By being too 'pragmatic' we are holding back the realization of an amazing > future. > > > On Sun, Oct 19, 2014 at 9:26 AM, Florian B?sch wrote: > >> Well the major roadblock to shaking things up is WebGL 2.0. And it's true >> that this is taking an abysmally long time. But that's not a problem of the >> standard really, it's the implementations that're difficult. Once an >> implementation has achieved the move (to mangle, ES3/D3D11 etc.) it should >> be much easier to move forward to the next one (ES 3.1). >> >> On Sun, Oct 19, 2014 at 3:14 PM, John Davis >> wrote: >> >>> Agree, what's happening is wonderful. But while the market is >>> digesting, the committee should be leading. There is always a balance >>> between being too pragmatic and too passionate. My perception is that >>> we're erring on the side of being too pragmatic. Three years is a long >>> time, why not shake things up a bit? >>> >>> On Sun, Oct 19, 2014 at 9:04 AM, Florian B?sch wrote: >>> >>>> I'd always like to see capabilities emerge faster. And WebGL 2.0 will >>>> be a nice jump. The past 3 years I've made my living almost exclusively >>>> implementing WebGL projects. There might not have happened terribly much in >>>> terms of capabilities (although don't overlook the extensions that did get >>>> approved and implemented, those help a lot). >>>> >>>> What I did observe trough the last 3 years was that the demand for >>>> WebGL (from a freelancers perspective) is rising meteorically, in line with >>>> its uses in non-demo applications. I don't think that a bit of stability in >>>> the standard is a bad thing, it allows the market to consolidate and for >>>> implementations to get better and more robust. After all, native support >>>> for HW accelerated rendering is still buggy and unreliable, and WebGL has >>>> to deal with that too. >>>> >>>> On Sun, Oct 19, 2014 at 2:57 PM, John Davis >>>> wrote: >>>> >>>>> Over three years ... feels like we're running in place. Closing the >>>>> gap between what the hardware can do, and what can be done in the browser, >>>>> we haven't come very far. IE11 and IOS8 are fantastic news, luckily they >>>>> decided to jump on board. >>>>> >>>>> >>>>> On Sun, Oct 19, 2014 at 8:46 AM, Florian B?sch >>>>> wrote: >>>>> >>>>>> I'm happy with Kens leadership. Things could always move quicker, but >>>>>> ultimately WebGL will only move as fast as the implementations will. >>>>>> >>>>>> On Sun, Oct 19, 2014 at 12:47 PM, John Davis < >>>>>> jdavis...@> wrote: >>>>>>> >>>>>>> Nothing personal. As chairman of the webgl working group, for over >>>>>>> three years, what has been achieved thus far? >>>>>>> >>>>>> >>>>>> - 15 ratified extensions >>>>>> - 7 community approved extensions >>>>>> - 5 draft extensions >>>>>> - 4 proposed extensions >>>>>> - Comprehensive conformance test coverage >>>>>> - Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 >>>>>> mobile browsers (native android, Chrome Mobile and Safari) >>>>>> - Advancement of WebGL overall from 60% to 73%, 62% -> 77% on >>>>>> desktops, 2.4% -> 48% on mobiles. >>>>>> - 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), 1 >>>>>> revision of of the WebGL 2.0 standard. >>>>>> - Implementations getting more robust >>>>>> - Microsoft has joined the WG >>>>>> >>>>>> There are things that have happened in the last 3 years, a lot of >>>>>> things. >>>>>> >>>>>> My perception is the standard progressed much faster under Vlad. If >>>>>>> he's willing, why don't we put Vlad back in the driver's seat? >>>>>>> >>>>>> >>>>>> Have you discussed this proposal with Ken and Vlad privately? >>>>>> >>>>> >>>>> >>>> >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Sun Oct 19 07:06:16 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Sun, 19 Oct 2014 17:06:16 +0300 Subject: [Public WebGL] Removal of glTexImage3D entry point? In-Reply-To: References: <261189712.17323491.1413289155953.JavaMail.zimbra@mozilla.com> <1377238346.17589620.1413412289194.JavaMail.zimbra@mozilla.com> <442928014.26110171.1413415782391.JavaMail.zimbra@mozilla.com> Message-ID: This is excellent, thank you! 2014-10-19 1:30 GMT+03:00 John Davis : > Great! > > > On Saturday, October 18, 2014, Kenneth Russell wrote: > >> After discussion in the working group this week texImage3D has been added >> back to the spec: >> https://www.khronos.org/registry/webgl/specs/latest/2.0/ . >> >> -Ken >> >> >> On Wed, Oct 15, 2014 at 4:29 PM, Jeff Gilbert >> wrote: >> >>> It sounds like if we want to track GLES3, we should more closely do so, >>> even if we disagree with components of it. Yes, it would be better if no >>> one ever used texImage3d, but if we count soon-to-be-ported apps as >>> 'existing code', then we unfortunately have a pretty good reason not to >>> remove texImage3d. >>> >>> ----- Original Message ----- >>> From: "Kenneth Russell" >>> To: "Benoit Jacob" >>> Cc: "Jukka Jyl?nki" , "public webgl" < >>> public_webgl...@> >>> Sent: Wednesday, October 15, 2014 4:02:16 PM >>> Subject: Re: [Public WebGL] Removal of glTexImage3D entry point? >>> >>> This is a good point. Thanks for catching it. It looks like the RED >>> format >>> is the preferred way to get a single-channel texture going forward, but >>> switching to that format requires updating shaders, or using texture >>> swizzling -- and if the application's using texture swizzling, that would >>> require significant bookkeeping behind the scenes. >>> >>> Since there hasn't been any other feedback from WebGL implementers, I'll >>> bring up this topic on the next working group conference call. >>> >>> Out of curiosity is it not feasible to ask the developer of this >>> application to update it to not use this deprecated texture format? >>> >>> -Ken >>> >>> >>> On Wed, Oct 15, 2014 at 3:31 PM, Benoit Jacob >>> wrote: >>> >>> > I just ran into another, maybe deeper problem with the removal of >>> > texImage3D: if my understanding of the spec is correct, it removes >>> > functionality. >>> > >>> > I have an OpenGL ES 3 application that uses a 3D texture with ALPHA >>> > format. Is there any way to get that with texStorage3D? texStorage3D >>> only >>> > accepts sized internalformats (indeed, it does not take a type >>> parameter, >>> > so an unsized internalformat would remain ambiguous). But there is no >>> sized >>> > internalformat value for any ALPHA format in the spec: ALPHA8, >>> ALPHA16F and >>> > ALPHA32F are not listed among valid sized internalformats anywhere in >>> the >>> > ES3 spec (e.g. Table 3.2). Moreover, at least ALPHA8 is explicitly >>> > described as a dummy effective internalformat not corresponding to any >>> > GLenum constant, in the ES3 spec (Table 3.2). >>> > >>> > The same issue also with LUMINANCE_ALPHA. >>> > >>> > I understand that ALPHA and LUMINANCE_ALPHA textures are deprecated, >>> but >>> > does there exist any reasonably simple, automatic porting path for ES3 >>> > applications relying on them? Something that would be reasonable to >>> > implement in a place like Emscripten's OpenGL-to-WebGL layer? >>> > >>> > Benoit >>> > >>> > ------------------------------ >>> > >>> > You make good points about not arbitrarily subsetting OpenGL ES 3. The >>> > thought in the WebGL working group at the time was something along the >>> > lines of: it would have been far better if mutable texture allocation >>> > functions had not been present in the first place (far simpler texture >>> > validation logic, etc.); and since 3D textures were being newly >>> introduced, >>> > there was an opportunity to avoid widespread usage of an undesirable >>> entry >>> > point. (We considered dropping TexImage2D in WebGL 2, but that would >>> have >>> > broken basically all applications.) >>> > >>> > You're correct that it isn't simple to emulate TexImage3D on top of >>> > TexStorage3D and TexSubImage3D. However, one point is that it should >>> not be >>> > difficult to change existing OpenGL ES 3.0 code to use TexStorage3D >>> instead >>> > of TexImage3D. For the long term, it still might be a good idea to push >>> > developers in the direction of using the immutable allocation >>> functions, >>> > and not providing TexImage3D in Emscripten's emulation layer. >>> > >>> > More opinions please? >>> > >>> > Thanks, >>> > >>> > -Ken >>> > >>> > >>> > >>> > On Tue, Oct 14, 2014 at 5:19 AM, Benoit Jacob >>> wrote: >>> > >>> >> I concur about the difficulty / impossibility of implementing >>> texImage3D >>> >> in full generality on top of just texStorage3D and texSubImage3D. >>> >> >>> >> If the first texture image specification call on a texture is a >>> >> texImage3D call with level=1 and width=3, then we can't know whether >>> the >>> >> level 0 image will have width 6 or width 7, which we need to know >>> >> immediately in order to call texStorage3D. >>> >> >>> >> In the short term, I'm hoping that the only application code that we >>> have >>> >> to worry about in the short term will always upload the level 0 image >>> >> first. Then, we still have to assume that a mipmap will be wanted, but >>> >> that's not a big deal because 1) the mipmap memory usage overhead for >>> a >>> >> cubic 3D texture is just 1/7 ( = 1/2^3 + 1/4^3 + 1/8^3 + ... ) the >>> size of >>> >> the level 0 image, and 2) when using texImage3D, a similar memory >>> >> allocation problem is handed over to the OpenGL implementation anyway. >>> >> >>> >> So I'm confident that for Emscripten we can do something that will >>> >> support the majority of reasonable applications in the short term, >>> but in >>> >> the long term, it's unfortunate to have to give up implementing all >>> of ES3. >>> >> Think emscriptening test suites, etc. So while this isn't a short-term >>> >> emergency, I think that if we stick to the removal of texImage3D, it's >>> >> going to haunt us. >>> >> >>> >> Benoit >>> >> >>> >> ------------------------------ >>> >> >>> >> Hi, >>> >> >>> >> in the current form, WebGL 2 spec is planning to remove a GLES3 entry >>> >> point it finds to be of "bad form" and use in modern code should be >>> >> avoided. See >>> >> https://www.khronos.org/registry/webgl/specs/latest/2.0/#5.14 and >>> >> https://github.com/KhronosGroup/WebGL/issues/542 . >>> >> >>> >> While one can agree that calling glTexStorage3D is of more modern form >>> >> than calling glTexImage3D, I don't agree that it is correct that >>> WebGL 2 >>> >> should start deprecating/erasing API functionality on its own. >>> Especially >>> >> when reading the comments in the issue tracker, the rationale seems >>> to not >>> >> be technical, but only for cleaning and peace of mind purposes. >>> However, >>> >> these kind of changes would break existing GLES3 code that is >>> compiled over >>> >> to the web via Emscripten. Therefore I would recommend that WebGL 2 >>> did not >>> >> arbitrate API cleanups like this, unless the emulation path is a >>> trivial >>> >> one that can be documented in the spec itself. What do you think? >>> >> >>> >> Jukka >>> >> >>> >> >>> >> >>> > >>> > >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 07:50:53 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 10:50:53 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Not sure I understand, Imagination Technologies ES 3.1 gpu's are coming out the floodgates as we speak. On Sun, Oct 19, 2014 at 10:02 AM, Florian B?sch wrote: > I'm fairly confident that no vendor, at this time, will require the WebGL > 2.1 standard because there's enough work to get WebGL 1.0 and WebGL 2.0 out > the door. I'll also trust that vendors will give advance warning if they > feel they're running out of work and are lacking a standard to do next. > > On Sun, Oct 19, 2014 at 3:42 PM, John Davis > wrote: > >> +webgl >> >> ---------- Forwarded message ---------- >> From: John Davis >> Date: Sun, Oct 19, 2014 at 9:39 AM >> Subject: Re: [Public WebGL] WebGL working group - leadership >> To: Florian B?sch >> >> >> Exactly, couldn't have said it better myself. MANGLE is a monstrous >> undertaking. However, it should not be allowed to slow down webgl for ES >> 3.1. For ES 3.1, webgl on IOS and Android, the implementation should be >> straightforward. The priority should be on these devices, the desktop can >> then catch up later. >> >> To me, WebGL is highly disruptive, and has the potential to take >> humankind to a whole new level. Allowing information to be >> created/assimilated in 3D as opposed to 2D, the implications for learning >> are MASSIVE. Throw in Occulus and things get really interesting. >> >> By being too 'pragmatic' we are holding back the realization of an >> amazing future. >> >> >> On Sun, Oct 19, 2014 at 9:26 AM, Florian B?sch wrote: >> >>> Well the major roadblock to shaking things up is WebGL 2.0. And it's >>> true that this is taking an abysmally long time. But that's not a problem >>> of the standard really, it's the implementations that're difficult. Once an >>> implementation has achieved the move (to mangle, ES3/D3D11 etc.) it should >>> be much easier to move forward to the next one (ES 3.1). >>> >>> On Sun, Oct 19, 2014 at 3:14 PM, John Davis >>> wrote: >>> >>>> Agree, what's happening is wonderful. But while the market is >>>> digesting, the committee should be leading. There is always a balance >>>> between being too pragmatic and too passionate. My perception is that >>>> we're erring on the side of being too pragmatic. Three years is a long >>>> time, why not shake things up a bit? >>>> >>>> On Sun, Oct 19, 2014 at 9:04 AM, Florian B?sch >>>> wrote: >>>> >>>>> I'd always like to see capabilities emerge faster. And WebGL 2.0 will >>>>> be a nice jump. The past 3 years I've made my living almost exclusively >>>>> implementing WebGL projects. There might not have happened terribly much in >>>>> terms of capabilities (although don't overlook the extensions that did get >>>>> approved and implemented, those help a lot). >>>>> >>>>> What I did observe trough the last 3 years was that the demand for >>>>> WebGL (from a freelancers perspective) is rising meteorically, in line with >>>>> its uses in non-demo applications. I don't think that a bit of stability in >>>>> the standard is a bad thing, it allows the market to consolidate and for >>>>> implementations to get better and more robust. After all, native support >>>>> for HW accelerated rendering is still buggy and unreliable, and WebGL has >>>>> to deal with that too. >>>>> >>>>> On Sun, Oct 19, 2014 at 2:57 PM, John Davis >>>>> wrote: >>>>> >>>>>> Over three years ... feels like we're running in place. Closing the >>>>>> gap between what the hardware can do, and what can be done in the browser, >>>>>> we haven't come very far. IE11 and IOS8 are fantastic news, luckily they >>>>>> decided to jump on board. >>>>>> >>>>>> >>>>>> On Sun, Oct 19, 2014 at 8:46 AM, Florian B?sch >>>>>> wrote: >>>>>> >>>>>>> I'm happy with Kens leadership. Things could always move quicker, >>>>>>> but ultimately WebGL will only move as fast as the implementations will. >>>>>>> >>>>>>> On Sun, Oct 19, 2014 at 12:47 PM, John Davis < >>>>>>> jdavis...@> wrote: >>>>>>>> >>>>>>>> Nothing personal. As chairman of the webgl working group, for over >>>>>>>> three years, what has been achieved thus far? >>>>>>>> >>>>>>> >>>>>>> - 15 ratified extensions >>>>>>> - 7 community approved extensions >>>>>>> - 5 draft extensions >>>>>>> - 4 proposed extensions >>>>>>> - Comprehensive conformance test coverage >>>>>>> - Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 >>>>>>> mobile browsers (native android, Chrome Mobile and Safari) >>>>>>> - Advancement of WebGL overall from 60% to 73%, 62% -> 77% on >>>>>>> desktops, 2.4% -> 48% on mobiles. >>>>>>> - 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), 1 >>>>>>> revision of of the WebGL 2.0 standard. >>>>>>> - Implementations getting more robust >>>>>>> - Microsoft has joined the WG >>>>>>> >>>>>>> There are things that have happened in the last 3 years, a lot of >>>>>>> things. >>>>>>> >>>>>>> My perception is the standard progressed much faster under Vlad. If >>>>>>>> he's willing, why don't we put Vlad back in the driver's seat? >>>>>>>> >>>>>>> >>>>>>> Have you discussed this proposal with Ken and Vlad privately? >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 07:59:05 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 16:59:05 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Google is dedicating resources to work on getting WebGL 2.0 out the door in Chrome. The same goes for Mozilla. I'm guessing that neither of them will dedicate resources to work on WebGL 2.1 before WebGL 2.0 is out and reasonably stable. Microsoft is still ironing out their WebGL 1.0 implementation, and I'm guessing they're not dedicating resources to WebGL 2.0 (let alone WebGL 2.1) implementations for a while yet. Apple has just got their implementation of WebGL 1.0 out the door with iOS 8, and it's usually a year before the next big iOS update, and I'm guessing they're now dedicating some resources to WebGL 2.0, and it'll be at least a year before they'll start looking at WebGL 2.1. This contains a lot of guesses, but what stands out is that at the current time, nobody needs a WebGL 2.1 specification urgently, and that even if you had one, it wouldn't speed things up in any way. It seems clear to me that during the course of next year, a WebGL 2.1 specification should be produced though. On Sun, Oct 19, 2014 at 4:50 PM, John Davis wrote: > Not sure I understand, Imagination Technologies ES 3.1 gpu's are coming > out the floodgates as we speak. > > On Sun, Oct 19, 2014 at 10:02 AM, Florian B?sch wrote: > >> I'm fairly confident that no vendor, at this time, will require the WebGL >> 2.1 standard because there's enough work to get WebGL 1.0 and WebGL 2.0 out >> the door. I'll also trust that vendors will give advance warning if they >> feel they're running out of work and are lacking a standard to do next. >> >> On Sun, Oct 19, 2014 at 3:42 PM, John Davis >> wrote: >> >>> +webgl >>> >>> ---------- Forwarded message ---------- >>> From: John Davis >>> Date: Sun, Oct 19, 2014 at 9:39 AM >>> Subject: Re: [Public WebGL] WebGL working group - leadership >>> To: Florian B?sch >>> >>> >>> Exactly, couldn't have said it better myself. MANGLE is a monstrous >>> undertaking. However, it should not be allowed to slow down webgl for ES >>> 3.1. For ES 3.1, webgl on IOS and Android, the implementation should be >>> straightforward. The priority should be on these devices, the desktop can >>> then catch up later. >>> >>> To me, WebGL is highly disruptive, and has the potential to take >>> humankind to a whole new level. Allowing information to be >>> created/assimilated in 3D as opposed to 2D, the implications for learning >>> are MASSIVE. Throw in Occulus and things get really interesting. >>> >>> By being too 'pragmatic' we are holding back the realization of an >>> amazing future. >>> >>> >>> On Sun, Oct 19, 2014 at 9:26 AM, Florian B?sch wrote: >>> >>>> Well the major roadblock to shaking things up is WebGL 2.0. And it's >>>> true that this is taking an abysmally long time. But that's not a problem >>>> of the standard really, it's the implementations that're difficult. Once an >>>> implementation has achieved the move (to mangle, ES3/D3D11 etc.) it should >>>> be much easier to move forward to the next one (ES 3.1). >>>> >>>> On Sun, Oct 19, 2014 at 3:14 PM, John Davis >>>> wrote: >>>> >>>>> Agree, what's happening is wonderful. But while the market is >>>>> digesting, the committee should be leading. There is always a balance >>>>> between being too pragmatic and too passionate. My perception is that >>>>> we're erring on the side of being too pragmatic. Three years is a long >>>>> time, why not shake things up a bit? >>>>> >>>>> On Sun, Oct 19, 2014 at 9:04 AM, Florian B?sch >>>>> wrote: >>>>> >>>>>> I'd always like to see capabilities emerge faster. And WebGL 2.0 will >>>>>> be a nice jump. The past 3 years I've made my living almost exclusively >>>>>> implementing WebGL projects. There might not have happened terribly much in >>>>>> terms of capabilities (although don't overlook the extensions that did get >>>>>> approved and implemented, those help a lot). >>>>>> >>>>>> What I did observe trough the last 3 years was that the demand for >>>>>> WebGL (from a freelancers perspective) is rising meteorically, in line with >>>>>> its uses in non-demo applications. I don't think that a bit of stability in >>>>>> the standard is a bad thing, it allows the market to consolidate and for >>>>>> implementations to get better and more robust. After all, native support >>>>>> for HW accelerated rendering is still buggy and unreliable, and WebGL has >>>>>> to deal with that too. >>>>>> >>>>>> On Sun, Oct 19, 2014 at 2:57 PM, John Davis >>>>> > wrote: >>>>>> >>>>>>> Over three years ... feels like we're running in place. Closing the >>>>>>> gap between what the hardware can do, and what can be done in the browser, >>>>>>> we haven't come very far. IE11 and IOS8 are fantastic news, luckily they >>>>>>> decided to jump on board. >>>>>>> >>>>>>> >>>>>>> On Sun, Oct 19, 2014 at 8:46 AM, Florian B?sch >>>>>>> wrote: >>>>>>> >>>>>>>> I'm happy with Kens leadership. Things could always move quicker, >>>>>>>> but ultimately WebGL will only move as fast as the implementations will. >>>>>>>> >>>>>>>> On Sun, Oct 19, 2014 at 12:47 PM, John Davis < >>>>>>>> jdavis...@> wrote: >>>>>>>>> >>>>>>>>> Nothing personal. As chairman of the webgl working group, for >>>>>>>>> over three years, what has been achieved thus far? >>>>>>>>> >>>>>>>> >>>>>>>> - 15 ratified extensions >>>>>>>> - 7 community approved extensions >>>>>>>> - 5 draft extensions >>>>>>>> - 4 proposed extensions >>>>>>>> - Comprehensive conformance test coverage >>>>>>>> - Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 >>>>>>>> mobile browsers (native android, Chrome Mobile and Safari) >>>>>>>> - Advancement of WebGL overall from 60% to 73%, 62% -> 77% on >>>>>>>> desktops, 2.4% -> 48% on mobiles. >>>>>>>> - 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), >>>>>>>> 1 revision of of the WebGL 2.0 standard. >>>>>>>> - Implementations getting more robust >>>>>>>> - Microsoft has joined the WG >>>>>>>> >>>>>>>> There are things that have happened in the last 3 years, a lot of >>>>>>>> things. >>>>>>>> >>>>>>>> My perception is the standard progressed much faster under Vlad. >>>>>>>>> If he's willing, why don't we put Vlad back in the driver's seat? >>>>>>>>> >>>>>>>> >>>>>>>> Have you discussed this proposal with Ken and Vlad privately? >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 08:14:21 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 11:14:21 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: $5 says MANGLE is devouring resources and turning into a rather large hairball. Simply shooting for ES 3.1 hardware at this point would be 10x easier than MANGLE, and create coverage for all mobile devices, the primary use case. Shoot for where the target will be, not where it currently stands. I just read the book "How Google Works", this falls in the category of "cut your losses". On Sun, Oct 19, 2014 at 10:59 AM, Florian B?sch wrote: > Google is dedicating resources to work on getting WebGL 2.0 out the door > in Chrome. The same goes for Mozilla. I'm guessing that neither of them > will dedicate resources to work on WebGL 2.1 before WebGL 2.0 is out and > reasonably stable. Microsoft is still ironing out their WebGL 1.0 > implementation, and I'm guessing they're not dedicating resources to WebGL > 2.0 (let alone WebGL 2.1) implementations for a while yet. Apple has just > got their implementation of WebGL 1.0 out the door with iOS 8, and it's > usually a year before the next big iOS update, and I'm guessing they're now > dedicating some resources to WebGL 2.0, and it'll be at least a year before > they'll start looking at WebGL 2.1. > > This contains a lot of guesses, but what stands out is that at the current > time, nobody needs a WebGL 2.1 specification urgently, and that even if you > had one, it wouldn't speed things up in any way. It seems clear to me that > during the course of next year, a WebGL 2.1 specification should be > produced though. > > On Sun, Oct 19, 2014 at 4:50 PM, John Davis > wrote: > >> Not sure I understand, Imagination Technologies ES 3.1 gpu's are coming >> out the floodgates as we speak. >> >> On Sun, Oct 19, 2014 at 10:02 AM, Florian B?sch wrote: >> >>> I'm fairly confident that no vendor, at this time, will require the >>> WebGL 2.1 standard because there's enough work to get WebGL 1.0 and WebGL >>> 2.0 out the door. I'll also trust that vendors will give advance warning if >>> they feel they're running out of work and are lacking a standard to do next. >>> >>> On Sun, Oct 19, 2014 at 3:42 PM, John Davis >>> wrote: >>> >>>> +webgl >>>> >>>> ---------- Forwarded message ---------- >>>> From: John Davis >>>> Date: Sun, Oct 19, 2014 at 9:39 AM >>>> Subject: Re: [Public WebGL] WebGL working group - leadership >>>> To: Florian B?sch >>>> >>>> >>>> Exactly, couldn't have said it better myself. MANGLE is a monstrous >>>> undertaking. However, it should not be allowed to slow down webgl for ES >>>> 3.1. For ES 3.1, webgl on IOS and Android, the implementation should be >>>> straightforward. The priority should be on these devices, the desktop can >>>> then catch up later. >>>> >>>> To me, WebGL is highly disruptive, and has the potential to take >>>> humankind to a whole new level. Allowing information to be >>>> created/assimilated in 3D as opposed to 2D, the implications for learning >>>> are MASSIVE. Throw in Occulus and things get really interesting. >>>> >>>> By being too 'pragmatic' we are holding back the realization of an >>>> amazing future. >>>> >>>> >>>> On Sun, Oct 19, 2014 at 9:26 AM, Florian B?sch >>>> wrote: >>>> >>>>> Well the major roadblock to shaking things up is WebGL 2.0. And it's >>>>> true that this is taking an abysmally long time. But that's not a problem >>>>> of the standard really, it's the implementations that're difficult. Once an >>>>> implementation has achieved the move (to mangle, ES3/D3D11 etc.) it should >>>>> be much easier to move forward to the next one (ES 3.1). >>>>> >>>>> On Sun, Oct 19, 2014 at 3:14 PM, John Davis >>>>> wrote: >>>>> >>>>>> Agree, what's happening is wonderful. But while the market is >>>>>> digesting, the committee should be leading. There is always a balance >>>>>> between being too pragmatic and too passionate. My perception is that >>>>>> we're erring on the side of being too pragmatic. Three years is a long >>>>>> time, why not shake things up a bit? >>>>>> >>>>>> On Sun, Oct 19, 2014 at 9:04 AM, Florian B?sch >>>>>> wrote: >>>>>> >>>>>>> I'd always like to see capabilities emerge faster. And WebGL 2.0 >>>>>>> will be a nice jump. The past 3 years I've made my living almost >>>>>>> exclusively implementing WebGL projects. There might not have happened >>>>>>> terribly much in terms of capabilities (although don't overlook the >>>>>>> extensions that did get approved and implemented, those help a lot). >>>>>>> >>>>>>> What I did observe trough the last 3 years was that the demand for >>>>>>> WebGL (from a freelancers perspective) is rising meteorically, in line with >>>>>>> its uses in non-demo applications. I don't think that a bit of stability in >>>>>>> the standard is a bad thing, it allows the market to consolidate and for >>>>>>> implementations to get better and more robust. After all, native support >>>>>>> for HW accelerated rendering is still buggy and unreliable, and WebGL has >>>>>>> to deal with that too. >>>>>>> >>>>>>> On Sun, Oct 19, 2014 at 2:57 PM, John Davis < >>>>>>> jdavis...@> wrote: >>>>>>> >>>>>>>> Over three years ... feels like we're running in place. Closing >>>>>>>> the gap between what the hardware can do, and what can be done in the >>>>>>>> browser, we haven't come very far. IE11 and IOS8 are fantastic news, >>>>>>>> luckily they decided to jump on board. >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Oct 19, 2014 at 8:46 AM, Florian B?sch >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I'm happy with Kens leadership. Things could always move quicker, >>>>>>>>> but ultimately WebGL will only move as fast as the implementations will. >>>>>>>>> >>>>>>>>> On Sun, Oct 19, 2014 at 12:47 PM, John Davis < >>>>>>>>> jdavis...@> wrote: >>>>>>>>>> >>>>>>>>>> Nothing personal. As chairman of the webgl working group, for >>>>>>>>>> over three years, what has been achieved thus far? >>>>>>>>>> >>>>>>>>> >>>>>>>>> - 15 ratified extensions >>>>>>>>> - 7 community approved extensions >>>>>>>>> - 5 draft extensions >>>>>>>>> - 4 proposed extensions >>>>>>>>> - Comprehensive conformance test coverage >>>>>>>>> - Uptake of WebGL by 2 desktop browsers (IE and Opera) and 3 >>>>>>>>> mobile browsers (native android, Chrome Mobile and Safari) >>>>>>>>> - Advancement of WebGL overall from 60% to 73%, 62% -> 77% on >>>>>>>>> desktops, 2.4% -> 48% on mobiles. >>>>>>>>> - 3 revisions of the WebGL 1.0 standard (1.0.0, 1.0.1, 1.0.2), >>>>>>>>> 1 revision of of the WebGL 2.0 standard. >>>>>>>>> - Implementations getting more robust >>>>>>>>> - Microsoft has joined the WG >>>>>>>>> >>>>>>>>> There are things that have happened in the last 3 years, a lot of >>>>>>>>> things. >>>>>>>>> >>>>>>>>> My perception is the standard progressed much faster under Vlad. >>>>>>>>>> If he's willing, why don't we put Vlad back in the driver's seat? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Have you discussed this proposal with Ken and Vlad privately? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 08:25:45 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 17:25:45 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: I don't think that you can change how a WebGL vendor goes about the business of implementing WebGL. The solutions they'll arrive at are a product of resource constraints, organizational structure and planning. But besides the merits or drawbacks of a particular development approach chosen, jumping a version introduces its own hazard. What if, everybody agreed that WebGL 2.0 was too late, and you'd jump a version? It puts more work before the next update, and what if, by then, OpenGL ES 4.0 is the new hotness? Do you jump a version again? Do you want WebGL to spend forever in development hell and never release another version, or do you want some next version, even if its late and somewhat behind times when it comes out? On Sun, Oct 19, 2014 at 5:14 PM, John Davis wrote: > $5 says MANGLE is devouring resources and turning into a rather large > hairball. Simply shooting for ES 3.1 hardware at this point would be 10x > easier than MANGLE, and create coverage for all mobile devices, the primary > use case. Shoot for where the target will be, not where it currently > stands. > > I just read the book "How Google Works", this falls in the category of > "cut your losses". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 08:33:13 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 11:33:13 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Beginning with a clean slate is always easier. ES 3.1 is so different, it affords this opportunity. There is no backwards compatibility chain for existing developers. Everyone is starting again with a new API. MANGLE is the hell you're speaking of. On Sun, Oct 19, 2014 at 11:25 AM, Florian B?sch wrote: > I don't think that you can change how a WebGL vendor goes about the > business of implementing WebGL. The solutions they'll arrive at are a > product of resource constraints, organizational structure and planning. > > But besides the merits or drawbacks of a particular development approach > chosen, jumping a version introduces its own hazard. What if, everybody > agreed that WebGL 2.0 was too late, and you'd jump a version? It puts more > work before the next update, and what if, by then, OpenGL ES 4.0 is the new > hotness? Do you jump a version again? Do you want WebGL to spend forever in > development hell and never release another version, or do you want some > next version, even if its late and somewhat behind times when it comes out? > > > On Sun, Oct 19, 2014 at 5:14 PM, John Davis > wrote: > >> $5 says MANGLE is devouring resources and turning into a rather large >> hairball. Simply shooting for ES 3.1 hardware at this point would be 10x >> easier than MANGLE, and create coverage for all mobile devices, the primary >> use case. Shoot for where the target will be, not where it currently >> stands. >> >> I just read the book "How Google Works", this falls in the category of >> "cut your losses". >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 08:41:13 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 17:41:13 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: On Sun, Oct 19, 2014 at 5:33 PM, John Davis wrote: > Beginning with a clean slate is always easier. ES 3.1 is so different, it > affords this opportunity. There is no backwards compatibility chain for > existing developers. Everyone is starting again with a new API. > I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year (around 8 months) and it'll support a lot of desktop and mobile hardware. WebGL 2.1 would probably not arrive next year and its support for desktop and mobile hardware would be substantially lower than WebGL 2.0. MANGLE is the hell you're speaking of. > A Web technology that doesn't work for most people is not very attractive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 08:49:32 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 11:49:32 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: I would suggest we weigh the number of smart phones and tablets on the planet against the number of PC's. Think big picture, India, China, U.S., ... On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch wrote: > On Sun, Oct 19, 2014 at 5:33 PM, John Davis > wrote: > >> Beginning with a clean slate is always easier. ES 3.1 is so different, >> it affords this opportunity. There is no backwards compatibility chain for >> existing developers. Everyone is starting again with a new API. >> > I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year > (around 8 months) and it'll support a lot of desktop and mobile hardware. > WebGL 2.1 would probably not arrive next year and its support for desktop > and mobile hardware would be substantially lower than WebGL 2.0. > > MANGLE is the hell you're speaking of. >> > A Web technology that doesn't work for most people is not very attractive. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 09:01:42 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 18:01:42 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: On http://webglstats.com/ with about 7-8 million visits across its contributing sites, I measure 90% desktops and 10% mobiles. For much of 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's flagging somewhat. http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the rest being uncategorizable other things). The change from last year is desktops -12% and mobiles +14%. Even assuming the trend'd continue linearly, you'd look at years before you could "lay desktops to rest" as an audience. However I'd also not be happy with a situation where a machine that I can stick in a GTX-980 that'll get about 1000x as much performance as any of the latest smarphones, is something that can't run WebGL well. I think that's counterproductive to WebGL. On Sun, Oct 19, 2014 at 5:49 PM, John Davis wrote: > I would suggest we weigh the number of smart phones and tablets on the > planet against the number of PC's. Think big picture, India, China, U.S., > ... > > On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch wrote: > >> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >> wrote: >> >>> Beginning with a clean slate is always easier. ES 3.1 is so different, >>> it affords this opportunity. There is no backwards compatibility chain for >>> existing developers. Everyone is starting again with a new API. >>> >> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >> (around 8 months) and it'll support a lot of desktop and mobile hardware. >> WebGL 2.1 would probably not arrive next year and its support for desktop >> and mobile hardware would be substantially lower than WebGL 2.0. >> >> MANGLE is the hell you're speaking of. >>> >> A Web technology that doesn't work for most people is not very attractive. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Sun Oct 19 12:03:27 2014 From: tpa...@ (Tony Parisi) Date: Sun, 19 Oct 2014 12:03:27 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: In my opinion, Ken is doing a fantastic job. One can measure the "progress" of a standard by its rate of adoption and its high degree of interoperability - both crucial for its success - just as much or more than the rate at which features are being introduced. WebGL is tops in both. This is in no small part because this group, led by Ken, has been stable and focused on conformance over adding features. What progress has been made in the last three years? WebGL is ubiquitous. That's enough for me. I can live without multiple render targets for another year... Tony On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: > On http://webglstats.com/ with about 7-8 million visits across its > contributing sites, I measure 90% desktops and 10% mobiles. For much of > 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's > flagging somewhat. > > http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the > rest being uncategorizable other things). The change from last year is > desktops -12% and mobiles +14%. Even assuming the trend'd continue > linearly, you'd look at years before you could "lay desktops to rest" as an > audience. > > However I'd also not be happy with a situation where a machine that I can > stick in a GTX-980 that'll get about 1000x as much performance as any of > the latest smarphones, is something that can't run WebGL well. I think > that's counterproductive to WebGL. > > On Sun, Oct 19, 2014 at 5:49 PM, John Davis > wrote: > >> I would suggest we weigh the number of smart phones and tablets on the >> planet against the number of PC's. Think big picture, India, China, U.S., >> ... >> >> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch wrote: >> >>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>> wrote: >>> >>>> Beginning with a clean slate is always easier. ES 3.1 is so different, >>>> it affords this opportunity. There is no backwards compatibility chain for >>>> existing developers. Everyone is starting again with a new API. >>>> >>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >>> (around 8 months) and it'll support a lot of desktop and mobile hardware. >>> WebGL 2.1 would probably not arrive next year and its support for desktop >>> and mobile hardware would be substantially lower than WebGL 2.0. >>> >>> MANGLE is the hell you're speaking of. >>>> >>> A Web technology that doesn't work for most people is not very >>> attractive. >>> >> >> > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my books! *Programming 3D Applications in HTML5 and WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 WebGL, Up and Running* http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Oct 19 12:15:27 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 19 Oct 2014 21:15:27 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: On Sun, Oct 19, 2014 at 9:03 PM, Tony Parisi wrote: > I can live without multiple render targets for another year... > WEBGL_draw_buffers is picking up some support (22.5% overall, 24% on desktops, 1% on mobiles). This is thanks to a high rate of support on OSX on Chrome and Firefox (88%), a good rate of support on Chrome OS (56%), a high rate of support on Linux by Chrome and Firefox (84%). Lagging behind on this extension is Windows (14%) where only Chrome implements it with a low rate of support (20%) and neither Firefox nor IE implements it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thu...@ Sun Oct 19 12:47:23 2014 From: thu...@ (Ben Adams) Date: Sun, 19 Oct 2014 20:47:23 +0100 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Also for the last 3 years, looking at adjunct WebGL progress bringing in more established areas: WebGL output from Unreal, Unity, Flash Professional (Adobe) There's even a WebGL based humble bundle: https://www.humblebundle.com/ Hat's off to Mozilla for a lot of work in these areas On 19 October 2014 20:03, Tony Parisi wrote: > In my opinion, Ken is doing a fantastic job. > > One can measure the "progress" of a standard by its rate of adoption and > its high degree of interoperability - both crucial for its success - just > as much or more than the rate at which features are being introduced. WebGL > is tops in both. This is in no small part because this group, led by Ken, > has been stable and focused on conformance over adding features. > > What progress has been made in the last three years? WebGL is ubiquitous. > That's enough for me. I can live without multiple render targets for > another year... > > Tony > > > > > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: > >> On http://webglstats.com/ with about 7-8 million visits across its >> contributing sites, I measure 90% desktops and 10% mobiles. For much of >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >> flagging somewhat. >> >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >> rest being uncategorizable other things). The change from last year is >> desktops -12% and mobiles +14%. Even assuming the trend'd continue >> linearly, you'd look at years before you could "lay desktops to rest" as an >> audience. >> >> However I'd also not be happy with a situation where a machine that I can >> stick in a GTX-980 that'll get about 1000x as much performance as any of >> the latest smarphones, is something that can't run WebGL well. I think >> that's counterproductive to WebGL. >> >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >> wrote: >> >>> I would suggest we weigh the number of smart phones and tablets on the >>> planet against the number of PC's. Think big picture, India, China, U.S., >>> ... >>> >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>> wrote: >>> >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>>> wrote: >>>> >>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>>>> different, it affords this opportunity. There is no backwards >>>>> compatibility chain for existing developers. Everyone is starting again >>>>> with a new API. >>>>> >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >>>> (around 8 months) and it'll support a lot of desktop and mobile hardware. >>>> WebGL 2.1 would probably not arrive next year and its support for desktop >>>> and mobile hardware would be substantially lower than WebGL 2.0. >>>> >>>> MANGLE is the hell you're speaking of. >>>>> >>>> A Web technology that doesn't work for most people is not very >>>> attractive. >>>> >>> >>> >> > > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my books! > > > *Programming 3D Applications in HTML5 and > WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 > WebGL, > Up and Running* > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 14:17:05 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 17:17:05 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Completely agree, we wouldn't be here if it weren't for Mozilla and Vlad. I wish they were still leading the standard. On Sun, Oct 19, 2014 at 3:47 PM, Ben Adams wrote: > Also for the last 3 years, looking at adjunct WebGL progress bringing in > more established areas: > > WebGL output from Unreal, Unity, Flash Professional (Adobe) > > There's even a WebGL based humble bundle: https://www.humblebundle.com/ > > Hat's off to Mozilla for a lot of work in these areas > > > On 19 October 2014 20:03, Tony Parisi wrote: > >> In my opinion, Ken is doing a fantastic job. >> >> One can measure the "progress" of a standard by its rate of adoption and >> its high degree of interoperability - both crucial for its success - just >> as much or more than the rate at which features are being introduced. WebGL >> is tops in both. This is in no small part because this group, led by Ken, >> has been stable and focused on conformance over adding features. >> >> What progress has been made in the last three years? WebGL is ubiquitous. >> That's enough for me. I can live without multiple render targets for >> another year... >> >> Tony >> >> >> >> >> On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: >> >>> On http://webglstats.com/ with about 7-8 million visits across its >>> contributing sites, I measure 90% desktops and 10% mobiles. For much of >>> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >>> flagging somewhat. >>> >>> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >>> rest being uncategorizable other things). The change from last year is >>> desktops -12% and mobiles +14%. Even assuming the trend'd continue >>> linearly, you'd look at years before you could "lay desktops to rest" as an >>> audience. >>> >>> However I'd also not be happy with a situation where a machine that I >>> can stick in a GTX-980 that'll get about 1000x as much performance as any >>> of the latest smarphones, is something that can't run WebGL well. I think >>> that's counterproductive to WebGL. >>> >>> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >>> wrote: >>> >>>> I would suggest we weigh the number of smart phones and tablets on the >>>> planet against the number of PC's. Think big picture, India, China, U.S., >>>> ... >>>> >>>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>>> wrote: >>>> >>>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>>>> wrote: >>>>> >>>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>>>>> different, it affords this opportunity. There is no backwards >>>>>> compatibility chain for existing developers. Everyone is starting again >>>>>> with a new API. >>>>>> >>>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >>>>> (around 8 months) and it'll support a lot of desktop and mobile hardware. >>>>> WebGL 2.1 would probably not arrive next year and its support for desktop >>>>> and mobile hardware would be substantially lower than WebGL 2.0. >>>>> >>>>> MANGLE is the hell you're speaking of. >>>>>> >>>>> A Web technology that doesn't work for most people is not very >>>>> attractive. >>>>> >>>> >>>> >>> >> >> >> -- >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> Read my books! >> >> >> *Programming 3D Applications in HTML5 and >> WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 >> WebGL, >> Up and Running* >> http://www.amazon.com/dp/144932357X >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sun Oct 19 14:23:53 2014 From: jda...@ (John Davis) Date: Sun, 19 Oct 2014 17:23:53 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Apologies, I can't help but think we can do better. On Sun, Oct 19, 2014 at 3:03 PM, Tony Parisi wrote: > In my opinion, Ken is doing a fantastic job. > > One can measure the "progress" of a standard by its rate of adoption and > its high degree of interoperability - both crucial for its success - just > as much or more than the rate at which features are being introduced. WebGL > is tops in both. This is in no small part because this group, led by Ken, > has been stable and focused on conformance over adding features. > > What progress has been made in the last three years? WebGL is ubiquitous. > That's enough for me. I can live without multiple render targets for > another year... > > Tony > > > > > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: > >> On http://webglstats.com/ with about 7-8 million visits across its >> contributing sites, I measure 90% desktops and 10% mobiles. For much of >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >> flagging somewhat. >> >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >> rest being uncategorizable other things). The change from last year is >> desktops -12% and mobiles +14%. Even assuming the trend'd continue >> linearly, you'd look at years before you could "lay desktops to rest" as an >> audience. >> >> However I'd also not be happy with a situation where a machine that I can >> stick in a GTX-980 that'll get about 1000x as much performance as any of >> the latest smarphones, is something that can't run WebGL well. I think >> that's counterproductive to WebGL. >> >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >> wrote: >> >>> I would suggest we weigh the number of smart phones and tablets on the >>> planet against the number of PC's. Think big picture, India, China, U.S., >>> ... >>> >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>> wrote: >>> >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>>> wrote: >>>> >>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>>>> different, it affords this opportunity. There is no backwards >>>>> compatibility chain for existing developers. Everyone is starting again >>>>> with a new API. >>>>> >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >>>> (around 8 months) and it'll support a lot of desktop and mobile hardware. >>>> WebGL 2.1 would probably not arrive next year and its support for desktop >>>> and mobile hardware would be substantially lower than WebGL 2.0. >>>> >>>> MANGLE is the hell you're speaking of. >>>>> >>>> A Web technology that doesn't work for most people is not very >>>> attractive. >>>> >>> >>> >> > > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my books! > > > *Programming 3D Applications in HTML5 and > WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 > WebGL, > Up and Running* > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Sun Oct 19 19:17:57 2014 From: jgi...@ (Jeff Gilbert) Date: Sun, 19 Oct 2014 19:17:57 -0700 (PDT) Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: <1861424132.27036080.1413771477226.JavaMail.zimbra@mozilla.com> For what it's worth, I disagree with your evaluations. I think we're largely in a good place right now, and on a good trajectory. I do not believe the WG has been a bottleneck for our WebGL implementation, at least. There's a lot of work that goes on behind the scenes which goes unappreciated. When done well, a decent amount of this work is nearly invisible. It's hard to put numbers on improved compatibility and conformance. It's still reasonable input if you believe we should have a stronger focus on features, but we're certainly not in the pure feature race. -Jeff ----- Original Message ----- From: "John Davis" To: "Tony Parisi" Cc: "Florian B?sch" , "public webgl" Sent: Sunday, October 19, 2014 2:23:53 PM Subject: Re: [Public WebGL] WebGL working group - leadership Apologies, I can't help but think we can do better. On Sun, Oct 19, 2014 at 3:03 PM, Tony Parisi wrote: > In my opinion, Ken is doing a fantastic job. > > One can measure the "progress" of a standard by its rate of adoption and > its high degree of interoperability - both crucial for its success - just > as much or more than the rate at which features are being introduced. WebGL > is tops in both. This is in no small part because this group, led by Ken, > has been stable and focused on conformance over adding features. > > What progress has been made in the last three years? WebGL is ubiquitous. > That's enough for me. I can live without multiple render targets for > another year... > > Tony > > > > > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: > >> On http://webglstats.com/ with about 7-8 million visits across its >> contributing sites, I measure 90% desktops and 10% mobiles. For much of >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >> flagging somewhat. >> >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >> rest being uncategorizable other things). The change from last year is >> desktops -12% and mobiles +14%. Even assuming the trend'd continue >> linearly, you'd look at years before you could "lay desktops to rest" as an >> audience. >> >> However I'd also not be happy with a situation where a machine that I can >> stick in a GTX-980 that'll get about 1000x as much performance as any of >> the latest smarphones, is something that can't run WebGL well. I think >> that's counterproductive to WebGL. >> >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >> wrote: >> >>> I would suggest we weigh the number of smart phones and tablets on the >>> planet against the number of PC's. Think big picture, India, China, U.S., >>> ... >>> >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>> wrote: >>> >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>>> wrote: >>>> >>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>>>> different, it affords this opportunity. There is no backwards >>>>> compatibility chain for existing developers. Everyone is starting again >>>>> with a new API. >>>>> >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >>>> (around 8 months) and it'll support a lot of desktop and mobile hardware. >>>> WebGL 2.1 would probably not arrive next year and its support for desktop >>>> and mobile hardware would be substantially lower than WebGL 2.0. >>>> >>>> MANGLE is the hell you're speaking of. >>>>> >>>> A Web technology that doesn't work for most people is not very >>>> attractive. >>>> >>> >>> >> > > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my books! > > > *Programming 3D Applications in HTML5 and > WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 > WebGL, > Up and Running* > http://www.amazon.com/dp/144932357X > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Sun Oct 19 19:33:56 2014 From: jgi...@ (Jeff Gilbert) Date: Sun, 19 Oct 2014 19:33:56 -0700 (PDT) Subject: [Public WebGL] compute shaders In-Reply-To: References: Message-ID: <928870673.27037176.1413772436906.JavaMail.zimbra@mozilla.com> We haven't committed to a WebGL version name for ES3.1 tracking, but if you use WebGL 2.1, people will know what you mean. -Jeff ----- Original Message ----- From: "Florian B?sch" To: "John Davis" Cc: "public webgl" Sent: Sunday, October 19, 2014 3:45:37 AM Subject: Re: [Public WebGL] compute shaders WebGL 2.0 will be an implementation of OpenGL ES 3.0. OpenGL ES 3.0 does not contain compute shaders. OpenGL ES 3.1 contains compute shaders. WebGL 2.1 (afaik) is supposed to be OpenGL ES 3.1. There is no specification for that version of WebGL yet. On Sun, Oct 19, 2014 at 12:27 PM, John Davis wrote: > ie Will it be webgl 2.1? Is there a spec yet? > > > On Sun, Oct 19, 2014 at 5:59 AM, John Davis > wrote: > >> Will webgl2 include compute shaders? >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Sun Oct 19 21:00:32 2014 From: baj...@ (Brandon Jones) Date: Mon, 20 Oct 2014 04:00:32 +0000 Subject: [Public WebGL] WebGL working group - leadership References: <1861424132.27036080.1413771477226.JavaMail.zimbra@mozilla.com> Message-ID: Given that I work with Ken day-to-day I'm sure my opinion will be taken with a large grain of salt. I've seen nothing over the past two years that I've been working directly on WebGL to suggest that Ken's leadership has been the bottleneck to WebGL 2.0 progress, or indeed that having him as the chair has been anything but beneficial. The draft of the WebGL 2.0 spec has been available for over a year now, and there's been nothing to prevent the various vendors from beginning implementations, even if they know the spec isn't final. Firefox is proof of this, since they've been quietly building out experimental WebGL 2.0 support for a while. The fact that other vendors haven't followed suite likely has more to do with internal priorities and resource availability than the spec state or any WG holdups. Safari and IE have been focusing on getting it's WebGL implementation release-worthy (great job to the teams involved!), and Chrome has been focusing intensely on stability and code cleanup (the aforementioned MANGLE effort, which is only a hairball if you're not familiar with Chrome's current GPU internals.) It's certainly not "sexy" work: everybody loves new features but it's hard to get excited about hearing that the browser crashes 30% less on a GPU that you don't own. The focus on implementation quality by all parties is crucial for ensuring that the API is viewed as more than a plaything for power-users, though. --Brandon On Sun Oct 19 2014 at 7:18:39 PM Jeff Gilbert wrote: > > For what it's worth, I disagree with your evaluations. I think we're > largely in a good place right now, and on a good trajectory. > > I do not believe the WG has been a bottleneck for our WebGL > implementation, at least. > There's a lot of work that goes on behind the scenes which goes > unappreciated. When done well, a decent amount of this work is nearly > invisible. > It's hard to put numbers on improved compatibility and conformance. > > It's still reasonable input if you believe we should have a stronger focus > on features, but we're certainly not in the pure feature race. > > -Jeff > > ----- Original Message ----- > From: "John Davis" > To: "Tony Parisi" > Cc: "Florian B?sch" , "public webgl" < > public_webgl...@> > Sent: Sunday, October 19, 2014 2:23:53 PM > Subject: Re: [Public WebGL] WebGL working group - leadership > > Apologies, I can't help but think we can do better. > > On Sun, Oct 19, 2014 at 3:03 PM, Tony Parisi wrote: > > > In my opinion, Ken is doing a fantastic job. > > > > One can measure the "progress" of a standard by its rate of adoption and > > its high degree of interoperability - both crucial for its success - just > > as much or more than the rate at which features are being introduced. > WebGL > > is tops in both. This is in no small part because this group, led by Ken, > > has been stable and focused on conformance over adding features. > > > > What progress has been made in the last three years? WebGL is ubiquitous. > > That's enough for me. I can live without multiple render targets for > > another year... > > > > Tony > > > > > > > > > > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: > > > >> On http://webglstats.com/ with about 7-8 million visits across its > >> contributing sites, I measure 90% desktops and 10% mobiles. For much of > >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's > >> flagging somewhat. > >> > >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the > >> rest being uncategorizable other things). The change from last year is > >> desktops -12% and mobiles +14%. Even assuming the trend'd continue > >> linearly, you'd look at years before you could "lay desktops to rest" > as an > >> audience. > >> > >> However I'd also not be happy with a situation where a machine that I > can > >> stick in a GTX-980 that'll get about 1000x as much performance as any of > >> the latest smarphones, is something that can't run WebGL well. I think > >> that's counterproductive to WebGL. > >> > >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis > >> wrote: > >> > >>> I would suggest we weigh the number of smart phones and tablets on the > >>> planet against the number of PC's. Think big picture, India, China, > U.S., > >>> ... > >>> > >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch > >>> wrote: > >>> > >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis > > >>>> wrote: > >>>> > >>>>> Beginning with a clean slate is always easier. ES 3.1 is so > >>>>> different, it affords this opportunity. There is no backwards > >>>>> compatibility chain for existing developers. Everyone is starting > again > >>>>> with a new API. > >>>>> > >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year > >>>> (around 8 months) and it'll support a lot of desktop and mobile > hardware. > >>>> WebGL 2.1 would probably not arrive next year and its support for > desktop > >>>> and mobile hardware would be substantially lower than WebGL 2.0. > >>>> > >>>> MANGLE is the hell you're speaking of. > >>>>> > >>>> A Web technology that doesn't work for most people is not very > >>>> attractive. > >>>> > >>> > >>> > >> > > > > > > -- > > Tony Parisi tparisi...@ > > CTO at Large 415.902.8002 > > Skype auradeluxe > > Follow me on Twitter! http://twitter.com/auradeluxe > > Read my blog at http://www.tonyparisi.com/ > > Learn WebGL http://learningwebgl.com/ > > > > Read my books! > > > > > > *Programming 3D Applications in HTML5 and > > WebGLhttp://www.amazon.com/Programming-Applications- > HTML5-WebGL-Visualization/dp/1449362966 > > HTML5-WebGL-Visualization/dp/1449362966>WebGL, > > Up and Running* > > http://www.amazon.com/dp/144932357X > > > > > > ----------------------------------------------------------- > 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...@ Mon Oct 20 06:49:10 2014 From: ash...@ (Ashley Gullen) Date: Mon, 20 Oct 2014 14:49:10 +0100 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: <1861424132.27036080.1413771477226.JavaMail.zimbra@mozilla.com> Message-ID: Just want to add my voice in support of the status quo: I think WebGL is on a great trajectory and progress has been outstanding given the gigantic size of the market, the range of hardware and driver implementations (especially difficulties with driver quality), and even overcoming the more political issues (e.g. getting Microsoft on board despite them having their own Direct3D API). The level of support for WebGL out there on the web is improving daily. Good engineering takes time, and good engineering is what I see being done. Obviously it'd be great if we could have WebGL 2.1 overnight, but fast, robust and interoperable implementations with the crazy platform diversity out there and the special considerations of the web platform make it something worth engineering carefully, and that takes time. We'll get there eventually though! On 20 October 2014 05:00, Brandon Jones wrote: > Given that I work with Ken day-to-day I'm sure my opinion will be taken > with a large grain of salt. I've seen nothing over the past two years that > I've been working directly on WebGL to suggest that Ken's leadership has > been the bottleneck to WebGL 2.0 progress, or indeed that having him as the > chair has been anything but beneficial. > > The draft of the WebGL 2.0 spec has been available for over a year now, > and there's been nothing to prevent the various vendors from beginning > implementations, even if they know the spec isn't final. Firefox is proof > of this, since they've been quietly building out experimental WebGL 2.0 > support for a while. The fact that other vendors haven't followed suite > likely has more to do with internal priorities and resource availability > than the spec state or any WG holdups. Safari and IE have been focusing on > getting it's WebGL implementation release-worthy (great job to the teams > involved!), and Chrome has been focusing intensely on stability and code > cleanup (the aforementioned MANGLE effort, which is only a hairball if > you're not familiar with Chrome's current GPU internals.) > > It's certainly not "sexy" work: everybody loves new features but it's hard > to get excited about hearing that the browser crashes 30% less on a GPU > that you don't own. The focus on implementation quality by all parties is > crucial for ensuring that the API is viewed as more than a plaything for > power-users, though. > > --Brandon > > On Sun Oct 19 2014 at 7:18:39 PM Jeff Gilbert > wrote: > >> >> For what it's worth, I disagree with your evaluations. I think we're >> largely in a good place right now, and on a good trajectory. >> >> I do not believe the WG has been a bottleneck for our WebGL >> implementation, at least. >> There's a lot of work that goes on behind the scenes which goes >> unappreciated. When done well, a decent amount of this work is nearly >> invisible. >> It's hard to put numbers on improved compatibility and conformance. >> >> It's still reasonable input if you believe we should have a stronger >> focus on features, but we're certainly not in the pure feature race. >> >> -Jeff >> >> ----- Original Message ----- >> From: "John Davis" >> To: "Tony Parisi" >> Cc: "Florian B?sch" , "public webgl" < >> public_webgl...@> >> Sent: Sunday, October 19, 2014 2:23:53 PM >> Subject: Re: [Public WebGL] WebGL working group - leadership >> >> Apologies, I can't help but think we can do better. >> >> On Sun, Oct 19, 2014 at 3:03 PM, Tony Parisi wrote: >> >> > In my opinion, Ken is doing a fantastic job. >> > >> > One can measure the "progress" of a standard by its rate of adoption and >> > its high degree of interoperability - both crucial for its success - >> just >> > as much or more than the rate at which features are being introduced. >> WebGL >> > is tops in both. This is in no small part because this group, led by >> Ken, >> > has been stable and focused on conformance over adding features. >> > >> > What progress has been made in the last three years? WebGL is >> ubiquitous. >> > That's enough for me. I can live without multiple render targets for >> > another year... >> > >> > Tony >> > >> > >> > >> > >> > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch >> wrote: >> > >> >> On http://webglstats.com/ with about 7-8 million visits across its >> >> contributing sites, I measure 90% desktops and 10% mobiles. For much of >> >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >> >> flagging somewhat. >> >> >> >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >> >> rest being uncategorizable other things). The change from last year is >> >> desktops -12% and mobiles +14%. Even assuming the trend'd continue >> >> linearly, you'd look at years before you could "lay desktops to rest" >> as an >> >> audience. >> >> >> >> However I'd also not be happy with a situation where a machine that I >> can >> >> stick in a GTX-980 that'll get about 1000x as much performance as any >> of >> >> the latest smarphones, is something that can't run WebGL well. I think >> >> that's counterproductive to WebGL. >> >> >> >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >> >> wrote: >> >> >> >>> I would suggest we weigh the number of smart phones and tablets on the >> >>> planet against the number of PC's. Think big picture, India, China, >> U.S., >> >>> ... >> >>> >> >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >> >>> wrote: >> >>> >> >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis < >> jdavis...@> >> >>>> wrote: >> >>>> >> >>>>> Beginning with a clean slate is always easier. ES 3.1 is so >> >>>>> different, it affords this opportunity. There is no backwards >> >>>>> compatibility chain for existing developers. Everyone is starting >> again >> >>>>> with a new API. >> >>>>> >> >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next >> year >> >>>> (around 8 months) and it'll support a lot of desktop and mobile >> hardware. >> >>>> WebGL 2.1 would probably not arrive next year and its support for >> desktop >> >>>> and mobile hardware would be substantially lower than WebGL 2.0. >> >>>> >> >>>> MANGLE is the hell you're speaking of. >> >>>>> >> >>>> A Web technology that doesn't work for most people is not very >> >>>> attractive. >> >>>> >> >>> >> >>> >> >> >> > >> > >> > -- >> > Tony Parisi tparisi...@ >> > CTO at Large 415.902.8002 >> > Skype auradeluxe >> > Follow me on Twitter! http://twitter.com/auradeluxe >> > Read my blog at http://www.tonyparisi.com/ >> > Learn WebGL http://learningwebgl.com/ >> > >> > Read my books! >> > >> > >> > *Programming 3D Applications in HTML5 and >> > WebGLhttp://www.amazon.com/Programming-Applications- >> HTML5-WebGL-Visualization/dp/1449362966 >> > > HTML5-WebGL-Visualization/dp/1449362966>WebGL, >> > Up and Running* >> > http://www.amazon.com/dp/144932357X >> > >> > >> >> ----------------------------------------------------------- >> 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 spa...@ Mon Oct 20 08:16:38 2014 From: spa...@ (Spam Spam) Date: Mon, 20 Oct 2014 08:16:38 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: <1861424132.27036080.1413771477226.JavaMail.zimbra@mozilla.com> Message-ID: As a user of WebGL, the most important thing to me is consistency of implementations and the number of platforms available. For me, now is an amazing time where I can write code once and run it on Windows, OSX, Linux, iOS, Android and Microsoft surface. It's a great time to be into WebGL and I'm happy with the leadership. Rob On Oct 20, 2014 6:50 AM, "Ashley Gullen" wrote: > Just want to add my voice in support of the status quo: I think WebGL is > on a great trajectory and progress has been outstanding given the gigantic > size of the market, the range of hardware and driver implementations > (especially difficulties with driver quality), and even overcoming the more > political issues (e.g. getting Microsoft on board despite them having their > own Direct3D API). The level of support for WebGL out there on the web is > improving daily. > > Good engineering takes time, and good engineering is what I see being > done. Obviously it'd be great if we could have WebGL 2.1 overnight, but > fast, robust and interoperable implementations with the crazy platform > diversity out there and the special considerations of the web platform make > it something worth engineering carefully, and that takes time. We'll get > there eventually though! > > > On 20 October 2014 05:00, Brandon Jones wrote: > >> Given that I work with Ken day-to-day I'm sure my opinion will be taken >> with a large grain of salt. I've seen nothing over the past two years that >> I've been working directly on WebGL to suggest that Ken's leadership has >> been the bottleneck to WebGL 2.0 progress, or indeed that having him as the >> chair has been anything but beneficial. >> >> The draft of the WebGL 2.0 spec has been available for over a year now, >> and there's been nothing to prevent the various vendors from beginning >> implementations, even if they know the spec isn't final. Firefox is proof >> of this, since they've been quietly building out experimental WebGL 2.0 >> support for a while. The fact that other vendors haven't followed suite >> likely has more to do with internal priorities and resource availability >> than the spec state or any WG holdups. Safari and IE have been focusing on >> getting it's WebGL implementation release-worthy (great job to the teams >> involved!), and Chrome has been focusing intensely on stability and code >> cleanup (the aforementioned MANGLE effort, which is only a hairball if >> you're not familiar with Chrome's current GPU internals.) >> >> It's certainly not "sexy" work: everybody loves new features but it's >> hard to get excited about hearing that the browser crashes 30% less on a >> GPU that you don't own. The focus on implementation quality by all parties >> is crucial for ensuring that the API is viewed as more than a plaything for >> power-users, though. >> >> --Brandon >> >> On Sun Oct 19 2014 at 7:18:39 PM Jeff Gilbert >> wrote: >> >>> >>> For what it's worth, I disagree with your evaluations. I think we're >>> largely in a good place right now, and on a good trajectory. >>> >>> I do not believe the WG has been a bottleneck for our WebGL >>> implementation, at least. >>> There's a lot of work that goes on behind the scenes which goes >>> unappreciated. When done well, a decent amount of this work is nearly >>> invisible. >>> It's hard to put numbers on improved compatibility and conformance. >>> >>> It's still reasonable input if you believe we should have a stronger >>> focus on features, but we're certainly not in the pure feature race. >>> >>> -Jeff >>> >>> ----- Original Message ----- >>> From: "John Davis" >>> To: "Tony Parisi" >>> Cc: "Florian B?sch" , "public webgl" < >>> public_webgl...@> >>> Sent: Sunday, October 19, 2014 2:23:53 PM >>> Subject: Re: [Public WebGL] WebGL working group - leadership >>> >>> Apologies, I can't help but think we can do better. >>> >>> On Sun, Oct 19, 2014 at 3:03 PM, Tony Parisi wrote: >>> >>> > In my opinion, Ken is doing a fantastic job. >>> > >>> > One can measure the "progress" of a standard by its rate of adoption >>> and >>> > its high degree of interoperability - both crucial for its success - >>> just >>> > as much or more than the rate at which features are being introduced. >>> WebGL >>> > is tops in both. This is in no small part because this group, led by >>> Ken, >>> > has been stable and focused on conformance over adding features. >>> > >>> > What progress has been made in the last three years? WebGL is >>> ubiquitous. >>> > That's enough for me. I can live without multiple render targets for >>> > another year... >>> > >>> > Tony >>> > >>> > >>> > >>> > >>> > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch >>> wrote: >>> > >>> >> On http://webglstats.com/ with about 7-8 million visits across its >>> >> contributing sites, I measure 90% desktops and 10% mobiles. For much >>> of >>> >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >>> >> flagging somewhat. >>> >> >>> >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% >>> (the >>> >> rest being uncategorizable other things). The change from last year is >>> >> desktops -12% and mobiles +14%. Even assuming the trend'd continue >>> >> linearly, you'd look at years before you could "lay desktops to rest" >>> as an >>> >> audience. >>> >> >>> >> However I'd also not be happy with a situation where a machine that I >>> can >>> >> stick in a GTX-980 that'll get about 1000x as much performance as any >>> of >>> >> the latest smarphones, is something that can't run WebGL well. I think >>> >> that's counterproductive to WebGL. >>> >> >>> >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >> > >>> >> wrote: >>> >> >>> >>> I would suggest we weigh the number of smart phones and tablets on >>> the >>> >>> planet against the number of PC's. Think big picture, India, China, >>> U.S., >>> >>> ... >>> >>> >>> >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>> >>> wrote: >>> >>> >>> >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis < >>> jdavis...@> >>> >>>> wrote: >>> >>>> >>> >>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>> >>>>> different, it affords this opportunity. There is no backwards >>> >>>>> compatibility chain for existing developers. Everyone is starting >>> again >>> >>>>> with a new API. >>> >>>>> >>> >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next >>> year >>> >>>> (around 8 months) and it'll support a lot of desktop and mobile >>> hardware. >>> >>>> WebGL 2.1 would probably not arrive next year and its support for >>> desktop >>> >>>> and mobile hardware would be substantially lower than WebGL 2.0. >>> >>>> >>> >>>> MANGLE is the hell you're speaking of. >>> >>>>> >>> >>>> A Web technology that doesn't work for most people is not very >>> >>>> attractive. >>> >>>> >>> >>> >>> >>> >>> >> >>> > >>> > >>> > -- >>> > Tony Parisi tparisi...@ >>> > CTO at Large 415.902.8002 >>> > Skype auradeluxe >>> > Follow me on Twitter! http://twitter.com/auradeluxe >>> > Read my blog at http://www.tonyparisi.com/ >>> > Learn WebGL http://learningwebgl.com/ >>> > >>> > Read my books! >>> > >>> > >>> > *Programming 3D Applications in HTML5 and >>> > WebGLhttp://www.amazon.com/Programming-Applications- >>> HTML5-WebGL-Visualization/dp/1449362966 >>> > >> HTML5-WebGL-Visualization/dp/1449362966>WebGL, >>> > Up and Running* >>> > http://www.amazon.com/dp/144932357X >>> > >>> > >>> >>> ----------------------------------------------------------- >>> 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 Mit...@ Mon Oct 20 08:34:25 2014 From: Mit...@ (Mitch Williams) Date: Mon, 20 Oct 2014 08:34:25 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: <1861424132.27036080.1413771477226.JavaMail.zimbra@mozilla.com> Message-ID: <004001cfec7b$6c4e7f50$44eb7df0$@3d-Online.com> We never get an opportunity to properly acknowledge all the great people that put these specifications and technologies together, from VRML, to X3D, to WebGL, and the related tech such as X3Dom. So, many self-sacrificing people and organizations such as Khronos, SIGGRAPH and the Web3D Consortium. I am the benefactor of the work of so many here. Fitting this Saturday, the 18th St. Arts Complex in Santa Monica, California will be celebrating its 25th b-day. It?s where I got my start: Dave Blackburn, host of the VR SIG, introduced VRML, presented by Tony Parisi, Mark Pesce and others at Kit and Sherry Galloway?s ECafe. And yet, I feel like I?m just getting started. Mitch Williams 3d-Online http://www.3d-Online.com 310-406-1169 From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Ashley Gullen Sent: Monday, October 20, 2014 6:49 AM To: Brandon Jones Cc: Jeff Gilbert; John Davis; Tony Parisi; Florian B?sch; public webgl Subject: Re: [Public WebGL] WebGL working group - leadership Just want to add my voice in support of the status quo: I think WebGL is on a great trajectory and progress has been outstanding given the gigantic size of the market, the range of hardware and driver implementations (especially difficulties with driver quality), and even overcoming the more political issues (e.g. getting Microsoft on board despite them having their own Direct3D API). The level of support for WebGL out there on the web is improving daily. Good engineering takes time, and good engineering is what I see being done. Obviously it'd be great if we could have WebGL 2.1 overnight, but fast, robust and interoperable implementations with the crazy platform diversity out there and the special considerations of the web platform make it something worth engineering carefully, and that takes time. We'll get there eventually though! On 20 October 2014 05:00, Brandon Jones wrote: Given that I work with Ken day-to-day I'm sure my opinion will be taken with a large grain of salt. I've seen nothing over the past two years that I've been working directly on WebGL to suggest that Ken's leadership has been the bottleneck to WebGL 2.0 progress, or indeed that having him as the chair has been anything but beneficial. The draft of the WebGL 2.0 spec has been available for over a year now, and there's been nothing to prevent the various vendors from beginning implementations, even if they know the spec isn't final. Firefox is proof of this, since they've been quietly building out experimental WebGL 2.0 support for a while. The fact that other vendors haven't followed suite likely has more to do with internal priorities and resource availability than the spec state or any WG holdups. Safari and IE have been focusing on getting it's WebGL implementation release-worthy (great job to the teams involved!), and Chrome has been focusing intensely on stability and code cleanup (the aforementioned MANGLE effort, which is only a hairball if you're not familiar with Chrome's current GPU internals.) It's certainly not "sexy" work: everybody loves new features but it's hard to get excited about hearing that the browser crashes 30% less on a GPU that you don't own. The focus on implementation quality by all parties is crucial for ensuring that the API is viewed as more than a plaything for power-users, though. --Brandon On Sun Oct 19 2014 at 7:18:39 PM Jeff Gilbert wrote: For what it's worth, I disagree with your evaluations. I think we're largely in a good place right now, and on a good trajectory. I do not believe the WG has been a bottleneck for our WebGL implementation, at least. There's a lot of work that goes on behind the scenes which goes unappreciated. When done well, a decent amount of this work is nearly invisible. It's hard to put numbers on improved compatibility and conformance. It's still reasonable input if you believe we should have a stronger focus on features, but we're certainly not in the pure feature race. -Jeff ----- Original Message ----- From: "John Davis" To: "Tony Parisi" Cc: "Florian B?sch" , "public webgl" Sent: Sunday, October 19, 2014 2:23:53 PM Subject: Re: [Public WebGL] WebGL working group - leadership Apologies, I can't help but think we can do better. On Sun, Oct 19, 2014 at 3:03 PM, Tony Parisi wrote: > In my opinion, Ken is doing a fantastic job. > > One can measure the "progress" of a standard by its rate of adoption and > its high degree of interoperability - both crucial for its success - just > as much or more than the rate at which features are being introduced. WebGL > is tops in both. This is in no small part because this group, led by Ken, > has been stable and focused on conformance over adding features. > > What progress has been made in the last three years? WebGL is ubiquitous. > That's enough for me. I can live without multiple render targets for > another year... > > Tony > > > > > On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: > >> On http://webglstats.com/ with about 7-8 million visits across its >> contributing sites, I measure 90% desktops and 10% mobiles. For much of >> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >> flagging somewhat. >> >> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >> rest being uncategorizable other things). The change from last year is >> desktops -12% and mobiles +14%. Even assuming the trend'd continue >> linearly, you'd look at years before you could "lay desktops to rest" as an >> audience. >> >> However I'd also not be happy with a situation where a machine that I can >> stick in a GTX-980 that'll get about 1000x as much performance as any of >> the latest smarphones, is something that can't run WebGL well. I think >> that's counterproductive to WebGL. >> >> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >> wrote: >> >>> I would suggest we weigh the number of smart phones and tablets on the >>> planet against the number of PC's. Think big picture, India, China, U.S., >>> ... >>> >>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>> wrote: >>> >>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>>> wrote: >>>> >>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>>>> different, it affords this opportunity. There is no backwards >>>>> compatibility chain for existing developers. Everyone is starting again >>>>> with a new API. >>>>> >>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next year >>>> (around 8 months) and it'll support a lot of desktop and mobile hardware. >>>> WebGL 2.1 would probably not arrive next year and its support for desktop >>>> and mobile hardware would be substantially lower than WebGL 2.0. >>>> >>>> MANGLE is the hell you're speaking of. >>>>> >>>> A Web technology that doesn't work for most people is not very >>>> attractive. >>>> >>> >>> >> > > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my books! > > > *Programming 3D Applications in HTML5 and > WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 > WebGL, > Up and Running* > http://www.amazon.com/dp/144932357X > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Mon Oct 20 10:26:14 2014 From: zmo...@ (Zhenyao Mo) Date: Mon, 20 Oct 2014 10:26:14 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Perception could be biased / deceiving, specifically you focus your evaluation solely on the "speed" factor. It's like planting a tree, we all can't wait to taste the fruit, but things have their cycles, and rushing usually does not work; it could even kill the plant. The fact is WebGL has been growing healthily for the past a few years, and we have more fruits to pick in the near future. So I would say great job on Ken's side. On Sun, Oct 19, 2014 at 3:47 AM, John Davis wrote: > Ken, > > Nothing personal. As chairman of the webgl working group, for over three > years, what has been achieved thus far? > > My perception is the standard progressed much faster under Vlad. If he's > willing, why don't we put Vlad back in the driver's seat? > > JD > ----------------------------------------------------------- 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 ale...@ Mon Oct 20 10:58:19 2014 From: ale...@ (Aleksandar Rodic) Date: Mon, 20 Oct 2014 10:58:19 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: What I'm seeing is increasing support, stability and performance across all platforms at a rate I thought was not possible. Kudos to Ken and everyone at WebGL WG for making it possible. Aki Aleksandar Aki Rodi? | @xyz_ak | +1 510 761 5522 | aleksandarrodic.com On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: > > Perception could be biased / deceiving, specifically you focus your > evaluation solely on the "speed" factor. > > It's like planting a tree, we all can't wait to taste the fruit, but > things have their cycles, and rushing usually does not work; it could > even kill the plant. > > The fact is WebGL has been growing healthily for the past a few years, > and we have more fruits to pick in the near future. So I would say > great job on Ken's side. > > > On Sun, Oct 19, 2014 at 3:47 AM, John Davis > wrote: > > Ken, > > > > Nothing personal. As chairman of the webgl working group, for over three > > years, what has been achieved thus far? > > > > My perception is the standard progressed much faster under Vlad. If he's > > willing, why don't we put Vlad back in the driver's seat? > > > > JD > > > > ----------------------------------------------------------- > 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 khr...@ Mon Oct 20 12:28:21 2014 From: khr...@ (Gregg Tavares) Date: Mon, 20 Oct 2014 12:28:21 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Let me add as well I think Ken has done and is doing a great job. We all want the shiniest newest features. But, one goal of a browser is to run everywhere. If WebGL were to go 3.1 most phones couldn't run it. Browsers are trying to cover as many people as possible. In fact it's likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs on. Windows XP's market share is still > 1 out of 5 people. Even looking at Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 out of 5 iPhones is still a 4 or 4S. No existing phone that I know of supports 3.1 I don't think the browser's goals have ever been to be on the bleeding edge of GPU APIs. Their goals are a more along the lines of making them accessible to the most people. Targeting 3.1 would likely mean most people couldn't use the API for many years. Unlike GL the goal of a browser is as much as possible write once run everywhere. Different goals lead to different priorities. Personally I think the current goals are the appropriate ones. On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic wrote: > What I'm seeing is increasing support, stability and performance across > all platforms at a rate I thought was not possible. > > Kudos to Ken and everyone at WebGL WG for making it possible. > > Aki > > > Aleksandar Aki Rodi? | @xyz_ak | +1 510 761 > 5522 | aleksandarrodic.com > > On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: > >> >> Perception could be biased / deceiving, specifically you focus your >> evaluation solely on the "speed" factor. >> >> It's like planting a tree, we all can't wait to taste the fruit, but >> things have their cycles, and rushing usually does not work; it could >> even kill the plant. >> >> The fact is WebGL has been growing healthily for the past a few years, >> and we have more fruits to pick in the near future. So I would say >> great job on Ken's side. >> >> >> On Sun, Oct 19, 2014 at 3:47 AM, John Davis >> wrote: >> > Ken, >> > >> > Nothing personal. As chairman of the webgl working group, for over >> three >> > years, what has been achieved thus far? >> > >> > My perception is the standard progressed much faster under Vlad. If >> he's >> > willing, why don't we put Vlad back in the driver's seat? >> > >> > JD >> > >> >> ----------------------------------------------------------- >> 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 jda...@ Mon Oct 20 14:50:28 2014 From: jda...@ (John Davis) Date: Mon, 20 Oct 2014 17:50:28 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Is limiting ourselves to the lowest common denominator the best strategy? If WinXP is our gold standard, then we'll never have compute shaders. The goal of reaching the most people is already in place, webgl 1.0 and ANGLE. Why not start shooting for where the target will be? If people see compelling content on their friend's webgl 2.1/ES 3.1 device, they will be inclined to upgrade sooner rather than later. As opposed to us waiting on them to upgrade on their own. At this point, I still think it would be a better allocation of resources to focus on webgl 2.1/es 3.1 for Android and IOS, and then let MANGLE catch up. The latest iphones and tablets, which are selling like hotcakes, have ES 3.1 hardware, right? Why is this years away? On Mon, Oct 20, 2014 at 3:28 PM, Gregg Tavares wrote: > Let me add as well I think Ken has done and is doing a great job. > > We all want the shiniest newest features. But, one goal of a browser is to > run everywhere. If WebGL were to go 3.1 most phones couldn't run it. > Browsers are trying to cover as many people as possible. In fact it's > likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs > on. Windows XP's market share is still > 1 out of 5 people. Even looking at > Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 > out of 5 iPhones is still a 4 or 4S. No existing phone that I know of > supports 3.1 > > I don't think the browser's goals have ever been to be on the bleeding > edge of GPU APIs. Their goals are a more along the lines of making them > accessible to the most people. Targeting 3.1 would likely mean most people > couldn't use the API for many years. Unlike GL the goal of a browser is as > much as possible write once run everywhere. Different goals lead to > different priorities. Personally I think the current goals are the > appropriate ones. > > > > > > On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic < > aleksandar.xyz...@> wrote: > >> What I'm seeing is increasing support, stability and performance across >> all platforms at a rate I thought was not possible. >> >> Kudos to Ken and everyone at WebGL WG for making it possible. >> >> Aki >> >> >> Aleksandar Aki Rodi? | @xyz_ak | +1 510 761 >> 5522 | aleksandarrodic.com >> >> On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: >> >>> >>> Perception could be biased / deceiving, specifically you focus your >>> evaluation solely on the "speed" factor. >>> >>> It's like planting a tree, we all can't wait to taste the fruit, but >>> things have their cycles, and rushing usually does not work; it could >>> even kill the plant. >>> >>> The fact is WebGL has been growing healthily for the past a few years, >>> and we have more fruits to pick in the near future. So I would say >>> great job on Ken's side. >>> >>> >>> On Sun, Oct 19, 2014 at 3:47 AM, John Davis >>> wrote: >>> > Ken, >>> > >>> > Nothing personal. As chairman of the webgl working group, for over >>> three >>> > years, what has been achieved thus far? >>> > >>> > My perception is the standard progressed much faster under Vlad. If >>> he's >>> > willing, why don't we put Vlad back in the driver's seat? >>> > >>> > JD >>> > >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Oct 20 15:00:33 2014 From: jgi...@ (Jeff Gilbert) Date: Mon, 20 Oct 2014 15:00:33 -0700 (PDT) Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: <1055048233.27417198.1413842433535.JavaMail.zimbra@mozilla.com> It's not years away. It's months away, maybe a year-ish for 3.1 stuff. I feel I should reiterate that MANGLE has nothing to do with anyone but Google, so I'm not sure why it keeps coming up regarding implementation progress. If you want to discuss Google priorities, I recommend contacting Ken directly. Just because something sounds easy doesn't mean it is. We can't just pass calls from JS straight through to ES, and we need to do a ton of validation and driver workarounds for things to keep working. We also may need to update our shader validators to handle compute shaders. (Can we even implement ES3 on Mac's 4.1+extensions?) -Jeff ----- Original Message ----- From: "John Davis" To: "Gregg Tavares" Cc: "Aleksandar Rodic" , "Zhenyao Mo" , "public webgl" Sent: Monday, October 20, 2014 2:50:28 PM Subject: Re: [Public WebGL] WebGL working group - leadership Is limiting ourselves to the lowest common denominator the best strategy? If WinXP is our gold standard, then we'll never have compute shaders. The goal of reaching the most people is already in place, webgl 1.0 and ANGLE. Why not start shooting for where the target will be? If people see compelling content on their friend's webgl 2.1/ES 3.1 device, they will be inclined to upgrade sooner rather than later. As opposed to us waiting on them to upgrade on their own. At this point, I still think it would be a better allocation of resources to focus on webgl 2.1/es 3.1 for Android and IOS, and then let MANGLE catch up. The latest iphones and tablets, which are selling like hotcakes, have ES 3.1 hardware, right? Why is this years away? On Mon, Oct 20, 2014 at 3:28 PM, Gregg Tavares wrote: > Let me add as well I think Ken has done and is doing a great job. > > We all want the shiniest newest features. But, one goal of a browser is to > run everywhere. If WebGL were to go 3.1 most phones couldn't run it. > Browsers are trying to cover as many people as possible. In fact it's > likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs > on. Windows XP's market share is still > 1 out of 5 people. Even looking at > Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 > out of 5 iPhones is still a 4 or 4S. No existing phone that I know of > supports 3.1 > > I don't think the browser's goals have ever been to be on the bleeding > edge of GPU APIs. Their goals are a more along the lines of making them > accessible to the most people. Targeting 3.1 would likely mean most people > couldn't use the API for many years. Unlike GL the goal of a browser is as > much as possible write once run everywhere. Different goals lead to > different priorities. Personally I think the current goals are the > appropriate ones. > > > > > > On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic < > aleksandar.xyz...@> wrote: > >> What I'm seeing is increasing support, stability and performance across >> all platforms at a rate I thought was not possible. >> >> Kudos to Ken and everyone at WebGL WG for making it possible. >> >> Aki >> >> >> Aleksandar Aki Rodi? | @xyz_ak | +1 510 761 >> 5522 | aleksandarrodic.com >> >> On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: >> >>> >>> Perception could be biased / deceiving, specifically you focus your >>> evaluation solely on the "speed" factor. >>> >>> It's like planting a tree, we all can't wait to taste the fruit, but >>> things have their cycles, and rushing usually does not work; it could >>> even kill the plant. >>> >>> The fact is WebGL has been growing healthily for the past a few years, >>> and we have more fruits to pick in the near future. So I would say >>> great job on Ken's side. >>> >>> >>> On Sun, Oct 19, 2014 at 3:47 AM, John Davis >>> wrote: >>> > Ken, >>> > >>> > Nothing personal. As chairman of the webgl working group, for over >>> three >>> > years, what has been achieved thus far? >>> > >>> > My perception is the standard progressed much faster under Vlad. If >>> he's >>> > willing, why don't we put Vlad back in the driver's seat? >>> > >>> > JD >>> > >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >>> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From khr...@ Mon Oct 20 15:30:06 2014 From: khr...@ (Gregg Tavares) Date: Mon, 20 Oct 2014 15:30:06 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: On Mon, Oct 20, 2014 at 2:50 PM, John Davis wrote: > Is limiting ourselves to the lowest common denominator the best strategy? > If WinXP is our gold standard, then we'll never have compute shaders. > > The goal of reaching the most people is already in place, webgl 1.0 and > ANGLE. Why not start shooting for where the target will be? > I think they are shooting for where the target will be. Today > 50% of people can't run ES 3.0. By the time WebGL 2.0 ships maybe that will be up to 60% > If people see compelling content on their friend's webgl 2.1/ES 3.1 > device, they will be inclined to upgrade sooner rather than later. As > opposed to us waiting on them to upgrade on their own > . > > At this point, I still think it would be a better allocation of resources > to focus on webgl 2.1/es 3.1 for Android and IOS, and then let MANGLE catch > up. The latest iphones and tablets, which are selling like hotcakes, have > ES 3.1 hardware, right? > There's no ES 3.1 on iOS AFAIK and the first ES 3.1 device hasn't shipped for Android yet. > Why is this years away? > I don't know know all the differences between 3.0 and 3.1 but assuming 3.1 is just 3 + some stuff then there's no difference in timeline as implementing all 3.1 would require first implementing all of 3.0 which is exactly what they're already doing. Targeting 3.1 would just mean you'd have to wait for them to implement all of 3.0 then all the additions to get to 3.1 before you'd get anything. That's an even along timeline > > On Mon, Oct 20, 2014 at 3:28 PM, Gregg Tavares > wrote: > >> Let me add as well I think Ken has done and is doing a great job. >> >> We all want the shiniest newest features. But, one goal of a browser is >> to run everywhere. If WebGL were to go 3.1 most phones couldn't run it. >> Browsers are trying to cover as many people as possible. In fact it's >> likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs >> on. Windows XP's market share is still > 1 out of 5 people. Even looking at >> Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 >> out of 5 iPhones is still a 4 or 4S. No existing phone that I know of >> supports 3.1 >> >> I don't think the browser's goals have ever been to be on the bleeding >> edge of GPU APIs. Their goals are a more along the lines of making them >> accessible to the most people. Targeting 3.1 would likely mean most people >> couldn't use the API for many years. Unlike GL the goal of a browser is as >> much as possible write once run everywhere. Different goals lead to >> different priorities. Personally I think the current goals are the >> appropriate ones. >> >> >> >> >> >> On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic < >> aleksandar.xyz...@> wrote: >> >>> What I'm seeing is increasing support, stability and performance across >>> all platforms at a rate I thought was not possible. >>> >>> Kudos to Ken and everyone at WebGL WG for making it possible. >>> >>> Aki >>> >>> >>> Aleksandar Aki Rodi? | @xyz_ak | +1 510 >>> 761 5522 | aleksandarrodic.com >>> >>> On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: >>> >>>> >>>> Perception could be biased / deceiving, specifically you focus your >>>> evaluation solely on the "speed" factor. >>>> >>>> It's like planting a tree, we all can't wait to taste the fruit, but >>>> things have their cycles, and rushing usually does not work; it could >>>> even kill the plant. >>>> >>>> The fact is WebGL has been growing healthily for the past a few years, >>>> and we have more fruits to pick in the near future. So I would say >>>> great job on Ken's side. >>>> >>>> >>>> On Sun, Oct 19, 2014 at 3:47 AM, John Davis >>>> wrote: >>>> > Ken, >>>> > >>>> > Nothing personal. As chairman of the webgl working group, for over >>>> three >>>> > years, what has been achieved thus far? >>>> > >>>> > My perception is the standard progressed much faster under Vlad. If >>>> he's >>>> > willing, why don't we put Vlad back in the driver's seat? >>>> > >>>> > JD >>>> > >>>> >>>> ----------------------------------------------------------- >>>> You are currently subscribed to public_webgl...@ >>>> To unsubscribe, send an email to majordomo...@ with >>>> the following command in the body of your email: >>>> unsubscribe public_webgl >>>> ----------------------------------------------------------- >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Mon Oct 20 15:55:21 2014 From: baj...@ (Brandon Jones) Date: Mon, 20 Oct 2014 22:55:21 +0000 Subject: [Public WebGL] WebGL working group - leadership References: Message-ID: On Mon Oct 20 2014 at 3:30:46 PM Gregg Tavares wrote: > > I don't know know all the differences between 3.0 and 3.1 but assuming 3.1 > is just 3 + some stuff then there's no difference in timeline as > implementing all 3.1 would require first implementing all of 3.0 which is > exactly what they're already doing. Targeting 3.1 would just mean you'd > have to wait for them to implement all of 3.0 then all the additions to get > to 3.1 before you'd get anything. That's an even along timeline > Just as an FYI: 3.1 includes compute shaders, which will be... non-trivial to implement. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Oct 20 17:10:06 2014 From: jda...@ (John Davis) Date: Mon, 20 Oct 2014 20:10:06 -0400 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: I might be missing something. From what I can tell, iPhone 6, GX6450 gpu, ES 3.1 support. http://blog.imgtec.com/powervr/the-complete-guide-to-powervr-rogue-gpus-specifications-features-api-support Looks like iPhone 6 has the hardware to do ES 3.1 On Mon, Oct 20, 2014 at 6:27 PM, Gregg Tavares wrote: > > > On Mon, Oct 20, 2014 at 2:49 PM, John Davis > wrote: > >> Is limiting ourselves to the lowest common denominator the best >> strategy? If WinXP is our gold standard, then we'll never have compute >> shaders. >> >> The goal of reaching the most people is already in place, webgl 1.0 and >> ANGLE. Why not start shooting for where the target will be? >> > > I think they are shooting for where the target will be. Today > 50% of > people can't run ES 3.0. By the time WebGL 2.0 ships maybe that will be up > to 60% > > >> If people see compelling content on their friend's webgl 2.1/ES 3.1 >> device, they will be inclined to upgrade sooner rather than later. As >> opposed to us waiting on them to upgrade on their own. >> >> At this point, I still think it would be a better allocation of resources >> to focus on webgl 2.1/es 3.1 for Android and IOS, and then let MANGLE catch >> up. The latest iphones and tablets, which are selling like hotcakes, have >> ES 3.1 hardware, right? >> > > There's no ES 3.1 on iOS AFAIK and the first ES 3.1 device hasn't shipped > for Android yet. > > >> Why is this years away? >> > > I don't know know the differences between 3.0 and 3.1 but assuming 3.1 is > just 3 + some stuff then there's no difference in timeline as implementing > all 3.1 would require first implementing all of 3.0 which is exactly what > they're already doing. > > > >> >> >> >> On Mon, Oct 20, 2014 at 3:28 PM, Gregg Tavares >> wrote: >> >>> Let me add as well I think Ken has done and is doing a great job. >>> >>> We all want the shiniest newest features. But, one goal of a browser is >>> to run everywhere. If WebGL were to go 3.1 most phones couldn't run it. >>> Browsers are trying to cover as many people as possible. In fact it's >>> likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs >>> on. Windows XP's market share is still > 1 out of 5 people. Even looking at >>> Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 >>> out of 5 iPhones is still a 4 or 4S. No existing phone that I know of >>> supports 3.1 >>> >>> I don't think the browser's goals have ever been to be on the bleeding >>> edge of GPU APIs. Their goals are a more along the lines of making them >>> accessible to the most people. Targeting 3.1 would likely mean most people >>> couldn't use the API for many years. Unlike GL the goal of a browser is as >>> much as possible write once run everywhere. Different goals lead to >>> different priorities. Personally I think the current goals are the >>> appropriate ones. >>> >>> >>> >>> >>> >>> On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic < >>> aleksandar.xyz...@> wrote: >>> >>>> What I'm seeing is increasing support, stability and performance across >>>> all platforms at a rate I thought was not possible. >>>> >>>> Kudos to Ken and everyone at WebGL WG for making it possible. >>>> >>>> Aki >>>> >>>> >>>> Aleksandar Aki Rodi? | @xyz_ak | +1 510 >>>> 761 5522 | aleksandarrodic.com >>>> >>>> On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: >>>> >>>>> >>>>> Perception could be biased / deceiving, specifically you focus your >>>>> evaluation solely on the "speed" factor. >>>>> >>>>> It's like planting a tree, we all can't wait to taste the fruit, but >>>>> things have their cycles, and rushing usually does not work; it could >>>>> even kill the plant. >>>>> >>>>> The fact is WebGL has been growing healthily for the past a few years, >>>>> and we have more fruits to pick in the near future. So I would say >>>>> great job on Ken's side. >>>>> >>>>> >>>>> On Sun, Oct 19, 2014 at 3:47 AM, John Davis >>>>> wrote: >>>>> > Ken, >>>>> > >>>>> > Nothing personal. As chairman of the webgl working group, for over >>>>> three >>>>> > years, what has been achieved thus far? >>>>> > >>>>> > My perception is the standard progressed much faster under Vlad. If >>>>> he's >>>>> > willing, why don't we put Vlad back in the driver's seat? >>>>> > >>>>> > JD >>>>> > >>>>> >>>>> ----------------------------------------------------------- >>>>> 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 thu...@ Mon Oct 20 18:20:20 2014 From: thu...@ (Ben Adams) Date: Tue, 21 Oct 2014 02:20:20 +0100 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: Hi John Was just adding to the record of events for the last 3 years. So as not be misunderstood I will state my position: Not being part of the WebGL Working Group , I can't directly comment on Ken's chairmanship; however during it WebGL has risen to be the most ubiquitous graphics/GPU library, supported on every device that you can currently buy, every platform and every current browser; and you can even very simply return to the desktop with node-webkit if you wanted to do something like deploy via Steam. It also must be by now the most tested; have the most conformance tests and clear standards of any graphics library - so I think what the Working Group, and community has achieved is pretty amazing. Community-wise in my experience Ken is very active and nurturing, generally being one of the first to reply to posters in this and other forums with advice, suggestions and encouragement as well as step in when debates get a little too heated. I have at times been the recipient of this and thank him for it. On WebGL 2.1, I see WebGL more around ubiquity and productivity than bleeding edge. If you want the absolute latest then you go raw native as you get it before the other tools that use it have been written; but also you need to write each platform differently, and have different sets of code for different feature levels, fall-backs etc. Right now, I'm happy to wait a bit longer until ES3.1 is much more widespread before writing code for it. I felt differently prior to IE on Desktop/WinPhone and Safari on OSX/iOS joining the mix. I'm actually enjoying the interlude of unity of api. At this juncture its probably wiser to wait to see what the effects will be of the Android Extension Pack, iOS's Metal, AMD's Mantle and DirectX 12 before rushing to implement or define a cross platform WebGL > 2.0 Sorry, turned out a bit long... On 19 October 2014 22:17, John Davis wrote: > Completely agree, we wouldn't be here if it weren't for Mozilla and Vlad. > I wish they were still leading the standard. > > On Sun, Oct 19, 2014 at 3:47 PM, Ben Adams > wrote: > >> Also for the last 3 years, looking at adjunct WebGL progress bringing in >> more established areas: >> >> WebGL output from Unreal, Unity, Flash Professional (Adobe) >> >> There's even a WebGL based humble bundle: https://www.humblebundle.com/ >> >> Hat's off to Mozilla for a lot of work in these areas >> >> >> On 19 October 2014 20:03, Tony Parisi wrote: >> >>> In my opinion, Ken is doing a fantastic job. >>> >>> One can measure the "progress" of a standard by its rate of adoption and >>> its high degree of interoperability - both crucial for its success - just >>> as much or more than the rate at which features are being introduced. WebGL >>> is tops in both. This is in no small part because this group, led by Ken, >>> has been stable and focused on conformance over adding features. >>> >>> What progress has been made in the last three years? WebGL is >>> ubiquitous. That's enough for me. I can live without multiple render >>> targets for another year... >>> >>> Tony >>> >>> >>> >>> >>> On Sun, Oct 19, 2014 at 9:01 AM, Florian B?sch wrote: >>> >>>> On http://webglstats.com/ with about 7-8 million visits across its >>>> contributing sites, I measure 90% desktops and 10% mobiles. For much of >>>> 2012 and 2013 the trend for mobiles has been rising, but in 2014 it's >>>> flagging somewhat. >>>> >>>> http://gs.statcounter.com/ has Desktops at 62% and mobiles at 30% (the >>>> rest being uncategorizable other things). The change from last year is >>>> desktops -12% and mobiles +14%. Even assuming the trend'd continue >>>> linearly, you'd look at years before you could "lay desktops to rest" as an >>>> audience. >>>> >>>> However I'd also not be happy with a situation where a machine that I >>>> can stick in a GTX-980 that'll get about 1000x as much performance as any >>>> of the latest smarphones, is something that can't run WebGL well. I think >>>> that's counterproductive to WebGL. >>>> >>>> On Sun, Oct 19, 2014 at 5:49 PM, John Davis >>>> wrote: >>>> >>>>> I would suggest we weigh the number of smart phones and tablets on the >>>>> planet against the number of PC's. Think big picture, India, China, U.S., >>>>> ... >>>>> >>>>> On Sun, Oct 19, 2014 at 11:41 AM, Florian B?sch >>>>> wrote: >>>>> >>>>>> On Sun, Oct 19, 2014 at 5:33 PM, John Davis >>>>> > wrote: >>>>>> >>>>>>> Beginning with a clean slate is always easier. ES 3.1 is so >>>>>>> different, it affords this opportunity. There is no backwards >>>>>>> compatibility chain for existing developers. Everyone is starting again >>>>>>> with a new API. >>>>>>> >>>>>> I'll prefer WebGL 2.0 because it's quite likely it'll arrive next >>>>>> year (around 8 months) and it'll support a lot of desktop and mobile >>>>>> hardware. WebGL 2.1 would probably not arrive next year and its support for >>>>>> desktop and mobile hardware would be substantially lower than WebGL 2.0. >>>>>> >>>>>> MANGLE is the hell you're speaking of. >>>>>>> >>>>>> A Web technology that doesn't work for most people is not very >>>>>> attractive. >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Tony Parisi tparisi...@ >>> CTO at Large 415.902.8002 >>> Skype auradeluxe >>> Follow me on Twitter! http://twitter.com/auradeluxe >>> Read my blog at http://www.tonyparisi.com/ >>> Learn WebGL http://learningwebgl.com/ >>> >>> Read my books! >>> >>> >>> *Programming 3D Applications in HTML5 and >>> WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 >>> WebGL, >>> Up and Running* >>> http://www.amazon.com/dp/144932357X >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Tue Oct 21 06:13:50 2014 From: khr...@ (Mark Callow) Date: Tue, 21 Oct 2014 22:13:50 +0900 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: <10D5CECA-B75D-4F92-A72D-C77651478D05@callow.im> On Oct 21, 2014, at 9:10 AM, John Davis wrote: > I might be missing something. From what I can tell, iPhone 6, GX6450 gpu, ES 3.1 support. > > http://blog.imgtec.com/powervr/the-complete-guide-to-powervr-rogue-gpus-specifications-features-api-support > > Looks like iPhone 6 has the hardware to do ES 3.1 > And the smartphone I bought in January this year has ES 3.1-capable hardware. However I?d say the likelihood of receiving an OS/driver update that would provide 3.1 is close to zero. Possibly it is more likely for the iPhone 6 but iOS updates typically happen about once per year and there has just been one? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From dko...@ Tue Oct 21 07:08:36 2014 From: dko...@ (Daniel Koch) Date: Tue, 21 Oct 2014 14:08:36 +0000 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: > There's no ES 3.1 on iOS AFAIK and the first ES 3.1 device hasn't shipped for Android yet. iPhone 6 may or may not have the HW, but it currently doesn't have the drivers, AFAICT. However, there are shipping ES 3.1 devices for Android. The Xiaomi MiPad and SHIELD Tablet have both been shipping for months and in a few weeks the Nexus 9 will be shipping as well. I agree though that it will likely be a while before there is broad market support, and as others noted, ES 3.1 will likely be challenging on OSX with only GL 4.1 support. GL 4.3-level support would make it much more feasible... -Daniel On 2014-10-20 8:10 PM, "John Davis" > wrote: I might be missing something. From what I can tell, iPhone 6, GX6450 gpu, ES 3.1 support. http://blog.imgtec.com/powervr/the-complete-guide-to-powervr-rogue-gpus-specifications-features-api-support Looks like iPhone 6 has the hardware to do ES 3.1 On Mon, Oct 20, 2014 at 6:27 PM, Gregg Tavares > wrote: On Mon, Oct 20, 2014 at 2:49 PM, John Davis > wrote: Is limiting ourselves to the lowest common denominator the best strategy? If WinXP is our gold standard, then we'll never have compute shaders. The goal of reaching the most people is already in place, webgl 1.0 and ANGLE. Why not start shooting for where the target will be? I think they are shooting for where the target will be. Today > 50% of people can't run ES 3.0. By the time WebGL 2.0 ships maybe that will be up to 60% If people see compelling content on their friend's webgl 2.1/ES 3.1 device, they will be inclined to upgrade sooner rather than later. As opposed to us waiting on them to upgrade on their own. At this point, I still think it would be a better allocation of resources to focus on webgl 2.1/es 3.1 for Android and IOS, and then let MANGLE catch up. The latest iphones and tablets, which are selling like hotcakes, have ES 3.1 hardware, right? There's no ES 3.1 on iOS AFAIK and the first ES 3.1 device hasn't shipped for Android yet. Why is this years away? I don't know know the differences between 3.0 and 3.1 but assuming 3.1 is just 3 + some stuff then there's no difference in timeline as implementing all 3.1 would require first implementing all of 3.0 which is exactly what they're already doing. On Mon, Oct 20, 2014 at 3:28 PM, Gregg Tavares > wrote: Let me add as well I think Ken has done and is doing a great job. We all want the shiniest newest features. But, one goal of a browser is to run everywhere. If WebGL were to go 3.1 most phones couldn't run it. Browsers are trying to cover as many people as possible. In fact it's likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs on. Windows XP's market share is still > 1 out of 5 people. Even looking at Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 out of 5 iPhones is still a 4 or 4S. No existing phone that I know of supports 3.1 I don't think the browser's goals have ever been to be on the bleeding edge of GPU APIs. Their goals are a more along the lines of making them accessible to the most people. Targeting 3.1 would likely mean most people couldn't use the API for many years. Unlike GL the goal of a browser is as much as possible write once run everywhere. Different goals lead to different priorities. Personally I think the current goals are the appropriate ones. On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic > wrote: What I'm seeing is increasing support, stability and performance across all platforms at a rate I thought was not possible. Kudos to Ken and everyone at WebGL WG for making it possible. Aki Aleksandar Aki Rodi? | @xyz_ak | +1 510 761 5522 | aleksandarrodic.com On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo > wrote: Perception could be biased / deceiving, specifically you focus your evaluation solely on the "speed" factor. It's like planting a tree, we all can't wait to taste the fruit, but things have their cycles, and rushing usually does not work; it could even kill the plant. The fact is WebGL has been growing healthily for the past a few years, and we have more fruits to pick in the near future. So I would say great job on Ken's side. On Sun, Oct 19, 2014 at 3:47 AM, John Davis > wrote: > Ken, > > Nothing personal. As chairman of the webgl working group, for over three > years, what has been achieved thus far? > > My perception is the standard progressed much faster under Vlad. If he's > willing, why don't we put Vlad back in the driver's seat? > > JD > ----------------------------------------------------------- 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 Oct 21 07:19:48 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 21 Oct 2014 16:19:48 +0200 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: iPhone 6 has displaced 9% of the device population of iOS devices for now. 91% are older iPhones: https://mixpanel.com/trends/#report/iphone_6/from_date:-365,report_unit:month,to_date:0 The rate of change from the last 2 months is around 5% of the older population getting displaced/month. I'd guess this is similar for Android devices. Which means it's likely something around a year until the iPhone6, Xiaomi MiPad, Shield and Nexus 9 displace 50% of the existing device population. This is roughly in line with the study that found that people replace their their mobile devices around every 2 years: http://www.phonearena.com/news/Americans-replace-their-cell-phones-every-2-years-Finns--every-six-a-study-claims_id20255 On Tue, Oct 21, 2014 at 4:08 PM, Daniel Koch wrote: > > There's no ES 3.1 on iOS AFAIK and the first ES 3.1 device hasn't > shipped for Android yet. > > iPhone 6 may or may not have the HW, but it currently doesn?t have the > drivers, AFAICT. > > However, there are shipping ES 3.1 devices for Android. > The Xiaomi MiPad and SHIELD Tablet have both been shipping for months and > in a few weeks the Nexus 9 will be shipping as well. > > I agree though that it will likely be a while before there is broad > market support, and as others noted, ES 3.1 will likely be challenging on > OSX with only GL 4.1 support. GL 4.3-level support would make it much more > feasible... > > -Daniel > > On 2014-10-20 8:10 PM, "John Davis" wrote: > > I might be missing something. From what I can tell, iPhone 6, GX6450 > gpu, ES 3.1 support. > > > http://blog.imgtec.com/powervr/the-complete-guide-to-powervr-rogue-gpus-specifications-features-api-support > > Looks like iPhone 6 has the hardware to do ES 3.1 > > > On Mon, Oct 20, 2014 at 6:27 PM, Gregg Tavares > wrote: > >> >> >> On Mon, Oct 20, 2014 at 2:49 PM, John Davis >> wrote: >> >>> Is limiting ourselves to the lowest common denominator the best >>> strategy? If WinXP is our gold standard, then we'll never have compute >>> shaders. >>> >>> The goal of reaching the most people is already in place, webgl 1.0 >>> and ANGLE. Why not start shooting for where the target will be? >>> >> >> I think they are shooting for where the target will be. Today > 50% of >> people can't run ES 3.0. By the time WebGL 2.0 ships maybe that will be up >> to 60% >> >> >>> If people see compelling content on their friend's webgl 2.1/ES 3.1 >>> device, they will be inclined to upgrade sooner rather than later. As >>> opposed to us waiting on them to upgrade on their own. >>> >>> At this point, I still think it would be a better allocation of >>> resources to focus on webgl 2.1/es 3.1 for Android and IOS, and then let >>> MANGLE catch up. The latest iphones and tablets, which are selling like >>> hotcakes, have ES 3.1 hardware, right? >>> >> >> There's no ES 3.1 on iOS AFAIK and the first ES 3.1 device hasn't >> shipped for Android yet. >> >> >>> Why is this years away? >>> >> >> I don't know know the differences between 3.0 and 3.1 but assuming 3.1 >> is just 3 + some stuff then there's no difference in timeline as >> implementing all 3.1 would require first implementing all of 3.0 which is >> exactly what they're already doing. >> >> >> >>> >>> >>> >>> On Mon, Oct 20, 2014 at 3:28 PM, Gregg Tavares >>> wrote: >>> >>>> Let me add as well I think Ken has done and is doing a great job. >>>> >>>> We all want the shiniest newest features. But, one goal of a browser >>>> is to run everywhere. If WebGL were to go 3.1 most phones couldn't run it. >>>> Browsers are trying to cover as many people as possible. In fact it's >>>> likely WebGL 2.0 won't run on a great number of devices that WebGL 1.0 runs >>>> on. Windows XP's market share is still > 1 out of 5 people. Even looking at >>>> Mac's 30% of them can't run WebGL 2.0 which requires OSX 10.9 or higher. 1 >>>> out of 5 iPhones is still a 4 or 4S. No existing phone that I know of >>>> supports 3.1 >>>> >>>> I don't think the browser's goals have ever been to be on the >>>> bleeding edge of GPU APIs. Their goals are a more along the lines of making >>>> them accessible to the most people. Targeting 3.1 would likely mean most >>>> people couldn't use the API for many years. Unlike GL the goal of a browser >>>> is as much as possible write once run everywhere. Different goals lead to >>>> different priorities. Personally I think the current goals are the >>>> appropriate ones. >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Oct 20, 2014 at 10:58 AM, Aleksandar Rodic < >>>> aleksandar.xyz...@> wrote: >>>> >>>>> What I'm seeing is increasing support, stability and performance >>>>> across all platforms at a rate I thought was not possible. >>>>> >>>>> Kudos to Ken and everyone at WebGL WG for making it possible. >>>>> >>>>> Aki >>>>> >>>>> >>>>> Aleksandar Aki Rodi? | @xyz_ak | +1 >>>>> 510 761 5522 | aleksandarrodic.com >>>>> >>>>> On Mon, Oct 20, 2014 at 10:26 AM, Zhenyao Mo wrote: >>>>> >>>>>> >>>>>> Perception could be biased / deceiving, specifically you focus your >>>>>> evaluation solely on the "speed" factor. >>>>>> >>>>>> It's like planting a tree, we all can't wait to taste the fruit, but >>>>>> things have their cycles, and rushing usually does not work; it could >>>>>> even kill the plant. >>>>>> >>>>>> The fact is WebGL has been growing healthily for the past a few years, >>>>>> and we have more fruits to pick in the near future. So I would say >>>>>> great job on Ken's side. >>>>>> >>>>>> >>>>>> On Sun, Oct 19, 2014 at 3:47 AM, John Davis >>>>>> wrote: >>>>>> > Ken, >>>>>> > >>>>>> > Nothing personal. As chairman of the webgl working group, for over >>>>>> three >>>>>> > years, what has been achieved thus far? >>>>>> > >>>>>> > My perception is the standard progressed much faster under Vlad. >>>>>> If he's >>>>>> > willing, why don't we put Vlad back in the driver's seat? >>>>>> > >>>>>> > JD >>>>>> > >>>>>> >>>>>> ----------------------------------------------------------- >>>>>> 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 tib...@ Wed Oct 22 13:34:37 2014 From: tib...@ (Tibor Ouden, den) Date: Wed, 22 Oct 2014 22:34:37 +0200 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: Frank, Rafael, If you are interested in another test case : http://www.borbitsoft.com/ contains my attempt to create a PhysX / Havoc / Bullet equivalent in the browser. (It is still in its early stages :-) ) All the heavy lifting is done by shaders on the gpu. It contains some long shaders which currently are not digested by IE. There should be a general issue on Microsoft Connect. When I have some time I will create more specific issues. Tibor 2014-10-07 19:40 GMT+02:00 Rafael Cintron : > Hello Jukka. Thank you very much for your feedback. > > > > The IE build on the results page is not the latest released version. You > should re-run your benchmark with the latest released version available on > Windows Update. > > > > While IE has improved compared to where we once were, we are still not > better than Chrome when you throw a large number of objects at the > benchmark. On an ATI FirePro V card, I get 23fps with 5000 objects on IE. > Chrome yields 30fps with the same workload. There is definitely more work > for us to do here. > > > > If you find any more issues, please let myself or Frank know. > > > > --Rafael > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *Jukka Jyl?nki > *Sent:* Monday, October 6, 2014 10:07 AM > *To:* Frank Olivier > *Cc:* jdavis...@; public webgl > *Subject:* Re: [Public WebGL] IE11 > > > > Hi Frank, > > > > I posted one such bug item about IE11 performance to connect.microsoft.com, > but it was closed without action and later deleted. It was numbered 810215 > and the title was "IE11 performance is worse than FF, Chrome or Opera in > Emscripten WebGL benchmark.". At the time when I did the benchmarks, the > results looked like this: > https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_benchmark/10kCubes_results_20130312.html > . Perhaps things have changed since then. You can run the benchmark in one > of the links on the page. Also, here is more recent interactive version of > the same application: > https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes.html > (It starts out with setTimeout(0)-based rendering, tap B once to get > requestAnimationFrame-based rendering). > > > > For your convenience, here is a zipped build of the interactive version: > https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes_vsync.zip > . > > > > Best, > > Jukka > > > > 2014-10-06 19:48 GMT+03:00 Frank Olivier : > > > > Wrt: ?Javascript is still slower in IE11? ? We?re very interested in > scenarios where we can improve Javascript performance; if you can point us > to scenarios, we?d appreciate it. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Oct 22 13:43:25 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 22 Oct 2014 22:43:25 +0200 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: It'd be cool if there was a good issue tracker (ala bugzilla or code.google.com) for IE. CodePlex looks like it has a fairly good issue tracking system and it's Microsoft property. Maybe IE could use that to track issues. Another thing that other browsers do is release changelogs of what changed in which version. Popular are also release roadmaps/feature roadmaps (I think Microsoft had something like that). On Wed, Oct 22, 2014 at 10:34 PM, Tibor Ouden, den wrote: > Frank, Rafael, > > If you are interested in another test case : > http://www.borbitsoft.com/ contains my attempt to create a PhysX / Havoc > / Bullet equivalent in the browser. > (It is still in its early stages :-) ) > All the heavy lifting is done by shaders on the gpu. > It contains some long shaders which currently are not digested by IE. > There should be a general issue on Microsoft Connect. > When I have some time I will create more specific issues. > > Tibor > > > > 2014-10-07 19:40 GMT+02:00 Rafael Cintron : > >> Hello Jukka. Thank you very much for your feedback. >> >> >> >> The IE build on the results page is not the latest released version. You >> should re-run your benchmark with the latest released version available on >> Windows Update. >> >> >> >> While IE has improved compared to where we once were, we are still not >> better than Chrome when you throw a large number of objects at the >> benchmark. On an ATI FirePro V card, I get 23fps with 5000 objects on IE. >> Chrome yields 30fps with the same workload. There is definitely more work >> for us to do here. >> >> >> >> If you find any more issues, please let myself or Frank know. >> >> >> >> --Rafael >> >> >> >> *From:* owners-public_webgl...@ [mailto: >> owners-public_webgl...@] *On Behalf Of *Jukka Jyl?nki >> *Sent:* Monday, October 6, 2014 10:07 AM >> *To:* Frank Olivier >> *Cc:* jdavis...@; public webgl >> *Subject:* Re: [Public WebGL] IE11 >> >> >> >> Hi Frank, >> >> >> >> I posted one such bug item about IE11 performance to >> connect.microsoft.com, but it was closed without action and later >> deleted. It was numbered 810215 and the title was "IE11 performance is >> worse than FF, Chrome or Opera in Emscripten WebGL benchmark.". At the time >> when I did the benchmarks, the results looked like this: >> https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_benchmark/10kCubes_results_20130312.html >> . Perhaps things have changed since then. You can run the benchmark in one >> of the links on the page. Also, here is more recent interactive version of >> the same application: >> https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes.html >> (It starts out with setTimeout(0)-based rendering, tap B once to get >> requestAnimationFrame-based rendering). >> >> >> >> For your convenience, here is a zipped build of the interactive version: >> https://dl.dropboxusercontent.com/u/40949268/emcc/10kCubes_vsync/10kCubes_vsync.zip >> . >> >> >> >> Best, >> >> Jukka >> >> >> >> 2014-10-06 19:48 GMT+03:00 Frank Olivier : >> >> >> >> Wrt: ?Javascript is still slower in IE11? ? We?re very interested in >> scenarios where we can improve Javascript performance; if you can point us >> to scenarios, we?d appreciate it. >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Thu Oct 23 11:46:22 2014 From: din...@ (Dean Jackson) Date: Thu, 23 Oct 2014 11:46:22 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: Message-ID: <9E6561D8-3914-47A9-BCD2-6AD3E04DF317@apple.com> While this thread evolved into a discussion of ES 3.1 implementation feasibility, device update speeds, MANGLE development, etc, I just wanted to join in by saying that Apple + WebKit are completely happy with Ken?s chairing and leadership of WebGL. On a personal level, I find it almost insulting to suggest he?s been anything other than fantastic in the role. Dean > On 19 Oct 2014, at 3:47 am, John Davis wrote: > > Ken, > > Nothing personal. As chairman of the webgl working group, for over three years, what has been achieved thus far? > > My perception is the standard progressed much faster under Vlad. If he's willing, why don't we put Vlad back in the driver's seat? > > JD > ----------------------------------------------------------- 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 Raf...@ Thu Oct 23 12:01:45 2014 From: Raf...@ (Rafael Cintron) Date: Thu, 23 Oct 2014 19:01:45 +0000 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: <9E6561D8-3914-47A9-BCD2-6AD3E04DF317@apple.com> References: <9E6561D8-3914-47A9-BCD2-6AD3E04DF317@apple.com> Message-ID: I agree 100% with Dean. Microsoft and the IE team are happy with Ken's leadership of WebGL. -----Original Message----- From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Dean Jackson Sent: Thursday, October 23, 2014 11:46 AM To: jdavis...@ Cc: public webgl Subject: Re: [Public WebGL] WebGL working group - leadership While this thread evolved into a discussion of ES 3.1 implementation feasibility, device update speeds, MANGLE development, etc, I just wanted to join in by saying that Apple + WebKit are completely happy with Ken?s chairing and leadership of WebGL. On a personal level, I find it almost insulting to suggest he?s been anything other than fantastic in the role. Dean > On 19 Oct 2014, at 3:47 am, John Davis wrote: > > Ken, > > Nothing personal. As chairman of the webgl working group, for over three years, what has been achieved thus far? > > My perception is the standard progressed much faster under Vlad. If he's willing, why don't we put Vlad back in the driver's seat? > > JD > ----------------------------------------------------------- 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 Mik...@ Thu Oct 23 15:24:07 2014 From: Mik...@ (Bourges-sevenier, Mikael) Date: Thu, 23 Oct 2014 22:24:07 +0000 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: <9E6561D8-3914-47A9-BCD2-6AD3E04DF317@apple.com> Message-ID: KzEgZm9yIEFNRCB0b28uIEtlbuKAmXMgbGVhZGVyc2hpcCBpcyBzdGVsbGFyLg0KDQrigJQgbWlr ZQ0KDQo+IE9uIE9jdCAyMywgMjAxNCwgYXQgMTI6MDEgUE0sIFJhZmFlbCBDaW50cm9uIDxSYWZh ZWwuQ2ludHJvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gDQo+IEkgYWdyZWUgMTAwJSB3aXRo IERlYW4uICBNaWNyb3NvZnQgYW5kIHRoZSBJRSB0ZWFtIGFyZSBoYXBweSB3aXRoIEtlbidzIGxl YWRlcnNoaXAgb2YgV2ViR0wuICANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IG93bmVycy1wdWJsaWNfd2ViZ2xAa2hyb25vcy5vcmcgW21haWx0bzpvd25lcnMtcHVi bGljX3dlYmdsQGtocm9ub3Mub3JnXSBPbiBCZWhhbGYgT2YgRGVhbiBKYWNrc29uDQo+IFNlbnQ6 IFRodXJzZGF5LCBPY3RvYmVyIDIzLCAyMDE0IDExOjQ2IEFNDQo+IFRvOiBqZGF2aXNAcGNwcm9n cmFtbWluZy5jb20NCj4gQ2M6IHB1YmxpYyB3ZWJnbA0KPiBTdWJqZWN0OiBSZTogW1B1YmxpYyBX ZWJHTF0gV2ViR0wgd29ya2luZyBncm91cCAtIGxlYWRlcnNoaXANCj4gDQo+IA0KPiBXaGlsZSB0 aGlzIHRocmVhZCBldm9sdmVkIGludG8gYSBkaXNjdXNzaW9uIG9mIEVTIDMuMSBpbXBsZW1lbnRh dGlvbiBmZWFzaWJpbGl0eSwgZGV2aWNlIHVwZGF0ZSBzcGVlZHMsIE1BTkdMRSBkZXZlbG9wbWVu dCwgZXRjLCBJIGp1c3Qgd2FudGVkIHRvIGpvaW4gaW4gYnkgc2F5aW5nIHRoYXQgQXBwbGUgKyBX ZWJLaXQgYXJlIGNvbXBsZXRlbHkgaGFwcHkgd2l0aCBLZW7igJlzIGNoYWlyaW5nIGFuZCBsZWFk ZXJzaGlwIG9mIFdlYkdMLiBPbiBhIHBlcnNvbmFsIGxldmVsLCBJIGZpbmQgaXQgYWxtb3N0IGlu c3VsdGluZyB0byBzdWdnZXN0IGhl4oCZcyBiZWVuIGFueXRoaW5nIG90aGVyIHRoYW4gZmFudGFz dGljIGluIHRoZSByb2xlLg0KPiANCj4gRGVhbg0KPiANCj4+IE9uIDE5IE9jdCAyMDE0LCBhdCAz OjQ3IGFtLCBKb2huIERhdmlzIDxqZGF2aXNAcGNwcm9ncmFtbWluZy5jb20+IHdyb3RlOg0KPj4g DQo+PiBLZW4sDQo+PiANCj4+IE5vdGhpbmcgcGVyc29uYWwuICBBcyBjaGFpcm1hbiBvZiB0aGUg d2ViZ2wgd29ya2luZyBncm91cCwgZm9yIG92ZXIgdGhyZWUgeWVhcnMsIHdoYXQgaGFzIGJlZW4g YWNoaWV2ZWQgdGh1cyBmYXI/DQo+PiANCj4+IE15IHBlcmNlcHRpb24gaXMgdGhlIHN0YW5kYXJk IHByb2dyZXNzZWQgbXVjaCBmYXN0ZXIgdW5kZXIgVmxhZC4gIElmIGhlJ3Mgd2lsbGluZywgd2h5 IGRvbid0IHdlIHB1dCBWbGFkIGJhY2sgaW4gdGhlIGRyaXZlcidzIHNlYXQ/DQo+PiANCj4+IEpE DQo+PiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBZb3UgYXJlIGN1cnJlbnRseSBzdWJzY3JpYmVkIHRvIHB1 YmxpY193ZWJnbEBraHJvbm9zLm9yZy4NCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwg dG8gbWFqb3Jkb21vQGtocm9ub3Mub3JnIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kIGluIHRo ZSBib2R5IG9mIHlvdXIgZW1haWw6DQo+IHVuc3Vic2NyaWJlIHB1YmxpY193ZWJnbA0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiANCj4gGO+/ve+/vXnLq++/ve+/ve+/vSsubu+/vSvvv73vv73vv73vv73vv71ubljvv73vv73v v73vv71Ia++/vXos77+977+9E++/ve+/vey5uxzvv70m3rHvv73vv71qd++/vWopbe+/vWbvv73v v73vv71o77+977+9Ie+/ve+/veiyiu+/ve+/vSth77+9F++/ve+/vVlo77+9Ke+/vXLvv73vv71q d2Lvv73vv71ebu+/vXLvv73vv73vv73vv73vv73vv71qKW7vv73Lm++/ve+/ve+/vW3vv71ubljv v73vv73vv70NCg0K ----------------------------------------------------------- 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 jam...@ Thu Oct 23 15:27:03 2014 From: jam...@ (James Bedford) Date: Thu, 23 Oct 2014 15:27:03 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: References: <9E6561D8-3914-47A9-BCD2-6AD3E04DF317@apple.com> Message-ID: <5FDE9BB1-C202-4060-A072-C660F259E9A0@me.com> Guys... what is this?? James > On Oct 23, 2014, at 3:24 PM, Bourges-sevenier, Mikael wrote: > > > KzEgZm9yIEFNRCB0b28uIEtlbuKAmXMgbGVhZGVyc2hpcCBpcyBzdGVsbGFyLg0KDQrigJQgbWlr > ZQ0KDQo+IE9uIE9jdCAyMywgMjAxNCwgYXQgMTI6MDEgUE0sIFJhZmFlbCBDaW50cm9uIDxSYWZh > ZWwuQ2ludHJvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gDQo+IEkgYWdyZWUgMTAwJSB3aXRo > IERlYW4uICBNaWNyb3NvZnQgYW5kIHRoZSBJRSB0ZWFtIGFyZSBoYXBweSB3aXRoIEtlbidzIGxl > YWRlcnNoaXAgb2YgV2ViR0wuICANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ > IEZyb206IG93bmVycy1wdWJsaWNfd2ViZ2xAa2hyb25vcy5vcmcgW21haWx0bzpvd25lcnMtcHVi > bGljX3dlYmdsQGtocm9ub3Mub3JnXSBPbiBCZWhhbGYgT2YgRGVhbiBKYWNrc29uDQo+IFNlbnQ6 > IFRodXJzZGF5LCBPY3RvYmVyIDIzLCAyMDE0IDExOjQ2IEFNDQo+IFRvOiBqZGF2aXNAcGNwcm9n > cmFtbWluZy5jb20NCj4gQ2M6IHB1YmxpYyB3ZWJnbA0KPiBTdWJqZWN0OiBSZTogW1B1YmxpYyBX > ZWJHTF0gV2ViR0wgd29ya2luZyBncm91cCAtIGxlYWRlcnNoaXANCj4gDQo+IA0KPiBXaGlsZSB0 > aGlzIHRocmVhZCBldm9sdmVkIGludG8gYSBkaXNjdXNzaW9uIG9mIEVTIDMuMSBpbXBsZW1lbnRh > dGlvbiBmZWFzaWJpbGl0eSwgZGV2aWNlIHVwZGF0ZSBzcGVlZHMsIE1BTkdMRSBkZXZlbG9wbWVu > dCwgZXRjLCBJIGp1c3Qgd2FudGVkIHRvIGpvaW4gaW4gYnkgc2F5aW5nIHRoYXQgQXBwbGUgKyBX > ZWJLaXQgYXJlIGNvbXBsZXRlbHkgaGFwcHkgd2l0aCBLZW7igJlzIGNoYWlyaW5nIGFuZCBsZWFk > ZXJzaGlwIG9mIFdlYkdMLiBPbiBhIHBlcnNvbmFsIGxldmVsLCBJIGZpbmQgaXQgYWxtb3N0IGlu > c3VsdGluZyB0byBzdWdnZXN0IGhl4oCZcyBiZWVuIGFueXRoaW5nIG90aGVyIHRoYW4gZmFudGFz > dGljIGluIHRoZSByb2xlLg0KPiANCj4gRGVhbg0KPiANCj4+IE9uIDE5IE9jdCAyMDE0LCBhdCAz > OjQ3IGFtLCBKb2huIERhdmlzIDxqZGF2aXNAcGNwcm9ncmFtbWluZy5jb20+IHdyb3RlOg0KPj4g > DQo+PiBLZW4sDQo+PiANCj4+IE5vdGhpbmcgcGVyc29uYWwuICBBcyBjaGFpcm1hbiBvZiB0aGUg > d2ViZ2wgd29ya2luZyBncm91cCwgZm9yIG92ZXIgdGhyZWUgeWVhcnMsIHdoYXQgaGFzIGJlZW4g > YWNoaWV2ZWQgdGh1cyBmYXI/DQo+PiANCj4+IE15IHBlcmNlcHRpb24gaXMgdGhlIHN0YW5kYXJk > IHByb2dyZXNzZWQgbXVjaCBmYXN0ZXIgdW5kZXIgVmxhZC4gIElmIGhlJ3Mgd2lsbGluZywgd2h5 > IGRvbid0IHdlIHB1dCBWbGFkIGJhY2sgaW4gdGhlIGRyaXZlcidzIHNlYXQ/DQo+PiANCj4+IEpE > DQo+PiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t > LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBZb3UgYXJlIGN1cnJlbnRseSBzdWJzY3JpYmVkIHRvIHB1 > YmxpY193ZWJnbEBraHJvbm9zLm9yZy4NCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwg > dG8gbWFqb3Jkb21vQGtocm9ub3Mub3JnIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kIGluIHRo > ZSBib2R5IG9mIHlvdXIgZW1haWw6DQo+IHVuc3Vic2NyaWJlIHB1YmxpY193ZWJnbA0KPiAtLS0t > LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K > PiANCj4gGO+/ve+/vXnLq++/ve+/ve+/vSsubu+/vSvvv73vv73vv73vv73vv71ubljvv73vv73v > v73vv71Ia++/vXos77+977+9E++/ve+/vey5uxzvv70m3rHvv73vv71qd++/vWopbe+/vWbvv73v > v73vv71o77+977+9Ie+/ve+/veiyiu+/ve+/vSth77+9F++/ve+/vVlo77+9Ke+/vXLvv73vv71q > d2Lvv73vv71ebu+/vXLvv73vv73vv73vv73vv73vv71qKW7vv73Lm++/ve+/ve+/vW3vv71ubljv > v73vv73vv70NCg0K > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jam...@ Thu Oct 23 15:36:43 2014 From: jam...@ (James Bedford) Date: Thu, 23 Oct 2014 15:36:43 -0700 Subject: [Public WebGL] WebGL working group - leadership In-Reply-To: <5FDE9BB1-C202-4060-A072-C660F259E9A0@me.com> References: <9E6561D8-3914-47A9-BCD2-6AD3E04DF317@apple.com> <5FDE9BB1-C202-4060-A072-C660F259E9A0@me.com> Message-ID: <892CF40D-5906-46FA-B186-CF8CE2D7C193@me.com> Excuse the noise, looks like my Mail client has a bug? James p.s. I love you Ken! > On Oct 23, 2014, at 3:27 PM, James Bedford wrote: > > > Guys... what is this?? > > James > >> On Oct 23, 2014, at 3:24 PM, Bourges-sevenier, Mikael wrote: >> >> >> KzEgZm9yIEFNRCB0b28uIEtlbuKAmXMgbGVhZGVyc2hpcCBpcyBzdGVsbGFyLg0KDQrigJQgbWlr >> ZQ0KDQo+IE9uIE9jdCAyMywgMjAxNCwgYXQgMTI6MDEgUE0sIFJhZmFlbCBDaW50cm9uIDxSYWZh >> ZWwuQ2ludHJvbkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gDQo+IEkgYWdyZWUgMTAwJSB3aXRo >> IERlYW4uICBNaWNyb3NvZnQgYW5kIHRoZSBJRSB0ZWFtIGFyZSBoYXBweSB3aXRoIEtlbidzIGxl >> YWRlcnNoaXAgb2YgV2ViR0wuICANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ >> IEZyb206IG93bmVycy1wdWJsaWNfd2ViZ2xAa2hyb25vcy5vcmcgW21haWx0bzpvd25lcnMtcHVi >> bGljX3dlYmdsQGtocm9ub3Mub3JnXSBPbiBCZWhhbGYgT2YgRGVhbiBKYWNrc29uDQo+IFNlbnQ6 >> IFRodXJzZGF5LCBPY3RvYmVyIDIzLCAyMDE0IDExOjQ2IEFNDQo+IFRvOiBqZGF2aXNAcGNwcm9n >> cmFtbWluZy5jb20NCj4gQ2M6IHB1YmxpYyB3ZWJnbA0KPiBTdWJqZWN0OiBSZTogW1B1YmxpYyBX >> ZWJHTF0gV2ViR0wgd29ya2luZyBncm91cCAtIGxlYWRlcnNoaXANCj4gDQo+IA0KPiBXaGlsZSB0 >> aGlzIHRocmVhZCBldm9sdmVkIGludG8gYSBkaXNjdXNzaW9uIG9mIEVTIDMuMSBpbXBsZW1lbnRh >> dGlvbiBmZWFzaWJpbGl0eSwgZGV2aWNlIHVwZGF0ZSBzcGVlZHMsIE1BTkdMRSBkZXZlbG9wbWVu >> dCwgZXRjLCBJIGp1c3Qgd2FudGVkIHRvIGpvaW4gaW4gYnkgc2F5aW5nIHRoYXQgQXBwbGUgKyBX >> ZWJLaXQgYXJlIGNvbXBsZXRlbHkgaGFwcHkgd2l0aCBLZW7igJlzIGNoYWlyaW5nIGFuZCBsZWFk >> ZXJzaGlwIG9mIFdlYkdMLiBPbiBhIHBlcnNvbmFsIGxldmVsLCBJIGZpbmQgaXQgYWxtb3N0IGlu >> c3VsdGluZyB0byBzdWdnZXN0IGhl4oCZcyBiZWVuIGFueXRoaW5nIG90aGVyIHRoYW4gZmFudGFz >> dGljIGluIHRoZSByb2xlLg0KPiANCj4gRGVhbg0KPiANCj4+IE9uIDE5IE9jdCAyMDE0LCBhdCAz >> OjQ3IGFtLCBKb2huIERhdmlzIDxqZGF2aXNAcGNwcm9ncmFtbWluZy5jb20+IHdyb3RlOg0KPj4g >> DQo+PiBLZW4sDQo+PiANCj4+IE5vdGhpbmcgcGVyc29uYWwuICBBcyBjaGFpcm1hbiBvZiB0aGUg >> d2ViZ2wgd29ya2luZyBncm91cCwgZm9yIG92ZXIgdGhyZWUgeWVhcnMsIHdoYXQgaGFzIGJlZW4g >> YWNoaWV2ZWQgdGh1cyBmYXI/DQo+PiANCj4+IE15IHBlcmNlcHRpb24gaXMgdGhlIHN0YW5kYXJk >> IHByb2dyZXNzZWQgbXVjaCBmYXN0ZXIgdW5kZXIgVmxhZC4gIElmIGhlJ3Mgd2lsbGluZywgd2h5 >> IGRvbid0IHdlIHB1dCBWbGFkIGJhY2sgaW4gdGhlIGRyaXZlcidzIHNlYXQ/DQo+PiANCj4+IEpE >> DQo+PiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t >> LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBZb3UgYXJlIGN1cnJlbnRseSBzdWJzY3JpYmVkIHRvIHB1 >> YmxpY193ZWJnbEBraHJvbm9zLm9yZy4NCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQgYW4gZW1haWwg >> dG8gbWFqb3Jkb21vQGtocm9ub3Mub3JnIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kIGluIHRo >> ZSBib2R5IG9mIHlvdXIgZW1haWw6DQo+IHVuc3Vic2NyaWJlIHB1YmxpY193ZWJnbA0KPiAtLS0t >> LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K >> PiANCj4gGO+/ve+/vXnLq++/ve+/ve+/vSsubu+/vSvvv73vv73vv73vv73vv71ubljvv73vv73v >> v73vv71Ia++/vXos77+977+9E++/ve+/vey5uxzvv70m3rHvv73vv71qd++/vWopbe+/vWbvv73v >> v73vv71o77+977+9Ie+/ve+/veiyiu+/ve+/vSth77+9F++/ve+/vVlo77+9Ke+/vXLvv73vv71q >> d2Lvv73vv71ebu+/vXLvv73vv73vv73vv73vv73vv71qKW7vv73Lm++/ve+/ve+/vW3vv71ubljv >> v73vv73vv70NCg0K >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Oct 27 23:03:05 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 07:03:05 +0100 Subject: [Public WebGL] Re: retrograde webgl support levels In-Reply-To: References: Message-ID: A worrying trend in webgl parameter support has appeared, mainly trough the introduction of WebGL to iOS. - MAX_VERTEX_UNIFORM_VECTORS long held lowest level (250) is being supplanted by a new lowest level (128) now at 4.1% - MAX_TEXTURE_IMAGE_UNITS long held lowest level (16) is being supplanted by new lowest level (8) now at 4.4% - MAX_COMBINED_TEXTURE_IMAGE_UNITS long held lowest level (16) is supplanted by new lowest level (8) now at 4.2% Trends with similar, but not as problematic nature (due to less rigidly held previous levels are): - MAX_VARYING_VECTORS lowest level (8) is expanding from 3.5% -> 5.4% this month - MAX_FRAGMENT_UNIFORM_VECTORS just approached new lowest level (221) is supplanted by new lowest level (64) now at 4.9% I have illustrated the situation with this a picture ( http://codeflow.org/pictures/webgl-parameters-retrograde.png and attached). These developments, particularly the first three are problematic because these parameter lowest levels have been held for nearly 3 years, and as a consequence a lot of WebGL applications out in the wild probably accommodate those practical minimal limits. The introduction of a new lower limits has the potential to break those applications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Oct 27 23:04:01 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 07:04:01 +0100 Subject: [Public WebGL] Re: retrograde webgl support levels In-Reply-To: References: Message-ID: Attachment for the retrograde parameter support. On Tue, Oct 28, 2014 at 7:03 AM, Florian B?sch wrote: > A worrying trend in webgl parameter support has appeared, mainly trough > the introduction of WebGL to iOS. > > - MAX_VERTEX_UNIFORM_VECTORS long held lowest level (250) is being > supplanted by a new lowest level (128) now at 4.1% > - MAX_TEXTURE_IMAGE_UNITS long held lowest level (16) is being > supplanted by new lowest level (8) now at 4.4% > - MAX_COMBINED_TEXTURE_IMAGE_UNITS long held lowest level (16) is > supplanted by new lowest level (8) now at 4.2% > > Trends with similar, but not as problematic nature (due to less rigidly > held previous levels are): > > - MAX_VARYING_VECTORS lowest level (8) is expanding from 3.5% -> 5.4% > this month > - MAX_FRAGMENT_UNIFORM_VECTORS just approached new lowest level (221) > is supplanted by new lowest level (64) now at 4.9% > > I have illustrated the situation with this a picture ( > http://codeflow.org/pictures/webgl-parameters-retrograde.png and > attached). > > These developments, particularly the first three are problematic because > these parameter lowest levels have been held for nearly 3 years, and as a > consequence a lot of WebGL applications out in the wild probably > accommodate those practical minimal limits. The introduction of a new lower > limits has the potential to break those applications. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: webgl-parameters-retrograde.png Type: image/png Size: 161851 bytes Desc: not available URL: From kir...@ Tue Oct 28 02:45:01 2014 From: kir...@ (Kirill Prazdnikov) Date: Tue, 28 Oct 2014 12:45:01 +0300 Subject: [Public WebGL] IE11 In-Reply-To: References: Message-ID: <544F659D.5050002@jetbrains.com> Hi Frank, This is one more WebGL test which fails under IE11 with *internal error *(latest version) which runs perfectly well under chrome and ff: https://www.shadertoy.com/view/4sfGWX* * Thanks -Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Oct 28 04:04:08 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 12:04:08 +0100 Subject: [Public WebGL] typed array convenience Message-ID: Typed arrays as specified by Khronos ( https://www.khronos.org/registry/typedarray/specs/latest/) do not have convenient methods to fill an array. To illustrate the issue I created this jsperf test: http://jsperf.com/typed-array-fast-filling The most convenient method would be to fill a section of the array from arguments, a list and other typed arrays. Something like: fillArray(r, i, [x0, y0, 1, 0, 0]); or fillArguments(r, i, x0, y0, 1, 0, 0); Unfortunately that's also the second slowest method to do it as the jsperf test shows (screenshot here http://codeflow.org/pictures/typed-array-test.png and attached). The fastest method by far (a factor of 3-4x) is the following: r[i] = x0; > r[i + 1] = y0; > r[i + 2] = 1; > r[i + 3] = 0; > r[i + 4] = 0; i += 5 This is unfortunate because it's also the least maintainable and readable code possible. I propose an addition to the typed array specification that introduces these methods like - argcpy(uint dstOffset, arguments...) - arrcpy(uint dstOffset, Array|TypedArrayView someArray) - memcpy(uint dstByteOffset, TypedArray[View] origin, uint srcByteOffset, uint srcByteCount) The name or the semantic of the methods doesn't matter to me, as long as they facilitate fast, efficient and convenient filling of typed arrays. It is quite often for tasks todo with tessellation, subdivision, geometry generation etc. to have to write code like that. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: typed-array-test.png Type: image/png Size: 15646 bytes Desc: not available URL: From khr...@ Tue Oct 28 06:11:17 2014 From: khr...@ (Mark Callow) Date: Tue, 28 Oct 2014 22:11:17 +0900 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: Message-ID: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> On Oct 28, 2014, at 3:03 PM, Florian B?sch wrote: > These developments, particularly the first three are problematic because these parameter lowest levels have been held for nearly 3 years, and as a consequence a lot of WebGL applications out in the wild probably accommodate those practical minimal limits. The introduction of a new lower limits has the potential to break those applications. Do you have any suggestions on how to deal with this? I believe the WebGL implementations reflect the limits of the underlying implementation. The lower limits you describe are within the OpenGL ES 2 specification and have probably been that way on these iOS devices all along. Many of them are almost certainly fundamental limitations of the hardware.The bright spot is that with the iPhone 6 reportedly selling so well, maybe those older devices won?t be around for much longer. 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 Oct 28 06:15:06 2014 From: khr...@ (Mark Callow) Date: Tue, 28 Oct 2014 22:15:06 +0900 Subject: [Public WebGL] typed array convenience In-Reply-To: References: Message-ID: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: > I propose an addition to the typed array specification that introduces these methods like > argcpy(uint dstOffset, arguments...) > arrcpy(uint dstOffset, Array|TypedArrayView someArray) > memcpy(uint dstByteOffset, TypedArray[View] origin, uint srcByteOffset, uint srcByteCount) > The name or the semantic of the methods doesn't matter to me, as long as they facilitate fast, efficient and convenient filling of typed arrays. > I would like to see these functions provided. I?ve wanted something like this myself on an earlier project. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Oct 28 06:36:16 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 14:36:16 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: On Tue, Oct 28, 2014 at 2:11 PM, Mark Callow wrote: > > Do you have any suggestions on how to deal with this? I believe the WebGL > implementations reflect the limits of the underlying implementation. These parameters are only represented at the lower end by relatively few android devices (most androids, often by more than 3/4 support the higher values. My iPad mini retina natively supports: - MAX_VERTEX_UNIFORM_VECTORS: 512 (384 more than webgl) - MAX_COMBINED_TEXTURE_IMAGE_UNITS: 32 (24 more than webgl) - MAX_TEXTURE_IMAGE_UNITS: 16 (8 more than webgl) My iPod touch 5tg gen supports: - MAX_VERTEX_UNIFORM_VECTORS: 128 (0 more than webgl) - MAX_COMBINED_TEXTURE_IMAGE_UNITS: 8 (0 more than webgl) - MAX_TEXTURE_IMAGE_UNITS: 8 (0 more than webgl) So the constraints do not reflect hardware constraints outright on some devices, particularly not the newer ones. I've detailed this fact on this blog post http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-webgl-implementation/#hardcoded-constraints-on-ios . See also this webkit ticket https://bugs.webkit.org/show_bug.cgi?id=133745 I understand Apples desire to support older devices and not fragment their own ecosystem with different capabilities (or perhaps it's just implementation convenience). However, in the act of doing so, they're fracturing the larger WebGL ecosystem, in particular, any application written in WebGL in the last 3 years that bumps against the practical lower limits. > The lower limits you describe are within the OpenGL ES 2 specification and > have probably been that way on these iOS devices all along. Many of them > are almost certainly fundamental limitations of the hardware.The bright > spot is that with the iPhone 6 reportedly selling so well, maybe those > older devices won?t be around for much longer. > Most android hardware (which is more budget oriented than iOS hardware) already superseeds those well established lower boundaries. It's reasonable to assume most iOS hardware in existence does so too (see iPad mini retina, and probably everything from iPhone 4 onwards). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jus...@ Tue Oct 28 06:42:31 2014 From: jus...@ (Jussi Kalliokoski) Date: Tue, 28 Oct 2014 15:42:31 +0200 Subject: [Public WebGL] typed array convenience In-Reply-To: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 3:15 PM, Mark Callow wrote: > > On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: > > I propose an addition to the typed array specification that introduces > these methods like > > - argcpy(uint dstOffset, arguments...) > - arrcpy(uint dstOffset, Array|TypedArrayView someArray) > > dst.set(someArray, dstOffset); > > - memcpy(uint dstByteOffset, TypedArray[View] origin, uint > srcByteOffset, uint srcByteCount) > > dst.set(src.subarray(srcOffset, srcOffset + srcByteCount), dstOffset); > The name or the semantic of the methods doesn't matter to me, as long as > they facilitate fast, efficient and convenient filling of typed arrays. > > > I would like to see these functions provided. I?ve wanted something like > this myself on an earlier project. > > Regards > > -Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Tue Oct 28 06:59:14 2014 From: flo...@ (Floh) Date: Tue, 28 Oct 2014 14:59:14 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: Are these native numbers what the GPU supports, or what the iOS GLES2 driver exposes? I don't have access to an iPhone6, but on the iPhone6 *simulator* a native GLES2 context exposes the same limits as the WebGL implementation (with iOS8.1): GL_MAX_TEXTURE_SIZE: 4096 GL_MAX_CUBE_MAP_TEXTURE_SIZE: 4096 GL_MAX_VIEWPORT_DIMS: 4096 4096 GL_MAX_VERTEX_ATTRIBS: 16 GL_MAX_VERTEX_UNIFORM_VECTORS: 128 GL_MAX_VARYING_VECTORS: 8 GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS: 8 GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS: 8 GL_MAX_FRAGMENT_UNIFORM_VECTORS: 64 My Gen4 iPad is the same (on the device, not simulator). I haven't checked OpenGLES3 yet on the iPhone6 simulator. Cheers, -Floh. On Tue, Oct 28, 2014 at 2:36 PM, Florian B?sch wrote: > On Tue, Oct 28, 2014 at 2:11 PM, Mark Callow wrote: >> >> Do you have any suggestions on how to deal with this? I believe the WebGL >> implementations reflect the limits of the underlying implementation. > > These parameters are only represented at the lower end by relatively few > android devices (most androids, often by more than 3/4 support the higher > values. > > My iPad mini retina natively supports: > > MAX_VERTEX_UNIFORM_VECTORS: 512 (384 more than webgl) > MAX_COMBINED_TEXTURE_IMAGE_UNITS: 32 (24 more than webgl) > MAX_TEXTURE_IMAGE_UNITS: 16 (8 more than webgl) > > My iPod touch 5tg gen supports: > > MAX_VERTEX_UNIFORM_VECTORS: 128 (0 more than webgl) > MAX_COMBINED_TEXTURE_IMAGE_UNITS: 8 (0 more than webgl) > MAX_TEXTURE_IMAGE_UNITS: 8 (0 more than webgl) > > So the constraints do not reflect hardware constraints outright on some > devices, particularly not the newer ones. I've detailed this fact on this > blog post > http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-webgl-implementation/#hardcoded-constraints-on-ios > . See also this webkit ticket https://bugs.webkit.org/show_bug.cgi?id=133745 > > I understand Apples desire to support older devices and not fragment their > own ecosystem with different capabilities (or perhaps it's just > implementation convenience). However, in the act of doing so, they're > fracturing the larger WebGL ecosystem, in particular, any application > written in WebGL in the last 3 years that bumps against the practical lower > limits. > >> >> The lower limits you describe are within the OpenGL ES 2 specification and >> have probably been that way on these iOS devices all along. Many of them are >> almost certainly fundamental limitations of the hardware.The bright spot is >> that with the iPhone 6 reportedly selling so well, maybe those older devices >> won?t be around for much longer. > > Most android hardware (which is more budget oriented than iOS hardware) > already superseeds those well established lower boundaries. It's reasonable > to assume most iOS hardware in existence does so too (see iPad mini retina, > and probably everything from iPhone 4 onwards). ----------------------------------------------------------- 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 flo...@ Tue Oct 28 07:02:45 2014 From: flo...@ (Floh) Date: Tue, 28 Oct 2014 15:02:45 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: PS: numbers for a native iOS8.1 GLES3 context running on the iPhone6 *simulator*: GL_VERSION: OpenGL ES 3.0 APPLE-10.1.5 GL_VENDOR: Apple Inc. GL_RENDERER: Apple Software Renderer GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 3.00 GL_MAX_TEXTURE_SIZE: 16384 GL_MAX_CUBE_MAP_TEXTURE_SIZE: 16384 GL_MAX_VIEWPORT_DIMS: 16384 16384 GL_MAX_VERTEX_ATTRIBS: 16 GL_MAX_VERTEX_UNIFORM_VECTORS: 512 GL_MAX_VARYING_VECTORS: 15 GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS: 32 GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS: 16 GL_MAX_FRAGMENT_UNIFORM_VECTORS: 224 But GLES3 is only supported on iPhone5S and better AFAIK. On Tue, Oct 28, 2014 at 2:59 PM, Floh wrote: > Are these native numbers what the GPU supports, or what the iOS GLES2 > driver exposes? I don't have access to an iPhone6, but on the iPhone6 > *simulator* a native GLES2 context exposes the same limits as the > WebGL implementation (with iOS8.1): > > GL_MAX_TEXTURE_SIZE: 4096 > GL_MAX_CUBE_MAP_TEXTURE_SIZE: 4096 > GL_MAX_VIEWPORT_DIMS: 4096 4096 > GL_MAX_VERTEX_ATTRIBS: 16 > GL_MAX_VERTEX_UNIFORM_VECTORS: 128 > GL_MAX_VARYING_VECTORS: 8 > GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS: 8 > GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS: 8 > GL_MAX_FRAGMENT_UNIFORM_VECTORS: 64 > > My Gen4 iPad is the same (on the device, not simulator). I haven't > checked OpenGLES3 yet on the iPhone6 simulator. > > Cheers, > -Floh. > > On Tue, Oct 28, 2014 at 2:36 PM, Florian B?sch wrote: >> On Tue, Oct 28, 2014 at 2:11 PM, Mark Callow wrote: >>> >>> Do you have any suggestions on how to deal with this? I believe the WebGL >>> implementations reflect the limits of the underlying implementation. >> >> These parameters are only represented at the lower end by relatively few >> android devices (most androids, often by more than 3/4 support the higher >> values. >> >> My iPad mini retina natively supports: >> >> MAX_VERTEX_UNIFORM_VECTORS: 512 (384 more than webgl) >> MAX_COMBINED_TEXTURE_IMAGE_UNITS: 32 (24 more than webgl) >> MAX_TEXTURE_IMAGE_UNITS: 16 (8 more than webgl) >> >> My iPod touch 5tg gen supports: >> >> MAX_VERTEX_UNIFORM_VECTORS: 128 (0 more than webgl) >> MAX_COMBINED_TEXTURE_IMAGE_UNITS: 8 (0 more than webgl) >> MAX_TEXTURE_IMAGE_UNITS: 8 (0 more than webgl) >> >> So the constraints do not reflect hardware constraints outright on some >> devices, particularly not the newer ones. I've detailed this fact on this >> blog post >> http://codeflow.org/entries/2014/jun/08/some-issues-with-apples-ios-webgl-implementation/#hardcoded-constraints-on-ios >> . See also this webkit ticket https://bugs.webkit.org/show_bug.cgi?id=133745 >> >> I understand Apples desire to support older devices and not fragment their >> own ecosystem with different capabilities (or perhaps it's just >> implementation convenience). However, in the act of doing so, they're >> fracturing the larger WebGL ecosystem, in particular, any application >> written in WebGL in the last 3 years that bumps against the practical lower >> limits. >> >>> >>> The lower limits you describe are within the OpenGL ES 2 specification and >>> have probably been that way on these iOS devices all along. Many of them are >>> almost certainly fundamental limitations of the hardware.The bright spot is >>> that with the iPhone 6 reportedly selling so well, maybe those older devices >>> won?t be around for much longer. >> >> Most android hardware (which is more budget oriented than iOS hardware) >> already superseeds those well established lower boundaries. It's reasonable >> to assume most iOS hardware in existence does so too (see iPad mini retina, >> and probably everything from iPhone 4 onwards). ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Oct 28 07:06:24 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 15:06:24 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: On Tue, Oct 28, 2014 at 2:59 PM, Floh wrote: > Are these native numbers what the GPU supports, or what the iOS GLES2 > driver exposes? These numbers come from gfxbench on a native device, not a simulator. -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Tue Oct 28 07:13:56 2014 From: flo...@ (Floh) Date: Tue, 28 Oct 2014 15:13:56 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: Found a link with in the iOS docs, it looks like an OpenGLES2 context always has the low limits even on the latest GPUs, and only a GLES3 context has the new, higher limits. Strange decision by Apple: https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html On Tue, Oct 28, 2014 at 3:06 PM, Florian B?sch wrote: > On Tue, Oct 28, 2014 at 2:59 PM, Floh wrote: >> >> Are these native numbers what the GPU supports, or what the iOS GLES2 >> driver exposes? > > These numbers come from gfxbench on a native device, not a simulator. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Oct 28 07:19:12 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 15:19:12 +0100 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 2:42 PM, Jussi Kalliokoski < jussi.kalliokoski...@> wrote: > On Tue, Oct 28, 2014 at 3:15 PM, Mark Callow wrote: > >> >> On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: >> >> I propose an addition to the typed array specification that introduces >> these methods like >> >> - argcpy(uint dstOffset, arguments...) >> - arrcpy(uint dstOffset, Array|TypedArrayView someArray) >> >> dst.set(someArray, dstOffset); > dst.set(0, 1, 2, 3, 4) --> invalid argument errort, not a substitute for argcpy suggestion. dst.set([1,2,3,4], dstOffset) is substantially slower than one at a time assignment (it's the second slowest method in fact). Updated jsperf http://jsperf.com/typed-array-fast-filling, attached screenshot http://codeflow.org/pictures/typed-array-test.png, blue on the bottom is array.set. > >> - memcpy(uint dstByteOffset, TypedArray[View] origin, uint >> srcByteOffset, uint srcByteCount) >> >> dst.set(src.subarray(srcOffset, srcOffset + srcByteCount), dstOffset); > You do not want to allocate an object a million times if you can avoid it in an on-line preprocessing step to copy memory from one array to another. Likewise, you do not want to allocate a GCed object oftentime at runtime for fairly obvious reasons. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: typed-array-test.png Type: image/png Size: 16900 bytes Desc: not available URL: From jus...@ Tue Oct 28 07:56:37 2014 From: jus...@ (Jussi Kalliokoski) Date: Tue, 28 Oct 2014 16:56:37 +0200 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 4:19 PM, Florian B?sch wrote: > > > On Tue, Oct 28, 2014 at 2:42 PM, Jussi Kalliokoski < > jussi.kalliokoski...@> wrote: > >> On Tue, Oct 28, 2014 at 3:15 PM, Mark Callow wrote: >> >>> >>> On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: >>> >>> I propose an addition to the typed array specification that introduces >>> these methods like >>> >>> - argcpy(uint dstOffset, arguments...) >>> - arrcpy(uint dstOffset, Array|TypedArrayView someArray) >>> >>> dst.set(someArray, dstOffset); >> > > dst.set(0, 1, 2, 3, 4) --> invalid argument errort, not a substitute for > argcpy suggestion. > Didn't try to be. :) > dst.set([1,2,3,4], dstOffset) is substantially slower than one at a time > assignment (it's the second slowest method in fact). Updated jsperf > http://jsperf.com/typed-array-fast-filling, attached screenshot > http://codeflow.org/pictures/typed-array-test.png, blue on the bottom is > array.set. > That can only be improved by improving the implementations, adding a new method that does the exact same thing (except that the arguments are reversed) won't help. I doubt the arguments-based one would be any better, since I'm quite skeptic that arguments objects have better performance characteristics (in terms of memory, GC or allocation time) than arrays. > > >> >>> - memcpy(uint dstByteOffset, TypedArray[View] origin, uint >>> srcByteOffset, uint srcByteCount) >>> >>> dst.set(src.subarray(srcOffset, srcOffset + srcByteCount), dstOffset); >> > > You do not want to allocate an object a million times if you can avoid it > in an on-line preprocessing step to copy memory from one array to another. > Likewise, you do not want to allocate a GCed object oftentime at runtime > for fairly obvious reasons. > Obviously. Maybe we could introduce optional arguments for srcOffset and srcEnd to set(). Or add a new method to avoid overloading costs. - Jussi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue Oct 28 08:13:30 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 28 Oct 2014 17:13:30 +0200 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: Regarding Chrome falling WebGL support, I noticed yesterday that on my 2011 Macbook Air which has Intel HD 3000, running Windows in bootcamp, Chrome started rejecting to create any WebGL canvases there. On Firefox and Chrome Canary WebGL does work. Perhaps they have a bad browser version out and later ones have fixed the issue? Jukka 2014-10-28 16:06 GMT+02:00 Florian B?sch : > On Tue, Oct 28, 2014 at 2:59 PM, Floh wrote: > >> Are these native numbers what the GPU supports, or what the iOS GLES2 >> driver exposes? > > These numbers come from gfxbench on a native device, not a simulator. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue Oct 28 08:21:58 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 28 Oct 2014 17:21:58 +0200 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: Being able to do typed array memcpys without allocating new typed array views would be very much preferred by Emscripten applications. A lot of Emscripten-generated garbage comes from this origin, and the impact of this to Firefox is being discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=936168 In Emscripten specifically to implement memcpy, we have observed typed array .set() to be slower than manually looping over bytes for small copies, so in Emscripten, short <4K element memcpys do a for loop over the data, and only larger ones do a typed array .set() call. I suspect Florian's example of very small ~1K range of copying won't get any faster if there are JS function calls involved. 2014-10-28 16:56 GMT+02:00 Jussi Kalliokoski : > On Tue, Oct 28, 2014 at 4:19 PM, Florian B?sch wrote: > >> >> >> On Tue, Oct 28, 2014 at 2:42 PM, Jussi Kalliokoski < >> jussi.kalliokoski...@> wrote: >> >>> On Tue, Oct 28, 2014 at 3:15 PM, Mark Callow wrote: >>> >>>> >>>> On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: >>>> >>>> I propose an addition to the typed array specification that introduces >>>> these methods like >>>> >>>> - argcpy(uint dstOffset, arguments...) >>>> - arrcpy(uint dstOffset, Array|TypedArrayView someArray) >>>> >>>> dst.set(someArray, dstOffset); >>> >> >> dst.set(0, 1, 2, 3, 4) --> invalid argument errort, not a substitute for >> argcpy suggestion. >> > > Didn't try to be. :) > > >> dst.set([1,2,3,4], dstOffset) is substantially slower than one at a time >> assignment (it's the second slowest method in fact). Updated jsperf >> http://jsperf.com/typed-array-fast-filling, attached screenshot >> http://codeflow.org/pictures/typed-array-test.png, blue on the bottom is >> array.set. >> > > That can only be improved by improving the implementations, adding a new > method that does the exact same thing (except that the arguments are > reversed) won't help. I doubt the arguments-based one would be any better, > since I'm quite skeptic that arguments objects have better performance > characteristics (in terms of memory, GC or allocation time) than arrays. > > >> >> >>> >>>> - memcpy(uint dstByteOffset, TypedArray[View] origin, uint >>>> srcByteOffset, uint srcByteCount) >>>> >>>> dst.set(src.subarray(srcOffset, srcOffset + srcByteCount), dstOffset); >>> >> >> You do not want to allocate an object a million times if you can avoid it >> in an on-line preprocessing step to copy memory from one array to another. >> Likewise, you do not want to allocate a GCed object oftentime at runtime >> for fairly obvious reasons. >> > > Obviously. Maybe we could introduce optional arguments for srcOffset and > srcEnd to set(). Or add a new method to avoid overloading costs. > > - Jussi > > >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jus...@ Tue Oct 28 09:58:36 2014 From: jus...@ (Jussi Kalliokoski) Date: Tue, 28 Oct 2014 18:58:36 +0200 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 5:21 PM, Jukka Jyl?nki wrote: > Being able to do typed array memcpys without allocating new typed array > views would be very much preferred by Emscripten applications. A lot of > Emscripten-generated garbage comes from this origin, and the impact of this > to Firefox is being discussed at > https://bugzilla.mozilla.org/show_bug.cgi?id=936168 > > Thanks for the link, lot's of interesting insight there! > In Emscripten specifically to implement memcpy, we have observed typed > array .set() to be slower than manually looping over bytes for small > copies, so in Emscripten, short <4K element memcpys do a for loop over the > data, and only larger ones do a typed array .set() call. I suspect > Florian's example of very small ~1K range of copying won't get any faster > if there are JS function calls involved. > Yep. I've mostly dealt with audio, where (due to the current script processing strategy of Web Audio API implementations) the buffer sizes are generally around 8k samples or more, and set() has been the most efficient way to deal with copying there. Even for zeroing an array, the fastest strategy has been to dst.set(new Float32Array(dst.length)), even with the GC costs. I've sometimes gone as far as to have empty arrays lying around for zeroing, and/or sending array buffers I know to be GC'd to an empty worker... Don't take my word for it though, it's been more than a year since I was last doing this sort of stuff actively. I think while it can be improved, set() is pretty good for memset, but FWIW in the case of filling arrays with arbitrary data, native implementations won't be of much help. I like to think of JS as a distributed system in terms of performance, where you want to pass small data in close proximity and larger data when the distance grows (where native implementations are far and JS implementations are close). If you care about performance, eventually you'll probably want to use SIMD intrinsics for most of the array filling cases anyway (which will of course unfortunately be even harder to read than the currently fastest implementation), so adding a method specifically for the performance characteristics of that use case seems premature. But to come back to my zeroing example, I think it would be super-handy to have a method for filling an array with a specific number, e.g. zero. This has been one of the biggest performance headaches I've had in implementing DSP stuff, where just iterating over a large array and setting all values to one specific value is severely slower than using set() on a pre-defined array. The Web Array Math [1] proposal defines other filling methods, such as filling with random or a range, but I think resetting the array should be something defined in the Typed Array spec itself. BTW, this discussion should probably take place in es-discuss, given that ES adopted typed arrays into its spec. - Jussi [1] http://opera-mage.github.io/webarraymath/ > 2014-10-28 16:56 GMT+02:00 Jussi Kalliokoski > : > >> On Tue, Oct 28, 2014 at 4:19 PM, Florian B?sch wrote: >> >>> >>> >>> On Tue, Oct 28, 2014 at 2:42 PM, Jussi Kalliokoski < >>> jussi.kalliokoski...@> wrote: >>> >>>> On Tue, Oct 28, 2014 at 3:15 PM, Mark Callow wrote: >>>> >>>>> >>>>> On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: >>>>> >>>>> I propose an addition to the typed array specification that introduces >>>>> these methods like >>>>> >>>>> - argcpy(uint dstOffset, arguments...) >>>>> - arrcpy(uint dstOffset, Array|TypedArrayView someArray) >>>>> >>>>> dst.set(someArray, dstOffset); >>>> >>> >>> dst.set(0, 1, 2, 3, 4) --> invalid argument errort, not a substitute for >>> argcpy suggestion. >>> >> >> Didn't try to be. :) >> >> >>> dst.set([1,2,3,4], dstOffset) is substantially slower than one at a time >>> assignment (it's the second slowest method in fact). Updated jsperf >>> http://jsperf.com/typed-array-fast-filling, attached screenshot >>> http://codeflow.org/pictures/typed-array-test.png, blue on the bottom >>> is array.set. >>> >> >> That can only be improved by improving the implementations, adding a new >> method that does the exact same thing (except that the arguments are >> reversed) won't help. I doubt the arguments-based one would be any better, >> since I'm quite skeptic that arguments objects have better performance >> characteristics (in terms of memory, GC or allocation time) than arrays. >> >> >>> >>> >>>> >>>>> - memcpy(uint dstByteOffset, TypedArray[View] origin, uint >>>>> srcByteOffset, uint srcByteCount) >>>>> >>>>> dst.set(src.subarray(srcOffset, srcOffset + srcByteCount), dstOffset); >>>> >>> >>> You do not want to allocate an object a million times if you can avoid >>> it in an on-line preprocessing step to copy memory from one array to >>> another. Likewise, you do not want to allocate a GCed object oftentime at >>> runtime for fairly obvious reasons. >>> >> >> Obviously. Maybe we could introduce optional arguments for srcOffset and >> srcEnd to set(). Or add a new method to avoid overloading costs. >> >> - Jussi >> >> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Oct 28 10:14:37 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 18:14:37 +0100 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 5:58 PM, Jussi Kalliokoski < jussi.kalliokoski...@> wrote: > I think while it can be improved, set() is pretty good for memset, but > FWIW in the case of filling arrays with arbitrary data, native > implementations won't be of much help. I like to think of JS as a > distributed system in terms of performance, where you want to pass small > data in close proximity and larger data when the distance grows (where > native implementations are far and JS implementations are close). > > If you care about performance, eventually you'll probably want to use SIMD > intrinsics for most of the array filling cases anyway (which will of course > unfortunately be even harder to read than the currently fastest > implementation), so adding a method specifically for the performance > characteristics of that use case seems premature. > I agree that memset/memcpy, while useful in other context, are useless to produce arbitrary data. Where I really disagree is that this (or an even worse mess) is the "best" that is attainable. That's simply not good enough. It is inconceivable to me how JS should fail at something that python, C, C++, lua, Java, haskell, erlang, brainfuck, D, go, and so forth all solve. Efficiently filling a binary array with data. This is a joke, it's a complete joke. You're seriously promoting a joke, as "best practice". I cannot condone this, that's baggering belief beyond my capacity to even wrap my mind around that idea. That's so broken, no words, just wow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jus...@ Tue Oct 28 10:38:41 2014 From: jus...@ (Jussi Kalliokoski) Date: Tue, 28 Oct 2014 19:38:41 +0200 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 7:14 PM, Florian B?sch wrote: > On Tue, Oct 28, 2014 at 5:58 PM, Jussi Kalliokoski < > jussi.kalliokoski...@> wrote: > >> I think while it can be improved, set() is pretty good for memset, but >> FWIW in the case of filling arrays with arbitrary data, native >> implementations won't be of much help. I like to think of JS as a >> distributed system in terms of performance, where you want to pass small >> data in close proximity and larger data when the distance grows (where >> native implementations are far and JS implementations are close). >> >> If you care about performance, eventually you'll probably want to use >> SIMD intrinsics for most of the array filling cases anyway (which will of >> course unfortunately be even harder to read than the currently fastest >> implementation), so adding a method specifically for the performance >> characteristics of that use case seems premature. >> > > I agree that memset/memcpy, while useful in other context, are useless to > produce arbitrary data. > > Where I really disagree is that this (or an even worse mess) is the "best" > that is attainable. That's simply not good enough. It is inconceivable to > me how JS should fail at something that python, C, C++, lua, Java, haskell, > erlang, brainfuck, D, go, and so forth all solve. Efficiently filling a > binary array with data. This is a joke, it's a complete joke. You're > seriously promoting a joke, as "best practice". I cannot condone this, > that's baggering belief beyond my capacity to even wrap my mind around that > idea. That's so broken, no words, just wow. > Don't take me wrong, I completely agree with your sentiment. I'm also not promoting any best practices, I was merely reflecting on my experiences on trying to squeeze out every bit of performance out of audio processing (at that given time), as well as the state of the art JS engines where there is a barrier between native calls and JS code, so big that it's for example a bad idea to use the native Function#bind() in performance-intensive parts of your application. Maybe that's a problem that can be fixed, but for what I've seen, I can't blame people for not trying, and it's still bad. I don't want it to be like this. In fact, probably for the past few years there hasn't been a day that I haven't cursed the most ubiquitous software development platform being bound to this broken language. On a personal level, I have pretty much zero hope of ever seeing readable and efficient JS converge. I'd be exploding with happiness to be proven wrong, though. Writing and reading for example efficient SciPy DSP code is fun and easy, instead of excruciatingly painful like with JS, and that's what I'd like to be able to do on the web as well. - Jussi -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Oct 28 10:45:29 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 28 Oct 2014 18:45:29 +0100 Subject: [Public WebGL] Re: typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: Well I can tell where it'll go. Do everything on the gpu, because it cannot be done efficiently in js. Once t&f, Tesselation, geometry and compute shaders are around. Pitty just you can't output audio from the gpu, yet. On Tuesday, October 28, 2014, Jussi Kalliokoski wrote: > On Tue, Oct 28, 2014 at 7:14 PM, Florian B?sch > wrote: > >> On Tue, Oct 28, 2014 at 5:58 PM, Jussi Kalliokoski < >> jussi.kalliokoski...@ >> > wrote: >> >>> I think while it can be improved, set() is pretty good for memset, but >>> FWIW in the case of filling arrays with arbitrary data, native >>> implementations won't be of much help. I like to think of JS as a >>> distributed system in terms of performance, where you want to pass small >>> data in close proximity and larger data when the distance grows (where >>> native implementations are far and JS implementations are close). >>> >>> If you care about performance, eventually you'll probably want to use >>> SIMD intrinsics for most of the array filling cases anyway (which will of >>> course unfortunately be even harder to read than the currently fastest >>> implementation), so adding a method specifically for the performance >>> characteristics of that use case seems premature. >>> >> >> I agree that memset/memcpy, while useful in other context, are useless to >> produce arbitrary data. >> >> Where I really disagree is that this (or an even worse mess) is the >> "best" that is attainable. That's simply not good enough. It is >> inconceivable to me how JS should fail at something that python, C, C++, >> lua, Java, haskell, erlang, brainfuck, D, go, and so forth all solve. >> Efficiently filling a binary array with data. This is a joke, it's a >> complete joke. You're seriously promoting a joke, as "best practice". I >> cannot condone this, that's baggering belief beyond my capacity to even >> wrap my mind around that idea. That's so broken, no words, just wow. >> > > Don't take me wrong, I completely agree with your sentiment. I'm also not > promoting any best practices, I was merely reflecting on my experiences on > trying to squeeze out every bit of performance out of audio processing (at > that given time), as well as the state of the art JS engines where there is > a barrier between native calls and JS code, so big that it's for example a > bad idea to use the native Function#bind() in performance-intensive parts > of your application. Maybe that's a problem that can be fixed, but for what > I've seen, I can't blame people for not trying, and it's still bad. > > I don't want it to be like this. In fact, probably for the past few years > there hasn't been a day that I haven't cursed the most ubiquitous software > development platform being bound to this broken language. On a personal > level, I have pretty much zero hope of ever seeing readable and efficient > JS converge. I'd be exploding with happiness to be proven wrong, though. > Writing and reading for example efficient SciPy DSP code is fun and easy, > instead of excruciatingly painful like with JS, and that's what I'd like to > be able to do on the web as well. > > - Jussi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Tue Oct 28 11:17:36 2014 From: Raf...@ (Rafael Cintron) Date: Tue, 28 Oct 2014 18:17:36 +0000 Subject: [Public WebGL] IE11 In-Reply-To: <544F659D.5050002@jetbrains.com> References: <544F659D.5050002@jetbrains.com> Message-ID: Thank you for your bug report, Kirill. We?ll investigate. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kirill Prazdnikov Sent: Tuesday, October 28, 2014 2:45 AM To: Frank Olivier; public webgl Subject: Re: [Public WebGL] IE11 Hi Frank, This is one more WebGL test which fails under IE11 with internal error (latest version) which runs perfectly well under chrome and ff: https://www.shadertoy.com/view/4sfGWX Thanks -Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Oct 28 14:49:56 2014 From: din...@ (Dean Jackson) Date: Tue, 28 Oct 2014 14:49:56 -0700 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: > On 28 Oct 2014, at 7:13 am, Floh wrote: > > > Found a link with in the iOS docs, it looks like an OpenGLES2 context > always has the low limits even on the latest GPUs, and only a GLES3 > context has the new, higher limits. That's correct. We don't add any limits to WebGL over the platform GLES2 context. Dean > Strange decision by Apple: > > https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html > > > On Tue, Oct 28, 2014 at 3:06 PM, Florian B?sch wrote: >> On Tue, Oct 28, 2014 at 2:59 PM, Floh wrote: >>> >>> Are these native numbers what the GPU supports, or what the iOS GLES2 >>> driver exposes? >> >> These numbers come from gfxbench on a native device, not a simulator. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Oct 28 22:46:58 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 29 Oct 2014 06:46:58 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: On Tue, Oct 28, 2014 at 10:49 PM, Dean Jackson wrote: > That's correct. We don't add any limits to WebGL over the platform GLES2 > context. > Whatever the cause, it's makes me worry about WebGL pages written, tested, finalized and released in 2011, 2012, 2013 and the better part of 2014. -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Oct 28 23:22:35 2014 From: din...@ (Dean Jackson) Date: Tue, 28 Oct 2014 23:22:35 -0700 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: <3EFC4638-280B-42ED-95A5-991F1B85ADF7@apple.com> > On 28 Oct 2014, at 22:46, Florian B?sch wrote: > >> On Tue, Oct 28, 2014 at 10:49 PM, Dean Jackson wrote: >> That's correct. We don't add any limits to WebGL over the platform GLES2 context. > > Whatever the cause, it's makes me worry about WebGL pages written, tested, finalized and released in 2011, 2012, 2013 and the better part of 2014. Yes, but this is the nature of the Web. The limits we're discussing are real on many devices, which means content won't work if it exceeds those limits. Outside WebGL, it could be that some devices don't support 1080p video, or complex Web Audio graphs, or run out of memory with a huge HTML document. A great feature of WebGL is that it exposes API to detect those limits. Most other Web things don't. I think another reason this has become a point of concern is that iOS updates are more available to older hardware than other systems. We could have decided to not enable WebGL on older devices, but that would be a huge shame - the devices are capable, just not as powerful as desktop machines. There is no shortage of GLES2 native apps that run on them. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Oct 28 23:53:05 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 29 Oct 2014 07:53:05 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: <3EFC4638-280B-42ED-95A5-991F1B85ADF7@apple.com> References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> <3EFC4638-280B-42ED-95A5-991F1B85ADF7@apple.com> Message-ID: On Wed, Oct 29, 2014 at 7:22 AM, Dean Jackson wrote: > Yes, but this is the nature of the Web. The limits we're discussing are > real on many devices, which means content won't work if it exceeds those > limits. Outside WebGL, it could be that some devices don't support 1080p > video, or complex Web Audio graphs, or run out of memory with a huge HTML > document. > That's true, however that doesn't explain why ES2 contexts are artificially hobbled where they didn't need to be. > A great feature of WebGL is that it exposes API to detect those limits. > Most other Web things don't. > That's also true, but that's why I highlighted these 3 parameters specifically (although the effect is found in nearly a dozen parameters). These parameters have been at very consistent levels for over 3 years, and so I see a "moral hazard" that may be present in many webgl apps. The steady lower limits where first established by PCs and later when more mobiles joined in, most of them already didn't go below those limits. That's why it's a concern, because it's easy to see how somebody could conclude, from years and years of observing these values, that it's safe to use them at the lower practical limit, not the lowest possible limit. I think another reason this has become a point of concern is that iOS > updates are more available to older hardware than other systems. We could > have decided to not enable WebGL on older devices, but that would be a huge > shame - the devices are capable, just not as powerful as desktop machines. > There is no shortage of GLES2 native apps that run on them. > And yet Android captures a higher usage share than iOS in some device categories, delivers fast updates as well, to many older devices, is more budget oriented and supports a very wide range of older hardware, and doesn't have this issue as pronounced (because they don't artificially hobble ES2 contexts). -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Oct 29 20:53:56 2014 From: kbr...@ (Kenneth Russell) Date: Wed, 29 Oct 2014 20:53:56 -0700 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Tue, Oct 28, 2014 at 9:58 AM, Jussi Kalliokoski < jussi.kalliokoski...@> wrote: > On Tue, Oct 28, 2014 at 5:21 PM, Jukka Jyl?nki wrote: > >> Being able to do typed array memcpys without allocating new typed array >> views would be very much preferred by Emscripten applications. A lot of >> Emscripten-generated garbage comes from this origin, and the impact of this >> to Firefox is being discussed at >> https://bugzilla.mozilla.org/show_bug.cgi?id=936168 >> >> > Thanks for the link, lot's of interesting insight there! > > >> In Emscripten specifically to implement memcpy, we have observed typed >> array .set() to be slower than manually looping over bytes for small >> copies, so in Emscripten, short <4K element memcpys do a for loop over the >> data, and only larger ones do a typed array .set() call. I suspect >> Florian's example of very small ~1K range of copying won't get any faster >> if there are JS function calls involved. >> > > Yep. I've mostly dealt with audio, where (due to the current script > processing strategy of Web Audio API implementations) the buffer sizes are > generally around 8k samples or more, and set() has been the most efficient > way to deal with copying there. Even for zeroing an array, the fastest > strategy has been to dst.set(new Float32Array(dst.length)), even with the > GC costs. I've sometimes gone as far as to have empty arrays lying around > for zeroing, and/or sending array buffers I know to be GC'd to an empty > worker... Don't take my word for it though, it's been more than a year > since I was last doing this sort of stuff actively. > > I think while it can be improved, set() is pretty good for memset, but > FWIW in the case of filling arrays with arbitrary data, native > implementations won't be of much help. I like to think of JS as a > distributed system in terms of performance, where you want to pass small > data in close proximity and larger data when the distance grows (where > native implementations are far and JS implementations are close). > > If you care about performance, eventually you'll probably want to use SIMD > intrinsics for most of the array filling cases anyway (which will of course > unfortunately be even harder to read than the currently fastest > implementation), so adding a method specifically for the performance > characteristics of that use case seems premature. > > But to come back to my zeroing example, I think it would be super-handy to > have a method for filling an array with a specific number, e.g. zero. This > has been one of the biggest performance headaches I've had in implementing > DSP stuff, where just iterating over a large array and setting all values > to one specific value is severely slower than using set() on a pre-defined > array. The Web Array Math [1] proposal defines other filling methods, such > as filling with random or a range, but I think resetting the array should > be something defined in the Typed Array spec itself. > > BTW, this discussion should probably take place in es-discuss, given that > ES adopted typed arrays into its spec. > Yes, at this point, proposals to improve typed arrays' APIs should happen on es-discuss: see https://esdiscuss.org/ . Khronos' typed array spec is no longer the API definition. The current ES6 draft can be found at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts . Keep in mind that when these types were subsumed into the ECMAScript spec, the goal was to share as much behavior as possible with "ordinary" ECMAScript arrays, so Florian, please think about how the new methods you suggest could be specified to apply to both. -Ken - Jussi > > [1] http://opera-mage.github.io/webarraymath/ > > >> 2014-10-28 16:56 GMT+02:00 Jussi Kalliokoski > >: >> >>> On Tue, Oct 28, 2014 at 4:19 PM, Florian B?sch wrote: >>> >>>> >>>> >>>> On Tue, Oct 28, 2014 at 2:42 PM, Jussi Kalliokoski < >>>> jussi.kalliokoski...@> wrote: >>>> >>>>> On Tue, Oct 28, 2014 at 3:15 PM, Mark Callow >>>>> wrote: >>>>> >>>>>> >>>>>> On Oct 28, 2014, at 8:04 PM, Florian B?sch wrote: >>>>>> >>>>>> I propose an addition to the typed array specification that >>>>>> introduces these methods like >>>>>> >>>>>> - argcpy(uint dstOffset, arguments...) >>>>>> - arrcpy(uint dstOffset, Array|TypedArrayView someArray) >>>>>> >>>>>> dst.set(someArray, dstOffset); >>>>> >>>> >>>> dst.set(0, 1, 2, 3, 4) --> invalid argument errort, not a substitute >>>> for argcpy suggestion. >>>> >>> >>> Didn't try to be. :) >>> >>> >>>> dst.set([1,2,3,4], dstOffset) is substantially slower than one at a >>>> time assignment (it's the second slowest method in fact). Updated jsperf >>>> http://jsperf.com/typed-array-fast-filling, attached screenshot >>>> http://codeflow.org/pictures/typed-array-test.png, blue on the bottom >>>> is array.set. >>>> >>> >>> That can only be improved by improving the implementations, adding a new >>> method that does the exact same thing (except that the arguments are >>> reversed) won't help. I doubt the arguments-based one would be any better, >>> since I'm quite skeptic that arguments objects have better performance >>> characteristics (in terms of memory, GC or allocation time) than arrays. >>> >>> >>>> >>>> >>>>> >>>>>> - memcpy(uint dstByteOffset, TypedArray[View] origin, uint >>>>>> srcByteOffset, uint srcByteCount) >>>>>> >>>>>> dst.set(src.subarray(srcOffset, srcOffset + srcByteCount), dstOffset); >>>>> >>>> >>>> You do not want to allocate an object a million times if you can avoid >>>> it in an on-line preprocessing step to copy memory from one array to >>>> another. Likewise, you do not want to allocate a GCed object oftentime at >>>> runtime for fairly obvious reasons. >>>> >>> >>> Obviously. Maybe we could introduce optional arguments for srcOffset and >>> srcEnd to set(). Or add a new method to avoid overloading costs. >>> >>> - Jussi >>> >>> >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Oct 30 01:34:08 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 30 Oct 2014 09:34:08 +0100 Subject: [Public WebGL] typed array convenience In-Reply-To: References: <1D168BC8-CF0B-4251-8E7C-05543E0ABE45@callow.im> Message-ID: On Thu, Oct 30, 2014 at 4:53 AM, Kenneth Russell wrote: > Keep in mind that when these types were subsumed into the ECMAScript spec, > the goal was to share as much behavior as possible with "ordinary" > ECMAScript arrays, so Florian, please think about how the new methods you > suggest could be specified to apply to both. > Started an es-discuss thread: https://mail.mozilla.org/pipermail/es-discuss/2014-October/040184.html Also updated the jsperf tests with one for asm.js, which is about 3x slower (even in firefox) than the handwrangled one at a time assign. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Fri Oct 31 01:14:01 2014 From: jda...@ (John Davis) Date: Fri, 31 Oct 2014 04:14:01 -0400 Subject: [Public WebGL] IE11 performance, nice Message-ID: Is there a webgl/IE11 icon we can use to redirect users to IE11? I'm not sure what kind of juice is getting put in there, my shaders now execute much better on IE11 than Chrome and Firefox. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Oct 31 01:24:30 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 31 Oct 2014 09:24:30 +0100 Subject: [Public WebGL] IE11 performance, nice In-Reply-To: References: Message-ID: On Fri, Oct 31, 2014 at 9:14 AM, John Davis wrote: > I'm not sure what kind of juice is getting put in there, my shaders now > execute much better on IE11 than Chrome and Firefox. > IE probably uses DX11. Afaik Angle (currently) still uses DX9. The DX9 HLSL compile process contains the Microsoft D3D compiler chain, which is very slow. It's fair to assume the DX11 compile process has been optimized. I remember Microsoft now also favors delivery of HLSL rather than intermediary bytecode. It's for this reason that games in the past often built their own compiler to intermediary bytecode, but starting with DX11 Microsoft requires that any intermediary bytecode is cryptographically signed by the D3D compiler, and so it's probably more important that it performs well in DX11. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Oct 31 09:58:48 2014 From: ben...@ (Ben Constable) Date: Fri, 31 Oct 2014 16:58:48 +0000 Subject: [Public WebGL] IE11 performance, nice In-Reply-To: References: Message-ID: John ? is this link what you want? http://windows.microsoft.com/en-us/internet-explorer/ie-11-worldwide-languages Florian is correct. IE11 uses D3D11 for everything. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Florian B?sch Sent: Friday, October 31, 2014 1:25 AM To: John Davis Cc: public webgl Subject: Re: [Public WebGL] IE11 performance, nice On Fri, Oct 31, 2014 at 9:14 AM, John Davis > wrote: I'm not sure what kind of juice is getting put in there, my shaders now execute much better on IE11 than Chrome and Firefox. IE probably uses DX11. Afaik Angle (currently) still uses DX9. The DX9 HLSL compile process contains the Microsoft D3D compiler chain, which is very slow. It's fair to assume the DX11 compile process has been optimized. I remember Microsoft now also favors delivery of HLSL rather than intermediary bytecode. It's for this reason that games in the past often built their own compiler to intermediary bytecode, but starting with DX11 Microsoft requires that any intermediary bytecode is cryptographically signed by the D3D compiler, and so it's probably more important that it performs well in DX11. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Fri Oct 31 10:46:26 2014 From: baj...@ (Brandon Jones) Date: Fri, 31 Oct 2014 17:46:26 +0000 Subject: [Public WebGL] IE11 performance, nice References: Message-ID: On Fri Oct 31 2014 at 1:25:02 AM Florian B?sch wrote: > > IE probably uses DX11. Afaik Angle (currently) still uses DX9. > Chrome may use D3D9 or D3D11, based on your hardware and driver. To see which one your system is using go to about:gpu and look at the value of GL_RENDERER. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Fri Oct 31 11:05:39 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Fri, 31 Oct 2014 20:05:39 +0200 Subject: [Public WebGL] IE11 performance, nice In-Reply-To: References: Message-ID: I am also seeing very good WebGL performance in IE11, which beats all competing browsers by a large margin in some apps we've been building. In Emscripten applications that are very CPU heavy, IE11 loses out because the JS engine can't keep up, and applications that are very GPU heavy, the performance is more or less identical across browsers, because GPU execution units are the same in hardware. The winning cases for IE11 seem to be in the middle, where both CPU and GPU workloads are closely balanced, which I attribute to two things: 1) IE11 has less CPU overhead in WebGL API calls compared to ANGLE-based Firefox and Chrome, and 2) IE11 has better frame/vsync scheduling and composition management. I suspect that both Firefox and Chrome suffer from per-frame sync points which cause pipeline bubbles in scheduling. If IE11 manages to step up their game in JS engine performance, they will have a killer web gaming browser in their hands! Jukks 2014-10-31 19:46 GMT+02:00 Brandon Jones : > On Fri Oct 31 2014 at 1:25:02 AM Florian B?sch wrote: >> >> IE probably uses DX11. Afaik Angle (currently) still uses DX9. >> > > Chrome may use D3D9 or D3D11, based on your hardware and driver. To see > which one your system is using go to about:gpu and look at the value of > GL_RENDERER. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kir...@ Fri Oct 31 11:12:42 2014 From: kir...@ (Kirill Prazdnikov) Date: Fri, 31 Oct 2014 21:12:42 +0300 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> Message-ID: <5453D11A.90104@jetbrains.com> On 28.10.2014 16:59, Floh wrote: > GL_MAX_VERTEX_UNIFORM_VECTORS: 128 This is REAL limit of iPad (2,3) GPU.. Unfortunately... 512 is software emulation. This makes HW skinning really difficult on iOS devices since it requires skin partitioning. Real life shows that desktop WebGL can handle 80 bones, while iOS only 40. -Kirill ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Oct 31 11:54:09 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 31 Oct 2014 19:54:09 +0100 Subject: [Public WebGL] retrograde webgl support levels In-Reply-To: <5453D11A.90104@jetbrains.com> References: <4A06FEDC-2FDE-4729-9640-E92842257ADC@callow.im> <5453D11A.90104@jetbrains.com> Message-ID: On Fri, Oct 31, 2014 at 7:12 PM, Kirill Prazdnikov < kirill.prazdnikov...@> wrote: > 512 is software emulation. This makes HW skinning really difficult on iOS > devices since it requires skin partitioning. > That's not the intent of the OpenGL API. The hardware limitations are supposed to represent hardware limitations, not some made up number that's supportable in software, unless you're running a software renderer entirely, which you clearly wouldn't, on mobiles. Don't you think it'd be kind of, like, important for iOS developers to know how many actually *real* vertex uniform vectors they can use? How'd you have them query that, since the actual API's lying to them? -------------- next part -------------- An HTML attachment was scrubbed... URL: