From jda...@ Wed Feb 1 04:47:04 2012 From: jda...@ (John Davis) Date: Wed, 1 Feb 2012 06:47:04 -0600 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: <532510956.45499.1323456205588.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <532510956.45499.1323456205588.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Has anyone gotten Firefox w/ webgl running on the Raspberry pi? On Friday, December 9, 2011, Benoit Jacob wrote: > I don't know any details. But in principle, assuming it will be the same software as the regular Firefox Mobile, it has the exact same WebGL implementation as the desktop version of Firefox. > > Benoit > > ________________________________ > > From what I understand, FireFox is in the approval process for Kindle Fire. Will it support the latest WebGL spec? > We need something like this to open the floodgates on mobile devices. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Feb 1 07:50:16 2012 From: bja...@ (Benoit Jacob) Date: Wed, 1 Feb 2012 07:50:16 -0800 (PST) Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: Message-ID: <341408946.112029.1328111416266.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> I don't know anything specific to the Raspberry Pi, but if it runs Android and has a OpenGL ES 2 driver, then the standard Firefox/Android build should work fine with WebGL . Benoit ----- Original Message ----- > Has anyone gotten Firefox w/ webgl running on the Raspberry pi? > On Friday, December 9, 2011, Benoit Jacob < bjacob...@ > > wrote: > > I don't know any details. But in principle, assuming it will be the > > same software as the regular Firefox Mobile, it has the exact same > > WebGL implementation as the desktop version of Firefox. > > > > Benoit > > > > ________________________________ > > > > From what I understand, FireFox is in the approval process for > > Kindle Fire. Will it support the latest WebGL spec? > > We need something like this to open the floodgates on mobile > > devices. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Feb 1 07:56:06 2012 From: jda...@ (John Davis) Date: Wed, 1 Feb 2012 09:56:06 -0600 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: <341408946.112029.1328111416266.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <341408946.112029.1328111416266.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: it runs arm/linux/oes 2.0, and has the potential to disrupt everything, it's OLPC done right On Wednesday, February 1, 2012, Benoit Jacob wrote: > I don't know anything specific to the Raspberry Pi, but if it runs Android and has a OpenGL ES 2 driver, then the standard Firefox/Android build should work fine with WebGL. > > Benoit > > > ________________________________ > > Has anyone gotten Firefox w/ webgl running on the Raspberry pi? > > On Friday, December 9, 2011, Benoit Jacob wrote: >> I don't know any details. But in principle, assuming it will be the same software as the regular Firefox Mobile, it has the exact same WebGL implementation as the desktop version of Firefox. >> >> Benoit >> >> ________________________________ >> >> From what I understand, FireFox is in the approval process for Kindle Fire. Will it support the latest WebGL spec? >> We need something like this to open the floodgates on mobile devices. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jat...@ Wed Feb 1 07:57:03 2012 From: jat...@ (John Tamplin) Date: Wed, 1 Feb 2012 10:57:03 -0500 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: <341408946.112029.1328111416266.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <341408946.112029.1328111416266.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Feb 1, 2012 at 10:50 AM, Benoit Jacob wrote: > I don't know anything specific to the Raspberry Pi, but if it runs Android > and has a OpenGL ES 2 driver, then the standard Firefox/Android build > should work fine with WebGL. > The Raspberry Pi is a cheap SBC running Linux, and is unlikely to run Android. However, it already supports OpenGL ES 2 and other than perhaps memory concerns I would expect normal desktop FF to work fine with it. http://www.raspberrypi.org/ -- John A. Tamplin Software Engineer (GWT), Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob...@ Wed Feb 1 08:05:01 2012 From: bob...@ (Robert Richter) Date: Wed, 1 Feb 2012 08:05:01 -0800 (PST) Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: Message-ID: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Indeed: http://en.wikipedia.org/wiki/Raspberry_Pi#Specifications CPU: 700 MHz ARM1176JZF-S core ( ARM11 family) [ 3 ] GPU: Broadcom VideoCore IV, [ 35 ] OpenGL ES 2.0, 1080p 30 h.264/MPEG-4 AVC high-profile decode [ 3 ] Memory (SDRAM): 128 MiB 256 MiB It already runs Arch/Debian linux. I assume it would run (slowly). ----- Original Message ----- From: "John Tamplin" To: "Benoit Jacob" Cc: jdavis...@, "public webgl" Sent: Wednesday, February 1, 2012 10:57:03 AM Subject: Re: [Public WebGL] Re: Android FireFox on Kindle Fire On Wed, Feb 1, 2012 at 10:50 AM, Benoit Jacob < bjacob...@ > wrote: I don't know anything specific to the Raspberry Pi, but if it runs Android and has a OpenGL ES 2 driver, then the standard Firefox/Android build should work fine with WebGL. The Raspberry Pi is a cheap SBC running Linux, and is unlikely to run Android. However, it already supports OpenGL ES 2 and other than perhaps memory concerns I would expect normal desktop FF to work fine with it. http://www.raspberrypi.org/ -- John A. Tamplin Software Engineer (GWT), Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon...@ Wed Feb 1 08:12:44 2012 From: jon...@ (Jon Buckley) Date: Wed, 1 Feb 2012 11:12:44 -0500 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1BADE86D-9817-4FCA-8030-DCEA625B9CA9@jbuckley.ca> We have a Raspberry Pi at Seneca College that the Fedora ARM team is currently using to get Fedora 14 running on it. I'll ask them if they've got a WebGL-capable version of Firefox or Chrome running on the device, and whether some WebGL demos work on it. Jon On 2012-02-01, at 11:05 AM, Robert Richter wrote: > Indeed: http://en.wikipedia.org/wiki/Raspberry_Pi#Specifications > > CPU: 700 MHz ARM1176JZF-S core (ARM11 family) [3] > GPU: Broadcom VideoCore IV,[35] OpenGL ES 2.0, 1080p30 h.264/MPEG-4 AVC high-profile decode [3] > Memory (SDRAM): 128 MiB 256 MiB > > It already runs Arch/Debian linux. I assume it would run (slowly). > > From: "John Tamplin" > To: "Benoit Jacob" > Cc: jdavis...@, "public webgl" > Sent: Wednesday, February 1, 2012 10:57:03 AM > Subject: Re: [Public WebGL] Re: Android FireFox on Kindle Fire > > On Wed, Feb 1, 2012 at 10:50 AM, Benoit Jacob wrote: > I don't know anything specific to the Raspberry Pi, but if it runs Android and has a OpenGL ES 2 driver, then the standard Firefox/Android build should work fine with WebGL. > > The Raspberry Pi is a cheap SBC running Linux, and is unlikely to run Android. However, it already supports OpenGL ES 2 and other than perhaps memory concerns I would expect normal desktop FF to work fine with it. > > http://www.raspberrypi.org/ > > -- > John A. Tamplin > Software Engineer (GWT), Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Feb 1 08:53:15 2012 From: bja...@ (Benoit Jacob) Date: Wed, 1 Feb 2012 08:53:15 -0800 (PST) Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: <1BADE86D-9817-4FCA-8030-DCEA625B9CA9@jbuckley.ca> Message-ID: <1315958380.164678.1328115195830.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Interesting. So it runs X11? In that case, the best starting point for a port of Firefox Mobile to it, would probably be to start from the Meego port (which is maintained to date and runs WebGL fine). Benoit ----- Original Message ----- > We have a Raspberry Pi at Seneca College that the Fedora ARM team is > currently using to get Fedora 14 running on it. I'll ask them if > they've got a WebGL-capable version of Firefox or Chrome running on > the device, and whether some WebGL demos work on it. > Jon > On 2012-02-01, at 11:05 AM, Robert Richter wrote: > > Indeed: http://en.wikipedia.org/wiki/Raspberry_Pi#Specifications > > > CPU: 700 MHz ARM1176JZF-S core ( ARM11 family) [3] > > > GPU: Broadcom VideoCore IV, [35] OpenGL ES 2.0, 1080p 30 > > h.264/MPEG-4 AVC high-profile decode [3] > > > Memory (SDRAM): 128 MiB 256 MiB > > > It already runs Arch/Debian linux. I assume it would run (slowly). > > > ----- Original Message ----- > > > From: "John Tamplin" < jat...@ > > > > To: "Benoit Jacob" < bjacob...@ > > > > Cc: jdavis...@ , "public webgl" < > > public_webgl...@ > > > > Sent: Wednesday, February 1, 2012 10:57:03 AM > > > Subject: Re: [Public WebGL] Re: Android FireFox on Kindle Fire > > > On Wed, Feb 1, 2012 at 10:50 AM, Benoit Jacob < bjacob...@ > > > > > wrote: > > > > I don't know anything specific to the Raspberry Pi, but if it > > > runs > > > Android and has a OpenGL ES 2 driver, then the standard > > > Firefox/Android build should work fine with WebGL. > > > > > The Raspberry Pi is a cheap SBC running Linux, and is unlikely to > > run > > Android. However, it already supports OpenGL ES 2 and other than > > perhaps memory concerns I would expect normal desktop FF to work > > fine with it. > > > http://www.raspberrypi.org/ > > > -- > > > John A. Tamplin > > > Software Engineer (GWT), Google > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Feb 1 08:56:31 2012 From: jda...@ (John Davis) Date: Wed, 1 Feb 2012 10:56:31 -0600 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: think open source apple tv for the planet w/ webgl, $25, airplay demo seems to indicate it's not slow, if only we could get google behind it ... :) On Wednesday, February 1, 2012, Robert Richter wrote: > Indeed: http://en.wikipedia.org/wiki/Raspberry_Pi#Specifications > CPU:700 MHz ARM1176JZF-S core (ARM11 family) [3] > GPU:Broadcom VideoCore IV,[35] OpenGL ES 2.0, 1080p30 h.264/MPEG-4 AVC high-profile decode [3] > Memory (SDRAM):128 MiB256 MiB > It already runs Arch/Debian linux. I assume it would run (slowly). > > ________________________________ > From: "John Tamplin" > To: "Benoit Jacob" > Cc: jdavis...@, "public webgl" > Sent: Wednesday, February 1, 2012 10:57:03 AM > Subject: Re: [Public WebGL] Re: Android FireFox on Kindle Fire > > On Wed, Feb 1, 2012 at 10:50 AM, Benoit Jacob wrote: >> >> I don't know anything specific to the Raspberry Pi, but if it runs Android and has a OpenGL ES 2 driver, then the standard Firefox/Android build should work fine with WebGL. > > The Raspberry Pi is a cheap SBC running Linux, and is unlikely to run Android. However, it already supports OpenGL ES 2 and other than perhaps memory concerns I would expect normal desktop FF to work fine with it. > http://www.raspberrypi.org/ > > -- > John A. Tamplin > Software Engineer (GWT), Google > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jat...@ Wed Feb 1 08:58:27 2012 From: jat...@ (John Tamplin) Date: Wed, 1 Feb 2012 11:58:27 -0500 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: References: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Feb 1, 2012 at 11:56 AM, John Davis wrote: > think open source apple tv for the planet w/ webgl, $25, airplay demo > seems to indicate it's not slow, if only we could get google behind it ... > :) And what would you want to get out of having Google behind it? -- John A. Tamplin Software Engineer (GWT), Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Feb 1 09:14:09 2012 From: jda...@ (John Davis) Date: Wed, 1 Feb 2012 11:14:09 -0600 Subject: [Public WebGL] Re: Android FireFox on Kindle Fire In-Reply-To: References: <146294224.122225.1328112301608.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: production/distribution scale, ie motorola On Wednesday, February 1, 2012, John Tamplin wrote: > On Wed, Feb 1, 2012 at 11:56 AM, John Davis wrote: >> >> think open source apple tv for the planet w/ webgl, $25, airplay demo seems to indicate it's not slow, if only we could get google behind it ... :) > > And what would you want to get out of having Google behind it? > -- > John A. Tamplin > Software Engineer (GWT), Google > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic...@ Wed Feb 1 12:25:24 2012 From: nic...@ (Nicolas Rannou) Date: Wed, 1 Feb 2012 15:25:24 -0500 Subject: [Public WebGL] Is depth peeling supported in WebGL Message-ID: Hello, I'm new to the webgl world and I was wondering if depth peeling is/will be supported in webgl? Which would be the best (performance/appearance) way to render transparent objects which are overlapping? Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Feb 1 12:35:49 2012 From: ben...@ (Ben Vanik) Date: Wed, 1 Feb 2012 12:35:49 -0800 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: Message-ID: Not without some modifications to the algorithm that would almost certainly be cost prohibitive. There is no support for multiple render targets and no MIN/MAX blending functions, so you'd need to not only double the number of passes but then do the blending of the results of each pass yourself in another shader. On Wed, Feb 1, 2012 at 12:25 PM, Nicolas Rannou wrote: > Hello, > > I'm new to the webgl world and I was wondering if depth peeling is/will be > supported in webgl? > > Which would be the best (performance/appearance) way to render transparent > objects which are overlapping? > > Thanks, > Nicolas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic...@ Wed Feb 1 12:59:50 2012 From: nic...@ (Nicolas Rannou) Date: Wed, 1 Feb 2012 15:59:50 -0500 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: Message-ID: Thanks for the quick answer! Would you have any suggestion about the best approach then? or is there any plan to integrate the "missing" features? On Wed, Feb 1, 2012 at 3:35 PM, Ben Vanik wrote: > Not without some modifications to the algorithm that would almost > certainly be cost prohibitive. There is no support for multiple render > targets and no MIN/MAX blending functions, so you'd need to not only double > the number of passes but then do the blending of the results of each pass > yourself in another shader. > > > On Wed, Feb 1, 2012 at 12:25 PM, Nicolas Rannou wrote: > >> Hello, >> >> I'm new to the webgl world and I was wondering if depth peeling is/will >> be supported in webgl? >> >> Which would be the best (performance/appearance) way to render >> transparent objects which are overlapping? >> >> Thanks, >> Nicolas >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 1 13:10:57 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Feb 2012 22:10:57 +0100 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: Message-ID: On Wed, Feb 1, 2012 at 9:59 PM, Nicolas Rannou wrote: > Would you have any suggestion about the best approach then? 1) Render the scenes color to a texture 3) Render the scenes depth to a texture 5) Render the scene color comparing against the texture from step #3 and discard the fragment when it closely approaches the read depth 6) Render the scenes depth comparing against the texture from step #3 and discard the fragment when it closely approaches the read depth 7) Replace reference to depth texture from step #3 with depth texture from step #6 8) goto step 5 until desired amount of peels are filled 9) compose the resultant color buffers back to front You will have 2 renders of the scene per peel + one compositing step at the end. > or is there any plan to integrate the "missing" features? WebGL is defined by Khronos to be OpenGL ES 2.0 compatible. OpenGL ES 2.0 does not have functionality for multiple render targets (nor does it have an extension for it). ----------------------------------------------------------- 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 gma...@ Wed Feb 1 13:17:13 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Wed, 1 Feb 2012 13:17:13 -0800 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: Message-ID: On Wed, Feb 1, 2012 at 1:10 PM, Florian B?sch wrote: > > On Wed, Feb 1, 2012 at 9:59 PM, Nicolas Rannou > wrote: > > Would you have any suggestion about the best approach then? > > 1) Render the scenes color to a texture > 3) Render the scenes depth to a texture > 5) Render the scene color comparing against the texture from step #3 > and discard the fragment when it closely approaches the read depth > 6) Render the scenes depth comparing against the texture from step #3 > and discard the fragment when it closely approaches the read depth > 7) Replace reference to depth texture from step #3 with depth texture > from step #6 > 8) goto step 5 until desired amount of peels are filled > 9) compose the resultant color buffers back to front > > You will have 2 renders of the scene per peel + one compositing step at > the end. > > > or is there any plan to integrate the "missing" features? > WebGL is defined by Khronos to be OpenGL ES 2.0 compatible. OpenGL ES > 2.0 does not have functionality for multiple render targets (nor does > it have an extension for it). > > http://www.khronos.org/registry/gles/extensions/NV/GL_NV_fbo_color_attachments.txt > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 1 13:18:35 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Feb 2012 22:18:35 +0100 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: Message-ID: On Wed, Feb 1, 2012 at 10:10 PM, Florian B?sch wrote: > You will have 2 renders of the scene per peel + one compositing step at the end. If we had depth textures for fbos we could solve that with one pass per peel. Which is why I proposed this extension: http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Feb 1 13:20:25 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Feb 2012 22:20:25 +0100 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: Message-ID: On Wed, Feb 1, 2012 at 10:17 PM, Gregg Tavares (?) wrote: > http://www.khronos.org/registry/gles/extensions/NV/GL_NV_fbo_color_attachments.txt Unfortunately this is a vendor specific extension and there is no canonical vendor unspecific one. I did propose adding one to OpenGL ES 2.0 in this thread: http://www.khronos.org/message_boards/viewtopic.php?f=9&t=4699 ----------------------------------------------------------- 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...@ Wed Feb 1 13:23:16 2012 From: bja...@ (Benoit Jacob) Date: Wed, 1 Feb 2012 13:23:16 -0800 (PST) Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: Message-ID: <2051044504.519527.1328131396788.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > > On Wed, Feb 1, 2012 at 10:10 PM, Florian B?sch > wrote: > > You will have 2 renders of the scene per peel + one compositing > > step at the end. > If we had depth textures for fbos we could solve that with one pass > per peel. Which is why I proposed this extension: > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ I just saw this in this document: "Written against the WebGL API 2.0 specification." Did you mean 1.0.1? Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Feb 1 13:28:59 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 1 Feb 2012 22:28:59 +0100 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: <2051044504.519527.1328131396788.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <2051044504.519527.1328131396788.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Wed, Feb 1, 2012 at 10:23 PM, Benoit Jacob wrote: > I just saw this in this document: > "Written against the WebGL API 2.0 specification." http://www.khronos.org/registry/gles/extensions/OES/OES_depth_texture.txt is written against 2.0 http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ is based on the OES extension, so it is either written against OpenGL ES 2.0 or against WebGL 1.0 (I'm not clear on what convention we use there) http://www.khronos.org/registry/gles/extensions/NV/GL_NV_fbo_color_attachments.txt is written against 2.0 http://www.khronos.org/message_boards/viewtopic.php?f=9&t=4699 is based on the NV extension so it should be written against OpenGL ES 2.0 ----------------------------------------------------------- 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 con...@ Wed Feb 1 18:37:03 2012 From: con...@ (Conor Dickinson) Date: Wed, 1 Feb 2012 18:37:03 -0800 Subject: [Public WebGL] EXT_sRGB Message-ID: Are there any plans to add support for the EXT_sRGB extension to WebGL any time soon? Aside from depth textures, anisotropic filtering, and texture compression (all which I am overjoyed to see being worked on), this is the one extension that is currently holding me back from making a top-quality renderer. I am currently doing sRGB conversion manually into and out of my shaders, but this is inefficient on hardware that supports the extension and it does not handle frame buffer blending correctly. http://www.khronos.org/registry/gles/extensions/EXT/EXT_sRGB.txt Thanks! Conor Dickinson railGun 3D -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Feb 2 01:56:30 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 2 Feb 2012 10:56:30 +0100 Subject: [Public WebGL] EXT_sRGB In-Reply-To: References: Message-ID: On Thu, Feb 2, 2012 at 3:37 AM, Conor Dickinson wrote: > Are there any plans to add support for the EXT_sRGB extension to WebGL any > time soon? This extension has not yet been ratified by the OpenGL ES WG. I've quickly went over the support for the extension by devices, which yielded zero (no device supports this extension yet). It is unlikely this would move forward at the current time in WebGL. > this is the > one extension that is currently holding me back from making a top-quality > renderer. ?I am currently doing sRGB conversion manually into and out of my > shaders, but this is inefficient on hardware that supports the extension and > it does not handle frame buffer blending correctly. You do not have to use sRGB to produce a high quality renderer. There are two items you should consider: Firstly you should consider the importance of being linear (also referred to here: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html ) 1) at entry to your application any color input should be converted to linear space 2) Therefore all calculations subsequently done will be correct, because they happen in linear space 3) Before outputting your result to the screen you convert it to gamma space again. Secondly, it is beneficial (and sometimes required) to be able to express more color graduations and wider values than afforded by byte textures. WebGL does support floating point textures. ----------------------------------------------------------- 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 tu...@ Thu Feb 2 07:56:17 2012 From: tu...@ (Thatcher Ulrich) Date: Thu, 2 Feb 2012 10:56:17 -0500 Subject: [Public WebGL] EXT_sRGB In-Reply-To: References: Message-ID: On Thu, Feb 2, 2012 at 4:56 AM, Florian B?sch wrote: > > On Thu, Feb 2, 2012 at 3:37 AM, Conor Dickinson wrote: >> Are there any plans to add support for the EXT_sRGB extension to WebGL any >> time soon? > This extension has not yet been ratified by the OpenGL ES WG. I've > quickly went over the support for the extension by devices, which > yielded zero (no device supports this extension yet). It is unlikely > this would move forward at the current time in WebGL. > >> this is the >> one extension that is currently holding me back from making a top-quality >> renderer. ?I am currently doing sRGB conversion manually into and out of my >> shaders, but this is inefficient on hardware that supports the extension and >> it does not handle frame buffer blending correctly. > You do not have to use sRGB to produce a high quality renderer. There > are two items you should consider: > > Firstly you should consider the importance of being linear (also > referred to here: > http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html ) > 1) at entry to your application any color input should be converted to > linear space FYI the sRGB extensions are preferred, to avoid banding. Quoting from that doc: "Appropriate sRGB formats are defined for all 8-bit texture formats (RGB, RGBA, luminance, luminance alpha, and DXT compressed), both in OpenGL and in DirectX. Passing GL_SRGB_EXT instead of GL_RGB to glTexImage2D, for example, ensures that any shader accesses to the specified texture return linear pixel values. The automatic sRGB corrections are free and are preferred to performing the corrections manually in a shader after each texture access, as shown in Listing 24-1, because each pow instruction is scalar and expanded to two instructions. Also, manual correction happens after filtering, which is incorrectly performed in a nonlinear space. The sRGB formats may also be preferred to preconverting textures to linear versions before they are loaded. Storing linear pixels back into an 8-bit image is effectively a loss of precision in low light levels and can cause banding when the pixels are converted back to monitor space or used in further shading." -T > 2) Therefore all calculations subsequently done will be correct, > because they happen in linear space > 3) Before outputting your result to the screen you convert it to gamma > space again. > > Secondly, it is beneficial (and sometimes required) to be able to > express more color graduations and wider values than afforded by byte > textures. WebGL does support floating point textures. > > ----------------------------------------------------------- > 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 Feb 2 08:15:28 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 2 Feb 2012 17:15:28 +0100 Subject: [Public WebGL] EXT_sRGB In-Reply-To: References: Message-ID: On Thu, Feb 2, 2012 at 4:56 PM, Thatcher Ulrich wrote: > FYI the sRGB extensions are preferred, to avoid banding. Assuming you want to squeeze your stuff into byte textures, sure sRGB would be better but: - sRGB is not yet supported by any mobile device whatsoever - sRGB is supported by about 45% of PCs. The performance impact of converting between colorspaces yourself is negligible. The precision (and respective loss of) is not negligible, but your mileage in manual conversion may vary, and in some cases linear bytes as transport format would probably be better. A particular use-case of high-quality physical based renderers is HDR computations (tone mapping, bloom blurs etc.), which is where neither linear byte values nor sRGB will be of any practical use (without massive banding). That is because you need to store HDR values which can have magnitudes of channels 50x brighter than 1, and many times fainter than 1/255th. In these cases you will have no other choice than to use floating point textures. When comparing sRGB back/forth conversions between linear and gamma versus actually using linear space 32-bit floats, floats win hands down in quality as well. Floating point texture support is present on: - 321 mobile devices - 65% of PCs ----------------------------------------------------------- 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 con...@ Thu Feb 2 13:29:15 2012 From: con...@ (Conor Dickinson) Date: Thu, 2 Feb 2012 13:29:15 -0800 Subject: [Public WebGL] EXT_sRGB In-Reply-To: References: Message-ID: I realized from your responses that I was not very clear in my original email about what I am working on. I am currently developing a top quality WebGL game renderer aimed to deliver nearly cutting edge graphics. Because it is for a game it also needs to be *fast*, hence I am using techniques developed for and used by triple-A console and PC titles. 1. Floating point textures and framebuffers are unacceptable from a performance standpoint; the framebuffer read/write speed is atrocious and floating point textures dramatically increase the rate of texture cache misses, especially compared to DXT compressed sRGB textures. 2. sRGB acts as a perceptual based compression scheme, it is the only way that color values are acceptable in byte textures. Linear values stored in bytes have way too much banding, especially compressed. http://altdevblogaday.com/2011/06/02/yet-another-post-about-gamma-correction/ 3. The performance impact of manual conversion from sRGB textures and back to sRGB framebuffer in the shaders is not negligible, that is 3 pow instructions per texture and 3 pow instructions at the end. And, as Thatcher mentioned, there is no way to manually to sRGB expansion before texture filtering or during alpha blending. I am currently doing the manual conversion and it definitely does not look as good or run as well as using the hardware support in OpenGL or DirectX. 4. Even when making an HDR renderer, LDR sRGB textures are still useful for storing pretty much all surface properties aside from lightmaps. 5. I am not targeting mobile devices, and while I understand the goal of keeping the WebGL core spec in line with mobile capabilities, sRGB is an *extension *and therefore it is acceptable to not be supported everywhere. The performance characteristics of mobile GPUs is such that I would want a different rendering path for those devices anyway. On the desktop computers without sRGB support I am fine with having a fallback path in my shaders, those devices will not support all the fancy rendering effects so I don't care about visual quality as much in that case. Conor Dickinson railGun 3D On Thu, Feb 2, 2012 at 8:15 AM, Florian B?sch wrote: > On Thu, Feb 2, 2012 at 4:56 PM, Thatcher Ulrich wrote: > > FYI the sRGB extensions are preferred, to avoid banding. > Assuming you want to squeeze your stuff into byte textures, sure sRGB > would be better but: > - sRGB is not yet supported by any mobile device whatsoever > - sRGB is supported by about 45% of PCs. > > The performance impact of converting between colorspaces yourself is > negligible. The precision (and respective loss of) is not negligible, > but your mileage in manual conversion may vary, and in some cases > linear bytes as transport format would probably be better. > > A particular use-case of high-quality physical based renderers is HDR > computations (tone mapping, bloom blurs etc.), which is where neither > linear byte values nor sRGB will be of any practical use (without > massive banding). That is because you need to store HDR values which > can have magnitudes of channels 50x brighter than 1, and many times > fainter than 1/255th. In these cases you will have no other choice > than to use floating point textures. > > When comparing sRGB back/forth conversions between linear and gamma > versus actually using linear space 32-bit floats, floats win hands > down in quality as well. > > Floating point texture support is present on: > - 321 mobile devices > - 65% of PCs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Feb 6 17:07:48 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 6 Feb 2012 17:07:48 -0800 Subject: [Public WebGL] Is depth peeling supported in WebGL In-Reply-To: References: <2051044504.519527.1328131396788.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: The convention in the WebGL extensions is that they reference a particular version of the WebGL API, which in turn references a particular version of the OpenGL ES API. I've fixed up the WEBGL_depth_texture proposal to reference API version 1.0. -Ken On Wed, Feb 1, 2012 at 1:28 PM, Florian B?sch wrote: > > On Wed, Feb 1, 2012 at 10:23 PM, Benoit Jacob wrote: >> I just saw this in this document: >> "Written against the WebGL API 2.0 specification." > http://www.khronos.org/registry/gles/extensions/OES/OES_depth_texture.txt > is written against 2.0 > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > is based on the OES extension, so it is either written against OpenGL > ES 2.0 or against WebGL 1.0 (I'm not clear on what convention we use > there) > > http://www.khronos.org/registry/gles/extensions/NV/GL_NV_fbo_color_attachments.txt > is written against 2.0 > http://www.khronos.org/message_boards/viewtopic.php?f=9&t=4699 is > based on the NV extension so it should be written against OpenGL ES > 2.0 > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Feb 6 17:26:54 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 6 Feb 2012 17:26:54 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: Florian, thanks for writing this up and for doing the research on how widespread support is. Clarified the return value of getParameter(MAX_TEXTURE_MAX_ANISOTROPY) and committed as a proposal. See https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/EXT_texture_filter_anisotropic/index.html and shortly http://www.khronos.org/registry/webgl/extensions/proposals/EXT_texture_filter_anisotropic/ . -Ken On Fri, Jan 27, 2012 at 10:47 AM, Ben Vanik wrote: > Excited about this. > One of the nice things about this as an extension (vs. some of the others) > is that it's fine to run without it as it's mainly just a quality > enhancement. This means that the devices that don't support it won't end up > being unable to run apps/games written with it unless the developer is > careless. > > > On Fri, Jan 27, 2012 at 10:28 AM, Florian B?sch wrote: >> >> I'm proposing to add the extension EXT_texture_filter_anisotropic [1]. >> It mirrors the OpenGL ES extension [2] and the OpenGL extension [3] >> >> Support: >> Mobiles -- According to glbenchmarks [4], 224 out of 387 devices (58%) >> support this extension see the full list [5], support for this >> extension is ranked at position 16 out of 152 extensions [6] >> Desktops -- According to wilfiregrames 96% of users have support for >> this extension [7], According to steam surveys 99% of users have DX 9 >> level hardware ?which should support it [8] >> APIs -- Direct3D 9 has support for the feature [9]. OpenGL [3] and >> OpenGL ES [2] support is via extension. >> >> [1] attachment: ext_texture_filter_anisotropic.tar.bz2, preview: >> >> http://codeflow.org/webgl/registry/extensions/proposals/EXT_texture_filter_anisotropic/ >> [2] >> http://www.khronos.org/registry/gles/extensions/EXT/texture_filter_anisotropic.txt >> [3] >> http://www.opengl.org/registry/specs/EXT/texture_filter_anisotropic.txt >> [4] http://www.glbenchmark.com/ >> [5] attachment: mobile_support_texture_filter_anisotropic.txt, >> >> http://codeflow.org/webgl/registry/extensions/proposals/EXT_texture_filter_anisotropic/mobile_support_texture_filter_anisotropic.txt >> [6] attachment: ranking.txt, >> >> http://codeflow.org/webgl/registry/extensions/proposals/EXT_texture_filter_anisotropic/ranking.txt >> [7] >> http://feedback.wildfiregames.com/report/opengl/feature/GL_EXT_texture_filter_anisotropic >> [8] http://store.steampowered.com/hwsurvey/videocard/ >> [9] >> http://msdn.microsoft.com/en-us/library/windows/desktop/bb172264(v=vs.85).aspx > > ----------------------------------------------------------- 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...@ Wed Feb 8 05:47:07 2012 From: jda...@ (John Davis) Date: Wed, 8 Feb 2012 07:47:07 -0600 Subject: [Public WebGL] chrome mobile Message-ID: Tavares, Any webgl love coming with chrome for ics? JD -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Feb 8 09:48:22 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Wed, 8 Feb 2012 09:48:22 -0800 Subject: [Public WebGL] chrome mobile In-Reply-To: References: Message-ID: On Wed, Feb 8, 2012 at 5:47 AM, John Davis wrote: > Tavares, > > Any webgl love coming with chrome for ics? > I plead the 5th http://code.google.com/chrome/mobile/docs/faq.html > > JD > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Wed Feb 8 10:58:09 2012 From: cma...@ (Chris Marrin) Date: Wed, 08 Feb 2012 10:58:09 -0800 Subject: [Public WebGL] chrome mobile In-Reply-To: References: Message-ID: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> On Feb 8, 2012, at 9:48 AM, Gregg Tavares (?) wrote: > > > On Wed, Feb 8, 2012 at 5:47 AM, John Davis wrote: > Tavares, > > Any webgl love coming with chrome for ics? > > I plead the 5th > > http://code.google.com/chrome/mobile/docs/faq.html Wow, how Apple of you :-) ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 8 11:01:26 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 8 Feb 2012 20:01:26 +0100 Subject: [Public WebGL] chrome mobile In-Reply-To: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: o_O *sigh* Btw. slightly related, I hear the PS3's now using webkit. Can I say Sony please nice enough? That'd totally rock ^^ ----------------------------------------------------------- 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 nic...@ Wed Feb 8 11:39:35 2012 From: nic...@ (Nicolas Kassis) Date: Wed, 8 Feb 2012 14:39:35 -0500 Subject: [Public WebGL] chrome mobile In-Reply-To: References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: Doesn't the PS3 already have an implementation of OpenGL 2.0 on it? WebGL for the PS3 could be really interesting. NIc On Wed, Feb 8, 2012 at 2:01 PM, Florian B?sch wrote: > > o_O *sigh* > > Btw. slightly related, I hear the PS3's now using webkit. Can I say > Sony please nice enough? That'd totally rock ^^ > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > -- ----------------- Nicolas Kassis ----------------------------------------------------------- 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 nic...@ Wed Feb 8 11:46:11 2012 From: nic...@ (Nicolas Kassis) Date: Wed, 8 Feb 2012 14:46:11 -0500 Subject: [Public WebGL] chrome mobile In-Reply-To: References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: I meant OpenGL ES 2.0, sorry if that wasn't clear. On Wed, Feb 8, 2012 at 2:39 PM, Nicolas Kassis wrote: > Doesn't the PS3 already have an implementation of OpenGL 2.0 on it? > WebGL for the PS3 could be really interesting. > > NIc > > On Wed, Feb 8, 2012 at 2:01 PM, Florian B?sch wrote: >> >> o_O *sigh* >> >> Btw. slightly related, I hear the PS3's now using webkit. Can I say >> Sony please nice enough? That'd totally rock ^^ >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> > > > > -- > ----------------- > Nicolas Kassis -- ----------------- Nicolas Kassis ----------------------------------------------------------- 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 hic...@ Wed Feb 8 12:31:26 2012 From: hic...@ (rix) Date: Wed, 8 Feb 2012 21:31:26 +0100 Subject: [Public WebGL] chrome mobile In-Reply-To: References: Message-ID: Sony released as open source their implementation of WebGL in android web browser http://www.androidauthority.com/sony-ericsson-releases-webgl-implementation-for-android-4-0-as-open-source-48038/ On Wed, Feb 8, 2012 at 2:47 PM, John Davis wrote: > Tavares, > > Any webgl love coming with chrome for ics? > > JD > -- Riccardo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Feb 8 13:24:48 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Wed, 8 Feb 2012 13:24:48 -0800 Subject: [Public WebGL] chrome mobile In-Reply-To: References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: PS3 would have an extremely hard time running JavaScript efficiently with it's poor cache. I suppose GLSL sandbox would have no problem but not a whole lot else. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Wed Feb 8 15:16:38 2012 From: kos...@ (David Sheets) Date: Wed, 8 Feb 2012 15:16:38 -0800 Subject: [Public WebGL] chrome mobile In-Reply-To: References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: On Wed, Feb 8, 2012 at 1:24 PM, Gregg Tavares (?) wrote: > PS3 would have an extremely hard time running JavaScript efficiently with > it's poor cache. Have you played with a JavaScript implementation on the PS3? Has Sony released one? Do you have special access to one? > I suppose GLSL sandbox would have no problem but not a whole lot else. If you haven't used an implementation and no one else has either, how can we know? My iPhone 3gs also seems to be theoretically capable but totally locked down and without implementation. So much for ownership of my own devices... David ----------------------------------------------------------- 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 gma...@ Wed Feb 8 15:26:02 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Wed, 8 Feb 2012 15:26:02 -0800 Subject: [Public WebGL] chrome mobile In-Reply-To: References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: On Wed, Feb 8, 2012 at 3:16 PM, David Sheets wrote: > On Wed, Feb 8, 2012 at 1:24 PM, Gregg Tavares (?) wrote: > > PS3 would have an extremely hard time running JavaScript efficiently with > > it's poor cache. > > Have you played with a JavaScript implementation on the PS3? Has Sony > released one? Do you have special access to one? > No I haven't. But I have programmed 2 shipping PS3 games and I know that any indirection massively kills perf on PS3. PCs do okay at this. PowerPCs, at least the one on the PS3, don't. JavaScript is the king of indirection hence you're unlikely to get any significant speed out of it on a PS3. GLSL sandbox needs no JS speed because it's doing almost nothing but most WebGL apps need to do significant work in JS (matrix multiplies, draw calls, etc...). On top of that, PS3 doesn't have a runtime GLSL compiler. You're required to compile offline. (though I suppose they could add one) All I'm saying is I wouldn't get your hopes up for WebGL on PS3 either happening or being all that amazing. > > I suppose GLSL sandbox would have no problem but not a whole lot else. > > If you haven't used an implementation and no one else has either, how > can we know? > > My iPhone 3gs also seems to be theoretically capable but totally > locked down and without implementation. So much for ownership of my > own devices... > > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Wed Feb 8 15:49:41 2012 From: kos...@ (David Sheets) Date: Wed, 8 Feb 2012 15:49:41 -0800 Subject: [Public WebGL] chrome mobile In-Reply-To: References: <7915E785-ABFD-45C2-B4E4-1068E04BD4E8@apple.com> Message-ID: On Wed, Feb 8, 2012 at 3:26 PM, Gregg Tavares (?) wrote: > > > On Wed, Feb 8, 2012 at 3:16 PM, David Sheets wrote: >> >> On Wed, Feb 8, 2012 at 1:24 PM, Gregg Tavares (?) wrote: >> > PS3 would have an extremely hard time running JavaScript efficiently >> > with >> > it's poor cache. >> >> Have you played with a JavaScript implementation on the PS3? Has Sony >> released one? Do you have special access to one? > > > No I haven't. But I have programmed 2 shipping PS3 games and I know that any > indirection massively kills perf on PS3. PCs do okay at this. PowerPCs, at > least the one on the PS3, don't. JavaScript is the king of indirection hence > you're unlikely to get any significant speed out of it on a PS3. ?GLSL > sandbox needs no JS speed because it's doing almost nothing but most WebGL > apps need to do significant work in JS (matrix multiplies, draw calls, > etc...). Sounds like a cell phone that plugs into the wall and my TV. Don't modern JS JITs optimize away indirection for well-typed code using static structures? Did your games have scripting? Did you generate native code from scripts before shipping? > On top of that, PS3 doesn't have a runtime GLSL compiler. You're required to > compile offline. (though I suppose they could add one) They would have to add one to support WebGL as shaders are transported as source. I assume the PS3 is functional enough to run a compiler? > All I'm saying is I wouldn't get your hopes up for WebGL on PS3 either > happening or being all that amazing. The quality of WebGL on PS3 appears to be a function of the development effort (or lack thereof thanks to its totally closed nature). Do you think WebGL on the PS3 would be more or less performant than Firefox Mobile Beta on a Tegra2? Which platform has a vendor that is trying? Which platform has a vendor that accepts bug reports and patches? ----------------------------------------------------------- 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...@ Fri Feb 10 10:53:42 2012 From: jda...@ (John Davis) Date: Fri, 10 Feb 2012 12:53:42 -0600 Subject: [Public WebGL] chrome18 Message-ID: is there a flag to force swiftshader-webgl rendering? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 10 11:01:30 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 10 Feb 2012 20:01:30 +0100 Subject: [Public WebGL] chrome18 In-Reply-To: References: Message-ID: As far as I know there is no such flag. I'm also under the impression that WebGL can only target OpenGL and Direct3D. Although I'd really like the idea of having a good software renderer. On Fri, Feb 10, 2012 at 7:53 PM, John Davis wrote: > is there a flag to force swiftshader-webgl rendering? ----------------------------------------------------------- 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...@ Fri Feb 10 11:07:34 2012 From: jda...@ (John Davis) Date: Fri, 10 Feb 2012 13:07:34 -0600 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: thanks to tavares we now have a third, this is HUGE! just need a dev switch for testing. On Friday, February 10, 2012, Florian B?sch wrote: > As far as I know there is no such flag. I'm also under the impression > that WebGL can only target OpenGL and Direct3D. Although I'd really > like the idea of having a good software renderer. > > On Fri, Feb 10, 2012 at 7:53 PM, John Davis wrote: >> is there a flag to force swiftshader-webgl rendering? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reh...@ Fri Feb 10 11:24:01 2012 From: reh...@ (Rehno Lindeque) Date: Fri, 10 Feb 2012 11:24:01 -0800 Subject: [Public WebGL] Conformance test for GLSL: Side-effects in the ternary if operator (used in combination with the comma (sequence) operator) Message-ID: Hi all, Following a lively discussion at the San Francisco WebGL meetup last night, someone suggested that we should submit bugs in GLSL so they could be added to the WebGL conformance tests. I agree that getting consistent glsl support across all devices/drivers would be pretty helpful. This is a bug that I've found in ANGLE on windows machines running Google Chrome 16.0.912.77 m. float a = ... float b = ... float r0 = ... float r1 = ... float r = ... float ab = a > b? (r = r0, a) : (r = r1, b); return r; On my usual (linux) machine this runs only one of the two side-effects (r = r0) or (r = r1) as you'd expect, but on ANGLE I believe it probably runs both. I didn't submit this before because I haven't had time to write up a decent test, however if someone would be willing to add it I'd be grateful. I guess I could probably be convinced to generate a shader that fails at this if you really need it. Thank you, Rehno -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Feb 10 12:02:29 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Fri, 10 Feb 2012 12:02:29 -0800 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: On Fri, Feb 10, 2012 at 11:07 AM, John Davis wrote: > thanks to tavares we now have a third, this is HUGE! just need a dev > switch for testing. don't thank me. Thank John Bauman (google) and the guys at TransGaming that write SwiftShader (and ANGLE) I haven't tried this but looking at the code maybe --use-gl=swiftshader > > > On Friday, February 10, 2012, Florian B?sch wrote: > > As far as I know there is no such flag. I'm also under the impression > > that WebGL can only target OpenGL and Direct3D. Although I'd really > > like the idea of having a good software renderer. > > > > On Fri, Feb 10, 2012 at 7:53 PM, John Davis > wrote: > >> is there a flag to force swiftshader-webgl rendering? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan...@ Fri Feb 10 12:22:36 2012 From: dan...@ (Daniel Koch) Date: Fri, 10 Feb 2012 15:22:36 -0500 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: The following blog post tells you how to test it out: http://blog.chromium.org/2012/02/gpu-accelerating-2d-canvas-and-enabling.html /Daniel/ On 2012-02-10, at 3:02 PM, Gregg Tavares (?) wrote: > > > On Fri, Feb 10, 2012 at 11:07 AM, John Davis wrote: > thanks to tavares we now have a third, this is HUGE! just need a dev switch for testing. > > don't thank me. Thank John Bauman (google) and the guys at TransGaming that write SwiftShader (and ANGLE) > > I haven't tried this but looking at the code maybe > > --use-gl=swiftshader > > > > > > > On Friday, February 10, 2012, Florian B?sch wrote: > > As far as I know there is no such flag. I'm also under the impression > > that WebGL can only target OpenGL and Direct3D. Although I'd really > > like the idea of having a good software renderer. > > > > On Fri, Feb 10, 2012 at 7:53 PM, John Davis wrote: > >> is there a flag to force swiftshader-webgl rendering? > > > > > --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From van...@ Fri Feb 10 12:27:59 2012 From: van...@ (Vangelis Kokkevis) Date: Fri, 10 Feb 2012 12:27:59 -0800 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: The flag you need to run chrome with is --blacklist-webgl . The first time you'll have to wait a bit for the SwiftShader download to kick in (may take 5-10 minutes). Vangelis On Fri, Feb 10, 2012 at 12:02 PM, Gregg Tavares (?) wrote: > > a > On Fri, Feb 10, 2012 at 11:07 AM, John Davis wrote: > >> thanks to tavares we now have a third, this is HUGE! just need a dev >> switch for testing. > > > don't thank me. Thank John Bauman (google) and the guys at TransGaming > that write SwiftShader (and ANGLE) > > I haven't tried this but looking at the code maybe > > --use-gl=swiftshader > > > > > >> >> >> On Friday, February 10, 2012, Florian B?sch wrote: >> > As far as I know there is no such flag. I'm also under the impression >> > that WebGL can only target OpenGL and Direct3D. Although I'd really >> > like the idea of having a good software renderer. >> > >> > On Fri, Feb 10, 2012 at 7:53 PM, John Davis >> wrote: >> >> is there a flag to force swiftshader-webgl rendering? >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Fri Feb 10 12:39:35 2012 From: jda...@ (John Davis) Date: Fri, 10 Feb 2012 14:39:35 -0600 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: thanks John Bauman! On Friday, February 10, 2012, Gregg Tavares (?) wrote: > > > On Fri, Feb 10, 2012 at 11:07 AM, John Davis wrote: >> >> thanks to tavares we now have a third, this is HUGE! just need a dev switch for testing. > > don't thank me. Thank John Bauman (google) and the guys at TransGaming that write SwiftShader (and ANGLE) > I haven't tried this but looking at the code maybe > --use-gl=swiftshader > > > >> >> On Friday, February 10, 2012, Florian B?sch wrote: >> > As far as I know there is no such flag. I'm also under the impression >> > that WebGL can only target OpenGL and Direct3D. Although I'd really >> > like the idea of having a good software renderer. >> > >> > On Fri, Feb 10, 2012 at 7:53 PM, John Davis wrote: >> >> is there a flag to force swiftshader-webgl rendering? >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Fri Feb 10 12:43:55 2012 From: jda...@ (John Davis) Date: Fri, 10 Feb 2012 14:43:55 -0600 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: eta for linux? On Friday, February 10, 2012, Daniel Koch wrote: > The following blog post tells you how to test it out: > http://blog.chromium.org/2012/02/gpu-accelerating-2d-canvas-and-enabling.html > /Daniel/ > On 2012-02-10, at 3:02 PM, Gregg Tavares (?) wrote: > > > On Fri, Feb 10, 2012 at 11:07 AM, John Davis wrote: >> >> thanks to tavares we now have a third, this is HUGE! just need a dev switch for testing. > > don't thank me. Thank John Bauman (google) and the guys at TransGaming that write SwiftShader (and ANGLE) > I haven't tried this but looking at the code maybe > --use-gl=swiftshader > > > >> >> On Friday, February 10, 2012, Florian B?sch wrote: >> > As far as I know there is no such flag. I'm also under the impression >> > that WebGL can only target OpenGL and Direct3D. Although I'd really >> > like the idea of having a good software renderer. >> > >> > On Fri, Feb 10, 2012 at 7:53 PM, John Davis wrote: >> >> is there a flag to force swiftshader-webgl rendering? >> > >> > > > --- > Daniel Koch -+- daniel...@ > Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan...@ Fri Feb 10 12:47:30 2012 From: dan...@ (Daniel Koch) Date: Fri, 10 Feb 2012 15:47:30 -0500 Subject: [Public WebGL] Re: chrome18 In-Reply-To: References: Message-ID: <6F6036BF-B907-4476-9738-29E0DB4E0165@transgaming.com> No. (if there is one it's not my place to give it, nor is this the forum.) On 2012-02-10, at 3:43 PM, John Davis wrote: > eta for linux? > > On Friday, February 10, 2012, Daniel Koch wrote: > > The following blog post tells you how to test it out: > > http://blog.chromium.org/2012/02/gpu-accelerating-2d-canvas-and-enabling.html > > /Daniel/ > > On 2012-02-10, at 3:02 PM, Gregg Tavares (?) wrote: > > > > > > On Fri, Feb 10, 2012 at 11:07 AM, John Davis wrote: > >> > >> thanks to tavares we now have a third, this is HUGE! just need a dev switch for testing. > > > > don't thank me. Thank John Bauman (google) and the guys at TransGaming that write SwiftShader (and ANGLE) > > I haven't tried this but looking at the code maybe > > --use-gl=swiftshader > > > > > > > >> > >> On Friday, February 10, 2012, Florian B?sch wrote: > >> > As far as I know there is no such flag. I'm also under the impression > >> > that WebGL can only target OpenGL and Direct3D. Although I'd really > >> > like the idea of having a good software renderer. > >> > > >> > On Fri, Feb 10, 2012 at 7:53 PM, John Davis wrote: > >> >> is there a flag to force swiftshader-webgl rendering? > >> > > >> > > > > > --- > > Daniel Koch -+- daniel...@ > > Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com > > --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Feb 10 17:29:25 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Fri, 10 Feb 2012 17:29:25 -0800 Subject: [Public WebGL] Conformance test for GLSL: Side-effects in the ternary if operator (used in combination with the comma (sequence) operator) In-Reply-To: References: Message-ID: Thanks for this and please keep them coming. I added these 2 tests to the WebGL conformance tests. https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/glsl/misc/shader-with-comma-assignment.html https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/glsl/misc/shader-with-comma-conditional-assignment.html I hope those sufficiently test the issue. I verified they do fail on ANGLE for 2 of 9 tests You can run newer conformance tests here https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html?minVersion=1.0.2 As soon as 1.0.1 is ratified we'll start pushing on 1.0.2 (though hopefully we'll find time to fix these bugs asap) -gregg On Fri, Feb 10, 2012 at 11:24 AM, Rehno Lindeque wrote: > Hi all, > > Following a lively discussion at the San Francisco WebGL meetup last > night, someone suggested that we should submit bugs in GLSL so they could > be added to the WebGL conformance tests. I agree that getting consistent > glsl support across all devices/drivers would be pretty helpful. > > This is a bug that I've found in ANGLE on windows machines running Google > Chrome 16.0.912.77 m. > > float a = ... > float b = ... > float r0 = ... > float r1 = ... > float r = ... > float ab = a > b? (r = r0, a) : (r = r1, b); > return r; > > On my usual (linux) machine this runs only one of the two side-effects (r > = r0) or (r = r1) as you'd expect, but on ANGLE I believe it probably runs > both. > > I didn't submit this before because I haven't had time to write up a > decent test, however if someone would be willing to add it I'd be grateful. > I guess I could probably be convinced to generate a shader that fails at > this if you really need it. > > Thank you, > Rehno > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reh...@ Fri Feb 10 17:44:09 2012 From: reh...@ (Rehno Lindeque) Date: Fri, 10 Feb 2012 17:44:09 -0800 Subject: [Public WebGL] Conformance test for GLSL: Side-effects in the ternary if operator (used in combination with the comma (sequence) operator) In-Reply-To: References: Message-ID: Thank you Gregg and great work on Chrome. Cheers On Fri, Feb 10, 2012 at 5:29 PM, Gregg Tavares (?) wrote: > Thanks for this and please keep them coming. > > I added these 2 tests to the WebGL conformance tests. > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/glsl/misc/shader-with-comma-assignment.html > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/glsl/misc/shader-with-comma-conditional-assignment.html > > I hope those sufficiently test the issue. I verified they do fail on > ANGLE for 2 of 9 tests > > You can run newer conformance tests here > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html?minVersion=1.0.2 > > As soon as 1.0.1 is ratified we'll start pushing on 1.0.2 (though > hopefully we'll find time to fix these bugs asap) > > > -gregg > > > On Fri, Feb 10, 2012 at 11:24 AM, Rehno Lindeque > wrote: > >> Hi all, >> >> Following a lively discussion at the San Francisco WebGL meetup last >> night, someone suggested that we should submit bugs in GLSL so they could >> be added to the WebGL conformance tests. I agree that getting consistent >> glsl support across all devices/drivers would be pretty helpful. >> >> This is a bug that I've found in ANGLE on windows machines running Google >> Chrome 16.0.912.77 m. >> >> float a = ... >> float b = ... >> float r0 = ... >> float r1 = ... >> float r = ... >> float ab = a > b? (r = r0, a) : (r = r1, b); >> return r; >> >> On my usual (linux) machine this runs only one of the two side-effects (r >> = r0) or (r = r1) as you'd expect, but on ANGLE I believe it probably runs >> both. >> >> I didn't submit this before because I haven't had time to write up a >> decent test, however if someone would be willing to add it I'd be grateful. >> I guess I could probably be convinced to generate a shader that fails at >> this if you really need it. >> >> Thank you, >> Rehno >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Tue Feb 14 14:08:12 2012 From: jda...@ (John Davis) Date: Tue, 14 Feb 2012 16:08:12 -0600 Subject: [Public WebGL] webgl/swiftshader Message-ID: what are the chances of getting it on android/win8 arm for firefox? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Feb 15 05:18:42 2012 From: bja...@ (Benoit Jacob) Date: Wed, 15 Feb 2012 05:18:42 -0800 (PST) Subject: [Public WebGL] webgl/swiftshader In-Reply-To: Message-ID: <1179335983.8669387.1329311922571.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> SwiftShader is not, as far as I know, available under a license that would allow us to use it in Firefox. The highest-performing open source 3D renderer that I know of, that we could consider as an alternative, is Mesa/llvmpipe. I was very concerned about increasing the Firefox download size, but it seems that the Chrome guys have found a good way to solve this problem: if I understand correctly, the software renderer is only downloaded on demand when it's going to be actually used. (Meanwhile, on desktop linux at least, we could simply ask linux distros to install Mesa/llvmpipe by default). Benoit ----- Original Message ----- > what are the chances of getting it on android/win8 arm for firefox? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir...@ Wed Feb 15 06:09:15 2012 From: mir...@ (miro) Date: Wed, 15 Feb 2012 15:09:15 +0100 Subject: [Public WebGL] WebGL support in Oracle VirtualBox Message-ID: <4F3BBC8B.3060506@gmail.com> Hi, I have tried to run WebGL in VirtualBox (oracle) but it didn't work - tried with the latest Chrome. Does anybody know if there are some workarounds to be able to run WebGL under VB? Regards, Miro -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Feb 15 10:14:50 2012 From: kbr...@ (Kenneth Russell) Date: Wed, 15 Feb 2012 10:14:50 -0800 Subject: [Public WebGL] WebGL support in Oracle VirtualBox In-Reply-To: <4F3BBC8B.3060506@gmail.com> References: <4F3BBC8B.3060506@gmail.com> Message-ID: You might try passing the command line argument --ignore-gpu-blacklist when launching Chrome, but this is not a configuration that the Chrome team tests and I can't vouch for whether it will work. -Ken On Wed, Feb 15, 2012 at 6:09 AM, miro wrote: > Hi, > I have tried to run WebGL in VirtualBox (oracle) but it didn't work - tried > with the latest Chrome. Does anybody know if there are some workarounds to > be able to run WebGL under VB? > > Regards, > Miro ----------------------------------------------------------- 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 cal...@ Wed Feb 15 10:37:09 2012 From: cal...@ (Mark Callow) Date: Wed, 15 Feb 2012 10:37:09 -0800 Subject: [Public WebGL] webgl/swiftshader In-Reply-To: References: Message-ID: <4F3BFB55.9000705@hicorp.co.jp> On 12/02/14 14:08, John Davis wrote: > what are the chances of getting it on android/win8 arm for firefox? Why the interest? As I understand it, any hardware capable of running win8 is not going to need software fallbacks. I suspect the same is true of any hardware capable of running Android 3+. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Feb 15 10:49:50 2012 From: jda...@ (John Davis) Date: Wed, 15 Feb 2012 12:49:50 -0600 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: <4F3BFB55.9000705@hicorp.co.jp> References: <4F3BFB55.9000705@hicorp.co.jp> Message-ID: Thanks, I didn't realize all cases would have powervr gpu's. On Wednesday, February 15, 2012, Mark Callow wrote: > On 12/02/14 14:08, John Davis wrote: > > what are the chances of getting it on android/win8 arm for firefox? > > Why the interest? As I understand it, any hardware capable of running win8 is not going to need software fallbacks. I suspect the same is true of any hardware capable of running Android 3+. > > Regards > > -Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bag...@ Wed Feb 15 10:57:39 2012 From: bag...@ (Patrick Baggett) Date: Wed, 15 Feb 2012 12:57:39 -0600 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> Message-ID: On Wed, Feb 15, 2012 at 12:49 PM, John Davis wrote: > Thanks, I didn't realize all cases would have powervr gpu's. > > > Not sure if troll, but Nvidia's Tegra platform looks up to the challenge and it isn't based on PowerVR. I wouldn't say 100% of Win8 platforms will be WebGL capable, but honestly, if a > 3.0 GHz x86-64 machine stutters while using Mesa's LLVM shader backend (swiftshader is x86 only, and cannot be ported since it glues x86 asm together), then I imagine a 600MHz - 1GHz ARM chip running with power constraints would scarcely be able to render anything "interactively". When it comes to shaders on embedded hardware, it is basically GPU or die trying. Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Feb 15 12:16:52 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 15 Feb 2012 21:16:52 +0100 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> Message-ID: On Wed, Feb 15, 2012 at 7:57 PM, Patrick Baggett wrote: > I wouldn't say 100% of Win8 platforms will be WebGL capable, but honestly, > if a > 3.0 GHz x86-64 machine stutters while using Mesa's LLVM shader > backend (swiftshader is x86 only, and cannot be ported since it glues x86 > asm together), then I imagine a 600MHz - 1GHz ARM chip running with power > constraints would scarcely be able to render anything "interactively". When > it comes to shaders on embedded hardware, it is basically GPU or die trying. > Well it's true that more complex usages would be all but hog-slow on CPUs. But if all you need is to draw a couple hundred triangles and some simple lighting, software rendering is a good alternative, say as opposed to missusing canvas2d to do 3d or rasterizing in pure javascript. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jba...@ Wed Feb 15 18:16:12 2012 From: jba...@ (John Bauman) Date: Wed, 15 Feb 2012 18:16:12 -0800 Subject: [Public WebGL] WebGL support in Oracle VirtualBox In-Reply-To: References: <4F3BBC8B.3060506@gmail.com> Message-ID: Or, failing that, --blacklist-webgl will let it use the Swiftshader software renderer (though you'll have to wait several minutes for it to be downloaded and installed). On Wed, Feb 15, 2012 at 10:14 AM, Kenneth Russell wrote: > > You might try passing the command line argument --ignore-gpu-blacklist > when launching Chrome, but this is not a configuration that the Chrome > team tests and I can't vouch for whether it will work. > > -Ken > > On Wed, Feb 15, 2012 at 6:09 AM, miro wrote: > > Hi, > > I have tried to run WebGL in VirtualBox (oracle) but it didn't work - > tried > > with the latest Chrome. Does anybody know if there are some workarounds > to > > be able to run WebGL under VB? > > > > Regards, > > Miro > > ----------------------------------------------------------- > 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 mir...@ Thu Feb 16 02:08:27 2012 From: mir...@ (miro) Date: Thu, 16 Feb 2012 11:08:27 +0100 Subject: [Public WebGL] WebGL support in Oracle VirtualBox In-Reply-To: References: <4F3BBC8B.3060506@gmail.com> Message-ID: <4F3CD59B.6090803@gmail.com> Many thanks for the reply, but unfortunately it didn't help (17.0.963.56 m). Was anybody able to run webgl under virtualBox (Windows Server 2008)? If yes, what browser and settings? Thank you for your help. m. On 16.02.2012 03:16, John Bauman wrote: > Or, failing that, --blacklist-webgl will let it use the Swiftshader > software renderer (though you'll have to wait several minutes for it > to be downloaded and installed). > > On Wed, Feb 15, 2012 at 10:14 AM, Kenneth Russell > wrote: > > > You might try passing the command line argument --ignore-gpu-blacklist > when launching Chrome, but this is not a configuration that the Chrome > team tests and I can't vouch for whether it will work. > > -Ken > > On Wed, Feb 15, 2012 at 6:09 AM, miro > wrote: > > Hi, > > I have tried to run WebGL in VirtualBox (oracle) but it didn't > work - tried > > with the latest Chrome. Does anybody know if there are some > workarounds to > > be able to run WebGL under VB? > > > > Regards, > > Miro > > ----------------------------------------------------------- > 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 bja...@ Thu Feb 16 05:40:05 2012 From: bja...@ (Benoit Jacob) Date: Thu, 16 Feb 2012 05:40:05 -0800 (PST) Subject: [Public WebGL] WebGL support in Oracle VirtualBox In-Reply-To: <4F3CD59B.6090803@gmail.com> Message-ID: <1984027584.9914277.1329399605293.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> For the record, on Firefox too, to use WebGL with VirtualBox you have to force-enable (about:config, webgl.force-enabled). We did this specifically because of a VirtualBox crash at that time (https://bugzilla.mozilla.org/show_bug.cgi?id=621411). It would be interesting to hear if anyone can get a complete run of the conformance test suite with VirtualBox (using Firefox Nightly or Chrome Canary), and report on test failures. Cheers, Benoit ----- Original Message ----- > Many thanks for the reply, but unfortunately it didn't help > (17.0.963.56 m). > Was anybody able to run webgl under virtualBox (Windows Server 2008)? > If yes, what browser and settings? > Thank you for your help. > m. > On 16.02.2012 03:16, John Bauman wrote: > > Or, failing that, --blacklist-webgl will let it use the Swiftshader > > software renderer (though you'll have to wait several minutes for > > it > > to be downloaded and installed). > > > On Wed, Feb 15, 2012 at 10:14 AM, Kenneth Russell < kbr...@ > > > > > wrote: > > > > You might try passing the command line argument > > > --ignore-gpu-blacklist > > > > > > when launching Chrome, but this is not a configuration that the > > > Chrome > > > > > > team tests and I can't vouch for whether it will work. > > > > > > -Ken > > > > > > On Wed, Feb 15, 2012 at 6:09 AM, miro < miroslav.karpis...@ > > > > > > > wrote: > > > > > > > Hi, > > > > > > > I have tried to run WebGL in VirtualBox (oracle) but it didn't > > > > work > > > > - tried > > > > > > > with the latest Chrome. Does anybody know if there are some > > > > workarounds to > > > > > > > be able to run WebGL under VB? > > > > > > > > > > > > > > Regards, > > > > > > > Miro > > > > > > ----------------------------------------------------------- > > > > > > 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 nic...@ Fri Feb 17 08:54:09 2012 From: nic...@ (Nicolas Rannou) Date: Fri, 17 Feb 2012 11:54:09 -0500 Subject: [Public WebGL] Empty triangles when decrease opacity Message-ID: Hi, I'm new in webgl. If I decrease the opacity of my meshes in the color fragment, some triangles become transparent... Would somebody know what could cause such a behavior? The meshes look fine with an opacity of 1... Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2012-02-17 at 11.50.08 AM.png Type: image/png Size: 59279 bytes Desc: not available URL: From pya...@ Fri Feb 17 09:03:02 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 17 Feb 2012 18:03:02 +0100 Subject: [Public WebGL] Empty triangles when decrease opacity In-Reply-To: References: Message-ID: On Fri, Feb 17, 2012 at 5:54 PM, Nicolas Rannou wrote: > If I decrease the opacity of my meshes in the color fragment, some > triangles become transparent... > Would somebody know what could cause such a behavior? > > The meshes look fine with an opacity of 1... > When alpha blending it is important that a fragment emitted further from the observer is drawn before a fragment emitted closer to an observer. I.e. all fragments that should be blended need to be drawn back to front. Your mesh is drawn in a random order, which does not coincide with the requirement to draw it back to front. Solutions: - One common solution to this problem is to sort the triangles back to front before drawing them (this may be expensive if you need to upload a lot of triangles every frame). This has a few degenerate cases (in case of overlapping loops or intersecting triangles). - Other solutions to the problem of unordered fragments are depth peeling (expensive to do in WebGL because we have no multi-render targets) - Linked lists of fragments (impossible to do in WebGL because we have no compute shaders or the like) - Using additive blending (cheap but not always desired) - Faking order independent blending by blending additively, and dividing by a counter (better than straight up additive, but of course not perfect) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cos...@ Sun Feb 19 07:32:33 2012 From: cos...@ (Liam Wilson) Date: Sun, 19 Feb 2012 15:32:33 +0000 (GMT) Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> Message-ID: <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> I think "software rendering is slow" is a bit of a self fulfilling prophecy. No one thinks it can be fast, so no one bothers to write a fast software renderer. So we then wind up drawing comparisons between unoptimised CPU renderers, and highly optimised GPUrenderers. Which then makes the performance gap look far worse than it actually is. Liam PS sorry about the top post, yahoo webmail now completely sucks at plain text email quoting. PPS According to http://transgaming.com/business/swiftshader/technology/ Swiftshader is not just x86 ________________________________ From: Florian B?sch To: Patrick Baggett Cc: jdavis...@; Mark Callow ; public webgl Sent: Wednesday, 15 February 2012, 20:16 Subject: Re: [Public WebGL] Re: webgl/swiftshader On Wed, Feb 15, 2012 at 7:57 PM, Patrick Baggett wrote: I wouldn't say 100% of Win8 platforms will be WebGL capable, but honestly, if a > 3.0 GHz x86-64 machine stutters while using Mesa's LLVMshaderbackend (swiftshader is x86 only, and cannot be ported since it glues x86 asm together), then I imagine a 600MHz - 1GHz ARM chip running with power constraints would scarcely be able to render anything "interactively". When it comes to shaders on embedded hardware, it is basically GPU or die trying. Well it's true that more complex usages would be all but hog-slow on CPUs. But if all you need is to draw a couple hundred triangles and some simple lighting, software rendering is a good alternative, say as opposed to missusing canvas2d to do 3d or rasterizing in pure javascript.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 19 08:06:55 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sun, 19 Feb 2012 17:06:55 +0100 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> Message-ID: On Sun, Feb 19, 2012 at 4:32 PM, Liam Wilson wrote: > I think "software rendering is slow" is a bit of a self fulfilling > prophecy. No one thinks it can be fast, so no one bothers to write a fast > software renderer. So we then wind up drawing comparisons between > unoptimised CPU renderers, and highly optimised GPU renderers. Which then > makes the performance gap look far worse than it actually is. > 1) Software rendering *is* slow. Mid-end desktop GPUs output around 500 million triangles per second and about 30 billion texels per second (that would be 14'000 full-hd screens per second). 2) Swiftshader is a good/fast implementation of software rendering, but you cannot expect this to ever reach anywhere actual GPU performance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cos...@ Sun Feb 19 11:20:22 2012 From: cos...@ (Liam Wilson) Date: Sun, 19 Feb 2012 19:20:22 +0000 (GMT) Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> Message-ID: <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> But the majority of people don't have even a mid range discrete GPU. They have an integrated GPU (and if http://unity3d.com/webplayer/hwstats/pages/web-2011Q3-gfxcard.html is anything to go by, they don't even have a good integrated GPU). Even if the do happen to have an okGPU there is still the issue of out dated drivers/missing GPU features.There's stats on http://people.mozilla.org/~bjacob/gfx_features_stats/ (again, take these with a pinch of salt), only about 10% of win XP users currently stand a chance of getting decent WebGL performance (layers acceleration enabled). It's not just a matter of raw performance. Rendering only needs to be fast enough to make applications usable. At a modest resolution and frame rates this is entirely possible with software rendering. There are far too many WebGL demos out there that attempt to render 60 fps at full screen resolution. 30fps at 640x360 would be perfectly good. ________________________________ From: Florian B?sch To: Liam Wilson Cc: public webgl Sent: Sunday, 19 February 2012, 16:06 Subject: Re: [Public WebGL] Re: webgl/swiftshader On Sun, Feb 19, 2012 at 4:32 PM, Liam Wilson wrote: I think "software rendering is slow" is a bit of a self fulfilling prophecy. No one thinks it can be fast, so no one bothers to write a fast software renderer. So we then wind up drawing comparisons between unoptimised CPU renderers, and highly optimised GPUrenderers. Which then makes the performance gap look far worse than it actually is. 1) Software rendering *is* slow. Mid-end desktop GPUs output around 500 million triangles per second and about 30 billion texels per second (that would be 14'000 full-hd screens per second). 2) Swiftshader is a good/fast implementation of software rendering, but you cannot expect this to ever reach anywhere actual GPU performance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Feb 19 12:03:35 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sun, 19 Feb 2012 21:03:35 +0100 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> Message-ID: On Sun, Feb 19, 2012 at 8:20 PM, Liam Wilson wrote: > But the majority of people don't have even a mid range discrete GPU. They > have an integrated GPU (and if > http://unity3d.com/webplayer/hwstats/pages/web-2011Q3-gfxcard.html is > anything to go by, they don't even have a good integrated GPU). Even if the > do happen to have an ok GPU there is still the issue of out dated > drivers/missing GPU features.There's stats on > http://people.mozilla.org/~bjacob/gfx_features_stats/ (again, take these > with a pinch of salt), only about 10% of win XP users currently stand a > chance of getting decent WebGL performance (layers acceleration enabled). > I guarantee you that no matter how slow the GPU, any hardware acceleration, any at all that works, will be faster than software rendering. Somebody who has a miserable GPU in his machine isn't gonna magically pull out a high end Intel Core i7 out of their hat. > It's not just a matter of raw performance. Rendering only needs to be > fast enough to make applications usable. At a modest resolution and frame > rates this is entirely possible with software rendering. There are far too > many WebGL demos out there that attempt to render 60 fps at full screen > resolution. 30fps at 640x360 would be perfectly good. > That's what I said, there's a a perfectly good range of use-cases that can use software rendering. If you're just gonna use simple shaders, forward shading and a couple hundred triangles, you're fine. Incidentally I don't do any of that really. In fact, even most severely limited games render at least a couple ten thousand triangles from half a dozen textures on screen at resolutions upwards of 1024x786. As to the matter of resolution. No, I won't like 640x360, that has about the size of a dollar bill on my desktop screen. Also the iPad3 will have a resolution of 2048x1536 at a screen size of 25cm diagonal your "ideal" 640x360 is about the size of quarter of a dollar bill, already pretty close to a postage stamp. The high resolution era isn't gonna halt before 3D content, and this isn't magically go away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ase...@ Mon Feb 20 09:51:10 2012 From: ase...@ (Alvaro Segura) Date: Mon, 20 Feb 2012 18:51:10 +0100 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> Message-ID: <4F42880E.3030501@vicomtech.org> My view is that software rendering is not only welcome but even necessary. Real world sites can't afford to use a technology that will not work for a large percentage of users or they will face countless complaints. A newspaper front page can't place a 3D object that will show an error message to a large number of their readers. Users of low end systems can understand things work suboptimally for them, but not that they don't work at all. They go to YouTube and expect to play videos, maybe in SD only or with some stutter, but they would complain if they just see a black screen and an error message. Standards-based Web technology must not impose special hardware requirements: Javascript executes slower in slow CPUs, Canvas draws slower in slower CPUs with no GPU support, CSS effects work slower in lower end machines, video decoding is slower and may limit practical video resolution in slower machines withour video decoding hardware, etc. But they all work anyway, better or worse. So, my opinion is: a fallback is necessary, i.e. a "better than nothing" fallback. In the time before programmable shaders and when 3D acceleration was less common, software rendering was quite ubiquitous. VRML software renderers perform quite well for their needs, they just work everywhere, but works much better on good 3D hardware. IMO, Swiftshader is quite impressive and usable for many applications. Not all 3D is like Crysis. For example, I just tried GL GoogleMaps and it shows rendering bugs (might be solved some day) but is not too slow, and Google Street View works perfect, and it does not need Flash! That is a practical example that does not require millions of vertices. BTW, Firefox used to allow software rendering via Mesa, but that seems to not work anymore (with OSMesa32.dll set in preferences, etc.). Or am I doing something wrong? I remember it as being too slow, though. Best regards El 19/02/2012 21:03, Florian B?sch escribi?: > On Sun, Feb 19, 2012 at 8:20 PM, Liam Wilson > > wrote: > > But the majority of people don't have even a mid range discrete > GPU. They have an integrated GPU (and if > http://unity3d.com/webplayer/hwstats/pages/web-2011Q3-gfxcard.html > is anything to go by, they don't even have a good integrated GPU). > Even if the do happen to have an ok GPU there is still the issue > of out dated drivers/missing GPU features.There's stats on > http://people.mozilla.org/~bjacob/gfx_features_stats/ > (again, > take these with a pinch of salt), only about 10% of win XP users > currently stand a chance of getting decent WebGL performance > (layers acceleration enabled). > > I guarantee you that no matter how slow the GPU, any hardware > acceleration, any at all that works, will be faster than software > rendering. Somebody who has a miserable GPU in his machine isn't gonna > magically pull out a high end Intel Core i7 out of their hat. > > It's not just a matter of raw performance. Rendering only needs to > be fast enough to make applications usable. At a modest resolution > and frame rates this is entirely possible with software rendering. > There are far too many WebGL demos out there that attempt to > render 60 fps at full screen resolution. 30fps at 640x360 would be > perfectly good. > > That's what I said, there's a a perfectly good range of use-cases that > can use software rendering. If you're just gonna use simple shaders, > forward shading and a couple hundred triangles, you're > fine. Incidentally I don't do any of that really. In fact, even most > severely limited games render at least a couple ten thousand triangles > from half a dozen textures on screen at resolutions upwards of 1024x786. > > As to the matter of resolution. No, I won't like 640x360, that has > about the size of a dollar bill on my desktop screen. Also the iPad3 > will have a resolution of 2048x1536 at a screen size of 25cm diagonal > your "ideal" 640x360 is about the size of quarter of a dollar bill, > already pretty close to a postage stamp. The high resolution era isn't > gonna halt before 3D content, and this isn't magically go away. ----------------------------------------------------------- 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 Feb 20 10:08:18 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 20 Feb 2012 19:08:18 +0100 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: <4F42880E.3030501@vicomtech.org> References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> Message-ID: On Mon, Feb 20, 2012 at 6:51 PM, Alvaro Segura wrote: > My view is that software rendering is not only welcome but even necessary. > It's very necessary, there's no denying that. > Real world sites can't afford to use a technology that will not work for a > large percentage of users or they will face countless complaints. That depends on what real world page you're doing. If you're writing a WebGL game intended for gamers, and not the next article in the new york times, your requirements differ, a lot. > Users of low end systems can understand things work suboptimally for them, > but not that they don't work at all. Some things will not work, at all, with software rendering. Mainly in the range of performance. For instance if your usecase requires 5000 triangles, but performance is too slow you can probably scale down to 2500 triangles. But if your usecase requires 2 million triangles, there simply isn't any way that's gonna fit into 2500 triangles. There's similar "can simply not scale down that much" issues around texel troughput, texture units, extensions, vram usage, etc. > Standards-based Web technology must not impose special hardware > requirements: > Efficient 3D rendering unfortunately requires special hardware requirements. Therefore that statement would have to be reminted to "WebGL should be restricted to the capabilities of software rendering only", which for most intend and purpose would be "no webgl at all". Clearly that's not a valid position. > So, my opinion is: a fallback is necessary, i.e. a "better than nothing" > fallback. > Yes a software fallback is nice, but it does not mean things will magically work for everybody. They will work for some. > In the time before programmable shaders and when 3D acceleration was less > common, software rendering was quite ubiquitous. VRML software renderers > perform quite well for their needs, they just work everywhere, but works > much better on good 3D hardware. > Nobody uses VRML (or x3d or o3d), which proves the point that another forward shading rasterizer and scene-graph library is what nobody wanted the last 20 years. Thinking things like "it worked for VRML, so it's gonna work for WebGL" is flawed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Mon Feb 20 11:14:57 2012 From: ste...@ (Steve Baker) Date: Mon, 20 Feb 2012 13:14:57 -0600 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> Message-ID: <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> While I'm not actively against a software rendering fallback - I honestly think it's a waste of effort to make one - and that it'll cause some people more harm than good. 10 years ago, a significant number people were still using 9600 baud dialup, but many were starting to get higher-speed connections. There were many websites that were *SO* slow at 9600 baud that they were effectively inaccessible. The fix for this was to have "Low Bandwidth Version" links for people who had dialup...you don't see many sites like that anymore - but they used to be everywhere. When designing a new software technology that is expected to be pervasive - one cannot afford to target the lowest common denominator because to do so is to invest heavily in a dying population of users. If we did that then we wouldn't be able to put 1024x1024 pixel images up on our web pages because a few die-hards still only have dialup and it takes them ~10 minutes to load it. WebGL *must* take a leap forward and assume the existence of a GPU or else it'll be useless for anything beyond minimal eye-candy. This is an 'intercept' technology - we design for the future and let the world catch up with us. That's how we become ready when the technology is so pervasive that it's safe to assume that it exists everywhere (just as we assume that nobody we care about still has dialup). Sadly, we're now in that interim period where not all computers will be able to display all of this cool new stuff. But that shouldn't stop web designers from using it. There is a perfectly good way to test to see whether you have a valid WebGL environment - and if you don't, and you care enough about that decreasing population of people without a GPU - then you find some other way to convey your message to them. If you're doing something like selling widgets on the Internet - then users with GPU's should get a 3D rendering of your new SuperWidget-3000 that they can spin around and interact with - and low end users should get a movie clip or a photo gallery of still images or something. If you care enough about getting your message to all of the users out there then this is a small price to pay. But - if you're a game designer - there is nothing worse than to find a valid WebGL environment and then discover that it takes 30 seconds to render a single frame and to have to resort to disgusting timing tricks to try to deduce whether this is a GPU or not. I'd *much* rather a system report "Sorry, you need a machine that can run WebGL" than to have it try to run my game at 0.03Hz. If software rendering were (say) 50% or even 10% as fast as the GPU, then I'd be tempted to try to fix that - but they aren't. They are about 1% of the speed in small windows and 0.1% of the speed in large windows. I can't make my content scale that much. If I have a 1000 triangle cow in my scene - I can't drop that to a 10 triangle cow for software rendering because you simply cannot topologically make a cow in 10 triangles! I'd have to do it by drawing fewer cows - but if my game centers on chasing herds of cows then the game play falls apart if you don't have enough of them. -- Steve Florian B?sch wrote: > On Mon, Feb 20, 2012 at 6:51 PM, Alvaro Segura > wrote: > >> My view is that software rendering is not only welcome but even >> necessary. >> > It's very necessary, there's no denying that. > > >> Real world sites can't afford to use a technology that will not work for >> a >> large percentage of users or they will face countless complaints. > > That depends on what real world page you're doing. If you're writing a > WebGL game intended for gamers, and not the next article in the new york > times, your requirements differ, a lot. > > >> Users of low end systems can understand things work suboptimally for >> them, >> but not that they don't work at all. > > Some things will not work, at all, with software rendering. Mainly in the > range of performance. For instance if your usecase requires 5000 > triangles, > but performance is too slow you can probably scale down to 2500 triangles. > But if your usecase requires 2 million triangles, there simply isn't any > way that's gonna fit into 2500 triangles. There's similar "can simply not > scale down that much" issues around texel troughput, texture units, > extensions, vram usage, etc. > > >> Standards-based Web technology must not impose special hardware >> requirements: >> > Efficient 3D rendering unfortunately requires special hardware > requirements. Therefore that statement would have to be reminted to "WebGL > should be restricted to the capabilities of software rendering only", > which > for most intend and purpose would be "no webgl at all". Clearly that's > not > a valid position. > > > >> So, my opinion is: a fallback is necessary, i.e. a "better than nothing" >> fallback. >> > Yes a software fallback is nice, but it does not mean things will > magically > work for everybody. They will work for some. > > >> In the time before programmable shaders and when 3D acceleration was >> less >> common, software rendering was quite ubiquitous. VRML software renderers >> perform quite well for their needs, they just work everywhere, but works >> much better on good 3D hardware. >> > Nobody uses VRML (or x3d or o3d), which proves the point that another > forward shading rasterizer and scene-graph library is what nobody wanted > the last 20 years. Thinking things like "it worked for VRML, so it's gonna > work for WebGL" is flawed. > -- Steve ----------------------------------------------------------- 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...@ Mon Feb 20 16:03:42 2012 From: bja...@ (Benoit Jacob) Date: Mon, 20 Feb 2012 16:03:42 -0800 (PST) Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: <4F42880E.3030501@vicomtech.org> Message-ID: <2137660843.11780047.1329782622406.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > BTW, Firefox used to allow software rendering via Mesa, but that > seems > to not work anymore (with OSMesa32.dll set in preferences, etc.). Or > am > I doing something wrong? I remember it as being too slow, though. It should work, but regressions are possible (not covered by unit tests). Please file a bug if you find one :) OSMesa is based on a very old version of Mesa that's a lot slower than Mesa 8 + LLVMpipe. New effort should go into that instead of old OSMesa support. Or maybe OSMesa will get updated, who knows. Benoit > > Best regards > > > > El 19/02/2012 21:03, Florian B?sch escribi?: > > On Sun, Feb 19, 2012 at 8:20 PM, Liam Wilson > > > > > wrote: > > > > But the majority of people don't have even a mid range discrete > > GPU. They have an integrated GPU (and if > > http://unity3d.com/webplayer/hwstats/pages/web-2011Q3-gfxcard.html > > is anything to go by, they don't even have a good integrated > > GPU). > > Even if the do happen to have an ok GPU there is still the > > issue > > of out dated drivers/missing GPU features.There's stats on > > http://people.mozilla.org/~bjacob/gfx_features_stats/ > > > > (again, > > take these with a pinch of salt), only about 10% of win XP > > users > > currently stand a chance of getting decent WebGL performance > > (layers acceleration enabled). > > > > I guarantee you that no matter how slow the GPU, any hardware > > acceleration, any at all that works, will be faster than software > > rendering. Somebody who has a miserable GPU in his machine isn't > > gonna > > magically pull out a high end Intel Core i7 out of their hat. > > > > It's not just a matter of raw performance. Rendering only needs > > to > > be fast enough to make applications usable. At a modest > > resolution > > and frame rates this is entirely possible with software > > rendering. > > There are far too many WebGL demos out there that attempt to > > render 60 fps at full screen resolution. 30fps at 640x360 would > > be > > perfectly good. > > > > That's what I said, there's a a perfectly good range of use-cases > > that > > can use software rendering. If you're just gonna use simple > > shaders, > > forward shading and a couple hundred triangles, you're > > fine. Incidentally I don't do any of that really. In fact, even > > most > > severely limited games render at least a couple ten thousand > > triangles > > from half a dozen textures on screen at resolutions upwards of > > 1024x786. > > > > As to the matter of resolution. No, I won't like 640x360, that has > > about the size of a dollar bill on my desktop screen. Also the > > iPad3 > > will have a resolution of 2048x1536 at a screen size of 25cm > > diagonal > > your "ideal" 640x360 is about the size of quarter of a dollar bill, > > already pretty close to a postage stamp. The high resolution era > > isn't > > gonna halt before 3D content, and this isn't magically go away. > > > ----------------------------------------------------------- > 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 jat...@ Tue Feb 21 07:36:19 2012 From: jat...@ (John Tamplin) Date: Tue, 21 Feb 2012 10:36:19 -0500 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> Message-ID: On Mon, Feb 20, 2012 at 2:14 PM, Steve Baker wrote: > > If you're doing something like selling widgets on the Internet - then > users with GPU's should get a 3D rendering of your new SuperWidget-3000 > that they can spin around and interact with - and low end users should get > a movie clip or a photo gallery of still images or something. If you care > enough about getting your message to all of the users out there then this > is a small price to pay. > > But - if you're a game designer - there is nothing worse than to find a > valid WebGL environment and then discover that it takes 30 seconds to > render a single frame and to have to resort to disgusting timing tricks to > try to deduce whether this is a GPU or not. I'd *much* rather a system > report "Sorry, you need a machine that can run WebGL" than to have it try > to run my game at 0.03Hz. > Maybe the answer is to have some way to ask the question "I have x triangles and need y fps and features z, what is the likelihood this WebGL implementation can deliver that". Given that, the app can make a reasonable decision of telling the user "sorry, you need to upgrade to use this app", running as-is, or scaling back. As I understand it, there isn't any way to do this now other than to try it and time the result, which gives a poor user experience anyway. The alternative is to detect and whitelist configurations, or leave it up to the user -- "here is the known-good version, you can try the WebGL version if you are brave". -- John A. Tamplin Software Engineer (GWT), Google -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Tue Feb 21 15:49:40 2012 From: ash...@ (Ashley Gullen) Date: Tue, 21 Feb 2012 23:49:40 +0000 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> Message-ID: Why not just introduce some flag which indicates whether the implementation is rendering with specialised hardware (GPU) or not (software)? Then each application developer can test their individual apps both ways and see if for practical purposes both work, or if only one works. Then each developer can either support both, require GPU support, or have some notification that says something like "Your computer can run this content, but it may be slow. Are you sure you want to continue?" By default it would use whatever's available so the developer would have to intervene to either require GPU support or introduce a notification. Sure, some beefy CPUs may be able to just out-do low-class GPU hardware, but I think the vast majority of software-rendering cases will be ordinary low-mid power computers with perfectly capable GPUs that are blacklisted due to old drivers. (Judging by the mozilla link earlier, 50% of people don't get hardware accelerated WebGL.) As noted previously, most of the time any GPU will far outdo software rendering. So for practical purposes a flag indicating software rendering is a good heuristic that rendering will basically be slow. IMO running performance tests on startup to judge performance is out of the question because every single different application needs its own performance test. This likely will require special coding and the developer may not even create a fair representation, resulting in bad data and the wrong renderer chosen. Personally I have no idea how I would create a single fair test for any particular game that always chooses the best renderer for the vast array of system configurations out there. Think about a game with loads of different levels, each with different rendering characteristics and heavily dependent on user input and skill level - how do you make a worthwhile five second test for that? I don't think it can be solved by frameworks either, because if there was some generalised test that could always pick the best renderer, we wouldn't have this problem in the first place. So I think there really ought to be a software/hardware rendering flag, and that's a good heuristic. For eye candy on a web page, just don't show it if it's going to be software rendered, and fall back to an image or video. For a simple game, you can probably get by with software rendering. For Crysis 3: Browser Wars, require hardware acceleration. That's still better than the "no WebGL, no content" situation that we face without SwiftShader. My 2c. Ashley Gullen Scirra.com On 21 February 2012 15:36, John Tamplin wrote: > On Mon, Feb 20, 2012 at 2:14 PM, Steve Baker wrote: >> >> If you're doing something like selling widgets on the Internet - then >> users with GPU's should get a 3D rendering of your new SuperWidget-3000 >> that they can spin around and interact with - and low end users should get >> a movie clip or a photo gallery of still images or something. If you care >> enough about getting your message to all of the users out there then this >> is a small price to pay. >> >> But - if you're a game designer - there is nothing worse than to find a >> valid WebGL environment and then discover that it takes 30 seconds to >> render a single frame and to have to resort to disgusting timing tricks to >> try to deduce whether this is a GPU or not. I'd *much* rather a system >> report "Sorry, you need a machine that can run WebGL" than to have it try >> to run my game at 0.03Hz. >> > > Maybe the answer is to have some way to ask the question "I have x > triangles and need y fps and features z, what is the likelihood this WebGL > implementation can deliver that". Given that, the app can make a > reasonable decision of telling the user "sorry, you need to upgrade to use > this app", running as-is, or scaling back. > > As I understand it, there isn't any way to do this now other than to try > it and time the result, which gives a poor user experience anyway. The > alternative is to detect and whitelist configurations, or leave it up to > the user -- "here is the known-good version, you can try the WebGL version > if you are brave". > > -- > John A. Tamplin > Software Engineer (GWT), Google > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Wed Feb 22 05:59:32 2012 From: ste...@ (Steve Baker) Date: Wed, 22 Feb 2012 07:59:32 -0600 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> Message-ID: The trouble with the software/hardware flag is that some implementations straddle the line. For example, most (all?) Intel graphics chips don't have vertex shader hardware - so they do that by running the shader in CPU-side software. Should they fess-up to that and flag themselves as software implementations? Maybe...but whichever they did would be wrong for someone. If your application is vertex-shader-heavy then you really would like Intel GPU's to identify themselves as software implementations - but if you only draw 100 full-screen quads a frame but do a huge amount of high-resolution, MSAA, pixel-shader stuff then you'd like it to tell you that it's a hardware implementation. Once you start breaking the implementation down into pieces, you end up in a world of hurt over which flags are set by whom. This debate was out there at the very beginning of OpenGL - when SGI were in the transition from IrisGL. The decision then was to expose the GL_VENDOR/GL_RENDERER/GL_VERSION strings so that the application could blacklist/whitelist or employ different algorithms where needed. In theory that's doable in WebGL - except that Firefox doesn't give you access to the real data because of the "server-side-cookie" issue. -- Steve Ashley Gullen wrote: > Why not just introduce some flag which indicates whether the > implementation > is rendering with specialised hardware (GPU) or not (software)? Then each > application developer can test their individual apps both ways and see if > for practical purposes both work, or if only one works. Then each > developer can either support both, require GPU support, or have some > notification that says something like "Your computer can run this content, > but it may be slow. Are you sure you want to continue?" By default it > would use whatever's available so the developer would have to intervene to > either require GPU support or introduce a notification. > > Sure, some beefy CPUs may be able to just out-do low-class GPU hardware, > but I think the vast majority of software-rendering cases will be ordinary > low-mid power computers with perfectly capable GPUs that are blacklisted > due to old drivers. (Judging by the mozilla link earlier, 50% of people > don't get hardware accelerated WebGL.) As noted previously, most of the > time any GPU will far outdo software rendering. So for practical purposes > a flag indicating software rendering is a good heuristic that rendering > will basically be slow. > > IMO running performance tests on startup to judge performance is out of > the > question because every single different application needs its own > performance test. This likely will require special coding and the > developer may not even create a fair representation, resulting in bad data > and the wrong renderer chosen. Personally I have no idea how I would > create a single fair test for any particular game that always chooses the > best renderer for the vast array of system configurations out there. > Think > about a game with loads of different levels, each with different rendering > characteristics and heavily dependent on user input and skill level - how > do you make a worthwhile five second test for that? I don't think it can > be solved by frameworks either, because if there was some generalised test > that could always pick the best renderer, we wouldn't have this problem in > the first place. > > So I think there really ought to be a software/hardware rendering flag, > and > that's a good heuristic. For eye candy on a web page, just don't show it > if it's going to be software rendered, and fall back to an image or video. > For a simple game, you can probably get by with software rendering. For > Crysis 3: Browser Wars, require hardware acceleration. That's still > better > than the "no WebGL, no content" situation that we face without > SwiftShader. > > My 2c. > > Ashley Gullen > Scirra.com > > > On 21 February 2012 15:36, John Tamplin wrote: > >> On Mon, Feb 20, 2012 at 2:14 PM, Steve Baker wrote: >>> >>> If you're doing something like selling widgets on the Internet - then >>> users with GPU's should get a 3D rendering of your new SuperWidget-3000 >>> that they can spin around and interact with - and low end users should >>> get >>> a movie clip or a photo gallery of still images or something. If you >>> care >>> enough about getting your message to all of the users out there then >>> this >>> is a small price to pay. >>> >>> But - if you're a game designer - there is nothing worse than to find a >>> valid WebGL environment and then discover that it takes 30 seconds to >>> render a single frame and to have to resort to disgusting timing tricks >>> to >>> try to deduce whether this is a GPU or not. I'd *much* rather a system >>> report "Sorry, you need a machine that can run WebGL" than to have it >>> try >>> to run my game at 0.03Hz. >>> >> >> Maybe the answer is to have some way to ask the question "I have x >> triangles and need y fps and features z, what is the likelihood this >> WebGL >> implementation can deliver that". Given that, the app can make a >> reasonable decision of telling the user "sorry, you need to upgrade to >> use >> this app", running as-is, or scaling back. >> >> As I understand it, there isn't any way to do this now other than to try >> it and time the result, which gives a poor user experience anyway. The >> alternative is to detect and whitelist configurations, or leave it up to >> the user -- "here is the known-good version, you can try the WebGL >> version >> if you are brave". >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> > -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Feb 22 06:05:54 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 22 Feb 2012 15:05:54 +0100 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> Message-ID: Maybe we're approaching the issue of wildly different speeds from a wrong angle. In essence app-devs just want to know how much performance they can assume. Trying to figure that out from flags or gpu model or anything would be both tedious and impossible because of the increase in user-identifyable bits. The other way we can figure that out would be by offering some sort of test-runner and performance settings to the user, which may be what's sometimes desired, but is always a lot of work to do. Maybe we can come up with some meaningful performance "profiles" that are tied to a set of authored benchmarks, and they'd roughly indicate the level of performance in a simple grading (say a scale between 0 and 1, 0 being the slowest implementation one can find that still works, and 1 being the fastest). And app-devs could use this as a hint to configure their app and settings (or set reasonable defaults for the user to change). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Feb 22 09:10:03 2012 From: jda...@ (John Davis) Date: Wed, 22 Feb 2012 11:10:03 -0600 Subject: [Public WebGL] Re: webgl/swiftshader In-Reply-To: References: <4F3BFB55.9000705@hicorp.co.jp> <1329665553.23696.YahooMailNeo@web29207.mail.ird.yahoo.com> <1329679222.19383.YahooMailNeo@web29210.mail.ird.yahoo.com> <4F42880E.3030501@vicomtech.org> <42e115f60e3c441715413e9bb150779a.squirrel@webmail.sjbaker.org> Message-ID: I'd love to be able to force use of the software rasterizer at runtime. On Tuesday, February 21, 2012, Ashley Gullen wrote: > Why not just introduce some flag which indicates whether the > implementation is rendering with specialised hardware (GPU) or not > (software)? Then each application developer can test their individual apps > both ways and see if for practical purposes both work, or if only one > works. Then each developer can either support both, require GPU support, > or have some notification that says something like "Your computer can run > this content, but it may be slow. Are you sure you want to continue?" By > default it would use whatever's available so the developer would have to > intervene to either require GPU support or introduce a notification. > > Sure, some beefy CPUs may be able to just out-do low-class GPU hardware, > but I think the vast majority of software-rendering cases will be ordinary > low-mid power computers with perfectly capable GPUs that are blacklisted > due to old drivers. (Judging by the mozilla link earlier, 50% of people > don't get hardware accelerated WebGL.) As noted previously, most of the > time any GPU will far outdo software rendering. So for practical purposes > a flag indicating software rendering is a good heuristic that rendering > will basically be slow. > > IMO running performance tests on startup to judge performance is out of > the question because every single different application needs its own > performance test. This likely will require special coding and the > developer may not even create a fair representation, resulting in bad data > and the wrong renderer chosen. Personally I have no idea how I would > create a single fair test for any particular game that always chooses the > best renderer for the vast array of system configurations out there. Think > about a game with loads of different levels, each with different rendering > characteristics and heavily dependent on user input and skill level - how > do you make a worthwhile five second test for that? I don't think it can > be solved by frameworks either, because if there was some generalised test > that could always pick the best renderer, we wouldn't have this problem in > the first place. > > So I think there really ought to be a software/hardware rendering flag, > and that's a good heuristic. For eye candy on a web page, just don't show > it if it's going to be software rendered, and fall back to an image or > video. For a simple game, you can probably get by with software rendering. > For Crysis 3: Browser Wars, require hardware acceleration. That's still > better than the "no WebGL, no content" situation that we face without > SwiftShader. > > My 2c. > > Ashley Gullen > Scirra.com > > > On 21 February 2012 15:36, John Tamplin > > wrote: > >> On Mon, Feb 20, 2012 at 2:14 PM, Steve Baker >> > wrote: >>> >>> If you're doing something like selling widgets on the Internet - then >>> users with GPU's should get a 3D rendering of your new SuperWidget-3000 >>> that they can spin around and interact with - and low end users should >>> get >>> a movie clip or a photo gallery of still images or something. If you >>> care >>> enough about getting your message to all of the users out there then this >>> is a small price to pay. >>> >>> But - if you're a game designer - there is nothing worse than to find a >>> valid WebGL environment and then discover that it takes 30 seconds to >>> render a single frame and to have to resort to disgusting timing tricks >>> to >>> try to deduce whether this is a GPU or not. I'd *much* rather a system >>> report "Sorry, you need a machine that can run WebGL" than to have it try >>> to run my game at 0.03Hz. >>> >> >> Maybe the answer is to have some way to ask the question "I have x >> triangles and need y fps and features z, what is the likelihood this WebGL >> implementation can deliver that". Given that, the app can make a >> reasonable decision of telling the user "sorry, you need to upgrade to use >> this app", running as-is, or scaling back. >> >> As I understand it, there isn't any way to do this now other than to try >> it and time the result, which gives a poor user experience anyway. The >> alternative is to detect and whitelist configurations, or leave it up to >> the user -- "here is the known-good version, you can try the WebGL version >> if you are brave". >> >> -- >> John A. Tamplin >> Software Engineer (GWT), Google >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Feb 23 06:03:51 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 23 Feb 2012 15:03:51 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: A patch to introduce this extension has been accepted by Mozilla to mozilla-inbound: https://bugzilla.mozilla.org/show_bug.cgi?id=728354 - The extension name MOZ_EXT_texture_filter_anisotropic is used by firefox. - A conformance test has been added for this feature: http://hg.mozilla.org/integration/mozilla-inbound/diff/a6dfdf5a529d/content/canvas/test/webgl/ext-texture-filter-anisotropic.patch - Is it possible to accept this conformance test upstream to the Khronos conformance test suite? - A demo for anisotropic filtering is available at: http://codeflow.org/webgl/anisotropy/ - Sample picture of the demo: http://codeflow.org/pictures/anisotropy.jpg Example Code: var ext = gl.getExtension('MOZ_EXT_texture_filter_anisotropic'); if(ext){ var max = gl.getParameter(ext.MAX_TEXTURE_MAX_ANISOTROPY); gl.texParameterf(target, ext.TEXTURE_MAX_ANISOTROPY, max); } Angle OpenGL works fine, but Direct3D support is not yet there for this feature, requirement described there: http://code.google.com/p/angleproject/issues/detail?id=297 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Feb 23 18:16:14 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 23 Feb 2012 18:16:14 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: The extension should be in "draft" state, not "proposed" state, before anyone implements it. See the very clear "DO NOT IMPLEMENT!" at the top of https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/EXT_texture_filter_anisotropic/index.html . Are there any objections to moving this WebGL extension into draft state? I don't suspect there would be... No objections to incorporating a conformance test for it as long as it passes without the extension being available and is prefixed with a minimum version of 1.0.2. -Ken On Thu, Feb 23, 2012 at 6:03 AM, Florian B?sch wrote: > A patch to introduce this extension has been accepted by Mozilla to > mozilla-inbound:?https://bugzilla.mozilla.org/show_bug.cgi?id=728354 > > - The extension name MOZ_EXT_texture_filter_anisotropic is used by firefox. > - A conformance test has been added for this > feature:?http://hg.mozilla.org/integration/mozilla-inbound/diff/a6dfdf5a529d/content/canvas/test/webgl/ext-texture-filter-anisotropic.patch > - Is it possible to accept this conformance test upstream to the Khronos > conformance test suite? > - A demo for anisotropic filtering is available > at:?http://codeflow.org/webgl/anisotropy/ > - Sample picture of the demo:?http://codeflow.org/pictures/anisotropy.jpg > > Example Code: > > var ext = gl.getExtension('MOZ_EXT_texture_filter_anisotropic'); > if(ext){ > ? ? var max = gl.getParameter(ext.MAX_TEXTURE_MAX_ANISOTROPY); > ? ? gl.texParameterf(target, ext.TEXTURE_MAX_ANISOTROPY, max); > } > > Angle OpenGL works fine, but Direct3D support is not yet there for this > feature, requirement described > there:?http://code.google.com/p/angleproject/issues/detail?id=297 > ----------------------------------------------------------- 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...@ Thu Feb 23 18:52:05 2012 From: bja...@ (Benoit Jacob) Date: Thu, 23 Feb 2012 18:52:05 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <698370369.844252.1330051925521.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > The extension should be in "draft" state, not "proposed" state, > before > anyone implements it. Ah OK. Anyway, as Florian said in his email, he's just implemented it in Mozilla. > See the very clear "DO NOT IMPLEMENT!" at the > top of > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/EXT_texture_filter_anisotropic/index.html > . I admit I was a bit confused by that. The draft seemed good enough for an implementation as an experimental (vendor-prefixed) extension. There doesn't seem to be much to argue about, in this extension spec. Is now the right time to drop the "DO NOT IMPLEMENT!" and keep it in "proposed" state? Benoit > > Are there any objections to moving this WebGL extension into draft > state? I don't suspect there would be... > > No objections to incorporating a conformance test for it as long as > it > passes without the extension being available and is prefixed with a > minimum version of 1.0.2. > > -Ken > > > On Thu, Feb 23, 2012 at 6:03 AM, Florian B?sch > wrote: > > A patch to introduce this extension has been accepted by Mozilla to > > mozilla-inbound: > > ?https://bugzilla.mozilla.org/show_bug.cgi?id=728354 > > > > - The extension name MOZ_EXT_texture_filter_anisotropic is used by > > firefox. > > - A conformance test has been added for this > > feature: > > ?http://hg.mozilla.org/integration/mozilla-inbound/diff/a6dfdf5a529d/content/canvas/test/webgl/ext-texture-filter-anisotropic.patch > > - Is it possible to accept this conformance test upstream to the > > Khronos > > conformance test suite? > > - A demo for anisotropic filtering is available > > at:?http://codeflow.org/webgl/anisotropy/ > > - Sample picture of the demo: > > ?http://codeflow.org/pictures/anisotropy.jpg > > > > Example Code: > > > > var ext = gl.getExtension('MOZ_EXT_texture_filter_anisotropic'); > > if(ext){ > > ? ? var max = gl.getParameter(ext.MAX_TEXTURE_MAX_ANISOTROPY); > > ? ? gl.texParameterf(target, ext.TEXTURE_MAX_ANISOTROPY, max); > > } > > > > Angle OpenGL works fine, but Direct3D support is not yet there for > > this > > feature, requirement described > > there:?http://code.google.com/p/angleproject/issues/detail?id=297 > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Feb 23 18:54:48 2012 From: kbr...@ (Kenneth Russell) Date: Thu, 23 Feb 2012 18:54:48 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <698370369.844252.1330051925521.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <698370369.844252.1330051925521.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, Feb 23, 2012 at 6:52 PM, Benoit Jacob wrote: > > > ----- Original Message ----- >> The extension should be in "draft" state, not "proposed" state, >> before >> anyone implements it. > > Ah OK. Anyway, as Florian said in his email, he's just implemented it in Mozilla. > >> See the very clear "DO NOT IMPLEMENT!" at the >> top of >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/EXT_texture_filter_anisotropic/index.html >> . > > I admit I was a bit confused by that. The draft seemed good enough for an implementation as an experimental (vendor-prefixed) extension. There doesn't seem to be much to argue about, in this extension spec. Is now the right time to drop the "DO NOT IMPLEMENT!" and keep it in "proposed" state? Gregg specifically added the "do not implement" text for proposals. Drafts don't contain that text. All that's needed to change the state is change one keyword in the extension.xml, move it out of the "proposals" folder and re-run make. Are there any objections to doing that? -Ken > Benoit > >> >> Are there any objections to moving this WebGL extension into draft >> state? I don't suspect there would be... >> >> No objections to incorporating a conformance test for it as long as >> it >> passes without the extension being available and is prefixed with a >> minimum version of 1.0.2. >> >> -Ken >> >> >> On Thu, Feb 23, 2012 at 6:03 AM, Florian B?sch >> wrote: >> > A patch to introduce this extension has been accepted by Mozilla to >> > mozilla-inbound: >> > ?https://bugzilla.mozilla.org/show_bug.cgi?id=728354 >> > >> > - The extension name MOZ_EXT_texture_filter_anisotropic is used by >> > firefox. >> > - A conformance test has been added for this >> > feature: >> > ?http://hg.mozilla.org/integration/mozilla-inbound/diff/a6dfdf5a529d/content/canvas/test/webgl/ext-texture-filter-anisotropic.patch >> > - Is it possible to accept this conformance test upstream to the >> > Khronos >> > conformance test suite? >> > - A demo for anisotropic filtering is available >> > at:?http://codeflow.org/webgl/anisotropy/ >> > - Sample picture of the demo: >> > ?http://codeflow.org/pictures/anisotropy.jpg >> > >> > Example Code: >> > >> > var ext = gl.getExtension('MOZ_EXT_texture_filter_anisotropic'); >> > if(ext){ >> > ? ? var max = gl.getParameter(ext.MAX_TEXTURE_MAX_ANISOTROPY); >> > ? ? gl.texParameterf(target, ext.TEXTURE_MAX_ANISOTROPY, max); >> > } >> > >> > Angle OpenGL works fine, but Direct3D support is not yet there for >> > this >> > feature, requirement described >> > there:?http://code.google.com/p/angleproject/issues/detail?id=297 >> > >> ----------------------------------------------------------- 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...@ Thu Feb 23 18:57:50 2012 From: bja...@ (Benoit Jacob) Date: Thu, 23 Feb 2012 18:57:50 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <601630216.844469.1330052270954.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Thu, Feb 23, 2012 at 6:52 PM, Benoit Jacob > wrote: > > > > > > ----- Original Message ----- > >> The extension should be in "draft" state, not "proposed" state, > >> before > >> anyone implements it. > > > > Ah OK. Anyway, as Florian said in his email, he's just implemented > > it in Mozilla. > > > >> See the very clear "DO NOT IMPLEMENT!" at the > >> top of > >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/EXT_texture_filter_anisotropic/index.html > >> . > > > > I admit I was a bit confused by that. The draft seemed good enough > > for an implementation as an experimental (vendor-prefixed) > > extension. There doesn't seem to be much to argue about, in this > > extension spec. Is now the right time to drop the "DO NOT > > IMPLEMENT!" and keep it in "proposed" state? > > Gregg specifically added the "do not implement" text for proposals. > Drafts don't contain that text. All that's needed to change the state > is change one keyword in the extension.xml, move it out of the > "proposals" folder and re-run make. Are there any objections to doing > that? No objection! Sorry I got it the wrong way around, in my previous email. Of course, I'm OK to move it to "draft" state. Benoit > > -Ken > > > > Benoit > > > >> > >> Are there any objections to moving this WebGL extension into draft > >> state? I don't suspect there would be... > >> > >> No objections to incorporating a conformance test for it as long > >> as > >> it > >> passes without the extension being available and is prefixed with > >> a > >> minimum version of 1.0.2. > >> > >> -Ken > >> > >> > >> On Thu, Feb 23, 2012 at 6:03 AM, Florian B?sch > >> wrote: > >> > A patch to introduce this extension has been accepted by Mozilla > >> > to > >> > mozilla-inbound: > >> > ?https://bugzilla.mozilla.org/show_bug.cgi?id=728354 > >> > > >> > - The extension name MOZ_EXT_texture_filter_anisotropic is used > >> > by > >> > firefox. > >> > - A conformance test has been added for this > >> > feature: > >> > ?http://hg.mozilla.org/integration/mozilla-inbound/diff/a6dfdf5a529d/content/canvas/test/webgl/ext-texture-filter-anisotropic.patch > >> > - Is it possible to accept this conformance test upstream to the > >> > Khronos > >> > conformance test suite? > >> > - A demo for anisotropic filtering is available > >> > at:?http://codeflow.org/webgl/anisotropy/ > >> > - Sample picture of the demo: > >> > ?http://codeflow.org/pictures/anisotropy.jpg > >> > > >> > Example Code: > >> > > >> > var ext = gl.getExtension('MOZ_EXT_texture_filter_anisotropic'); > >> > if(ext){ > >> > ? ? var max = gl.getParameter(ext.MAX_TEXTURE_MAX_ANISOTROPY); > >> > ? ? gl.texParameterf(target, ext.TEXTURE_MAX_ANISOTROPY, max); > >> > } > >> > > >> > Angle OpenGL works fine, but Direct3D support is not yet there > >> > for > >> > this > >> > feature, requirement described > >> > there: > >> > ?http://code.google.com/p/angleproject/issues/detail?id=297 > >> > > >> > ----------------------------------------------------------- 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 nia...@ Thu Feb 23 23:20:55 2012 From: nia...@ (Niaz Jalal) Date: Thu, 23 Feb 2012 23:20:55 -0800 Subject: [Public WebGL] WebGL conformance tests Message-ID: Hi. Can someone point me to the latest conformance test suite? What is the state of the test suite, is it locked down or is it still changing? Where is information on the conformance certification process? Thanks a lot, -- Niaz Jalal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jia...@ Fri Feb 24 00:14:18 2012 From: jia...@ (Zhao, Jian J) Date: Fri, 24 Feb 2012 08:14:18 +0000 Subject: [Public WebGL] WebGL conformance tests In-Reply-To: References: Message-ID: <5F4298C27433CC49837972C794A4FD43101F4BD8@SHSMSX102.ccr.corp.intel.com> As I know the latest conformance test suite is at: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html. And it is still changing with many new cases added in. Best regards zhaojian From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Niaz Jalal Sent: Friday, February 24, 2012 3:21 PM To: public_webgl...@ Subject: [Public WebGL] WebGL conformance tests Hi. Can someone point me to the latest conformance test suite? What is the state of the test suite, is it locked down or is it still changing? Where is information on the conformance certification process? Thanks a lot, -- Niaz Jalal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 02:01:28 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Feb 2012 11:01:28 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell wrote: > Are there any objections to moving this WebGL extension into draft > state? I don't suspect there would be... > No objection. > No objections to incorporating a conformance test for it as long as it > passes without the extension being available This behavior is implemented by the conformance test. For cross-vendor support the queried extension would have to be either of MOZ_EXT_texture_filter_anisotropic, WEBKIT_EXT_texture_filter_anisotropic or EXT_texture_filter_anisotropic, do you want me to provide a patch to the conformance test for that? > and is prefixed with a > minimum version of 1.0.2. > How do I prefix the test? All that's needed to change the state > is change one keyword in the extension.xml, move it out of the > "proposals" folder and re-run make. Should I provide the patch to the specification? As to the life/implementation of specifications, I'm not entirely clear on how that works. So I propose the following (arguable) formalization: Lifecycle of an extension: proposal -> draft -> ratified Lifecycle of implementations: - proposal: may implement but with vendor prefix, implementation is subject to removal again if failing to move on to draft. - draft: may implement without vendor prefix, implementation is subject to removal again if failing to move on to ratified. - ratified: should implement without vendor prefix, implementation may not be removed again, web-developers can now trust this being supported by vendors. Please help me get this formalized to everybodies satisfaction, so we can create an extension guide from it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Feb 24 10:21:00 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Feb 2012 10:21:00 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: On Fri, Feb 24, 2012 at 2:01 AM, Florian B?sch wrote: > > > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell wrote: >> >> Are there any objections to moving this WebGL extension into draft >> state? I don't suspect there would be... > > No objection. > >> >> No objections to incorporating a conformance test for it as long as it >> passes without the extension being available > > This behavior is implemented by the conformance test. For cross-vendor > support the queried extension would have to be either of > MOZ_EXT_texture_filter_anisotropic, WEBKIT_EXT_texture_filter_anisotropic or > EXT_texture_filter_anisotropic, do you want me to provide a patch to the > conformance test for that? > >> >> and is prefixed with a >> minimum version of 1.0.2. > > How do I prefix the test? > >> ?All that's needed to change the state >> is change one keyword in the extension.xml, move it out of the >> "proposals" folder and re-run make. > > Should I provide the patch to the specification? > > > As to the life/implementation of specifications, I'm not entirely clear on > how that works. So I propose the following (arguable) formalization: > > Lifecycle of an extension: proposal -> draft -> ratified > Lifecycle of implementations: > - proposal: may implement but with vendor prefix, implementation is subject > to removal again if failing to move on to draft. > - draft: may implement without vendor prefix, implementation is subject to > removal again if failing to move on to ratified. > - ratified: should implement without vendor prefix, implementation may not > be removed again, web-developers can now trust this being supported by > vendors. > > Please help me get this formalized to everybodies satisfaction, so we can > create an extension guide from it. Agree that we should formalize the process. I believe the implementation lifetime should be as follows: - Proposal: for discussion on the public mailing list only, in order to move to draft status. Must not be implemented by any vendor in this form. - Draft: may be implemented with vendor prefix. For experimentation purposes, to gain experience with the extension before finalizing. - Ratified: should be implemented without vendor prefix. Should not be removed except if there is a security issue or similar. Thoughts? Also, I'd like to propose we move OES_element_index_uint and WEBGL_depth_texture from proposal state to draft state; these seem non-controversial. Objections or support? https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ -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...@ Fri Feb 24 10:25:28 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Feb 2012 10:25:28 -0800 Subject: [Public WebGL] WebGL conformance tests In-Reply-To: <5F4298C27433CC49837972C794A4FD43101F4BD8@SHSMSX102.ccr.corp.intel.com> References: <5F4298C27433CC49837972C794A4FD43101F4BD8@SHSMSX102.ccr.corp.intel.com> Message-ID: That's the correct location of the current version of the conformance tests. That version is under active development, so expect that there will be test cases that will fail. Periodically a snapshot is taken for a particular version of the specification. The snapshot for the upcoming version 1.0.1 of the spec was just taken. It isn't completely finalized; bug fixing work in the 1.0.1 version may still occur. I'll send more information about this to the mailing list shortly. -Ken On Fri, Feb 24, 2012 at 12:14 AM, Zhao, Jian J wrote: > As I know the latest conformance test suite is at: > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html. > And it is still changing with many new cases added in. > > > > Best regards > > zhaojian > > > > From: owner-public_webgl...@ [mailto:owner-public_webgl...@] > On Behalf Of Niaz Jalal > Sent: Friday, February 24, 2012 3:21 PM > To: public_webgl...@ > Subject: [Public WebGL] WebGL conformance tests > > > > Hi. > > > > Can someone point me to the latest conformance test suite? What is the state > of the test suite, is it locked down or is it still changing? ?Where is > information on the conformance certification process? > > > Thanks a lot, > > > > -- Niaz Jalal ----------------------------------------------------------- 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...@ Fri Feb 24 10:36:17 2012 From: bja...@ (Benoit Jacob) Date: Fri, 24 Feb 2012 10:36:17 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <682080134.1142924.1330108577156.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> > Agree that we should formalize the process. I believe the > implementation lifetime should be as follows: > > - Proposal: for discussion on the public mailing list only, in > order > to move to draft status. Must not be implemented by any vendor in > this > form. > - Draft: may be implemented with vendor prefix. For experimentation > purposes, to gain experience with the extension before finalizing. > - Ratified: should be implemented without vendor prefix. Should not > be removed except if there is a security issue or similar. > > Thoughts? OK to formalize the notion that proposals should be made drafts before implementation starts (will do next time). Could we also formalize that once an extension is ratified, not only it should be implemented without vendor prefix, but any browser that already has an implementation with prefix should remove support for the prefixed extension string as soon as possible, even if this breaks content? > > Also, I'd like to propose we move OES_element_index_uint and > WEBGL_depth_texture from proposal state to draft state; these seem > non-controversial. Objections or support? About OES_element_index_uint, is there a use case where this is a significant performance win, or is this is just a convenience extension? Is it worth the portability issues it introduces? I support depth textures. Benoit > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ > http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > > -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 bag...@ Fri Feb 24 10:35:31 2012 From: bag...@ (Patrick Baggett) Date: Fri, 24 Feb 2012 12:35:31 -0600 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: On Fri, Feb 24, 2012 at 12:21 PM, Kenneth Russell wrote: > > On Fri, Feb 24, 2012 at 2:01 AM, Florian B?sch wrote: > > > > > > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell wrote: > >> > >> Are there any objections to moving this WebGL extension into draft > >> state? I don't suspect there would be... > > > > No objection. > > > >> > >> No objections to incorporating a conformance test for it as long as it > >> passes without the extension being available > > > > This behavior is implemented by the conformance test. For cross-vendor > > support the queried extension would have to be either of > > MOZ_EXT_texture_filter_anisotropic, > WEBKIT_EXT_texture_filter_anisotropic or > > EXT_texture_filter_anisotropic, do you want me to provide a patch to the > > conformance test for that? > > > >> > >> and is prefixed with a > >> minimum version of 1.0.2. > > > > How do I prefix the test? > > > >> All that's needed to change the state > >> is change one keyword in the extension.xml, move it out of the > >> "proposals" folder and re-run make. > > > > Should I provide the patch to the specification? > > > > > > As to the life/implementation of specifications, I'm not entirely clear > on > > how that works. So I propose the following (arguable) formalization: > > > > Lifecycle of an extension: proposal -> draft -> ratified > > Lifecycle of implementations: > > - proposal: may implement but with vendor prefix, implementation is > subject > > to removal again if failing to move on to draft. > > - draft: may implement without vendor prefix, implementation is subject > to > > removal again if failing to move on to ratified. > > - ratified: should implement without vendor prefix, implementation may > not > > be removed again, web-developers can now trust this being supported by > > vendors. > > > > Please help me get this formalized to everybodies satisfaction, so we can > > create an extension guide from it. > > Agree that we should formalize the process. I believe the > implementation lifetime should be as follows: > > - Proposal: for discussion on the public mailing list only, in order > to move to draft status. Must not be implemented by any vendor in this > form. > - Draft: may be implemented with vendor prefix. For experimentation > purposes, to gain experience with the extension before finalizing. > - Ratified: should be implemented without vendor prefix. Should not > be removed except if there is a security issue or similar. > > Thoughts? > > Also, I'd like to propose we move OES_element_index_uint and > WEBGL_depth_texture from proposal state to draft state; these seem > non-controversial. Objections or support? > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ > > http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ > > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > > I know it seems consistent to do OES_element_index_uint.UNSIGNED_INT, but will this token be duplicated later? Isn't it sufficient to simply allow UNSIGNED_INT where the extension allows it? > -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Feb 24 10:38:39 2012 From: bja...@ (Benoit Jacob) Date: Fri, 24 Feb 2012 10:38:39 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Fri, Feb 24, 2012 at 12:21 PM, Kenneth Russell < kbr...@ > > wrote: > > On Fri, Feb 24, 2012 at 2:01 AM, Florian B?sch < pyalot...@ > > > wrote: > > > > > > > > > > > > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell < kbr...@ > > > > > > > wrote: > > > >> > > > >> Are there any objections to moving this WebGL extension into > > >> draft > > > >> state? I don't suspect there would be... > > > > > > > > No objection. > > > > > > > >> > > > >> No objections to incorporating a conformance test for it as long > > >> as it > > > >> passes without the extension being available > > > > > > > > This behavior is implemented by the conformance test. For > > > cross-vendor > > > > support the queried extension would have to be either of > > > > MOZ_EXT_texture_filter_anisotropic, > > > WEBKIT_EXT_texture_filter_anisotropic or > > > > EXT_texture_filter_anisotropic, do you want me to provide a patch > > > to the > > > > conformance test for that? > > > > > > > >> > > > >> and is prefixed with a > > > >> minimum version of 1.0.2. > > > > > > > > How do I prefix the test? > > > > > > > >> All that's needed to change the state > > > >> is change one keyword in the extension.xml, move it out of the > > > >> "proposals" folder and re-run make. > > > > > > > > Should I provide the patch to the specification? > > > > > > > > > > > > As to the life/implementation of specifications, I'm not entirely > > > clear on > > > > how that works. So I propose the following (arguable) > > > formalization: > > > > > > > > Lifecycle of an extension: proposal -> draft -> ratified > > > > Lifecycle of implementations: > > > > - proposal: may implement but with vendor prefix, implementation > > > is > > > subject > > > > to removal again if failing to move on to draft. > > > > - draft: may implement without vendor prefix, implementation is > > > subject to > > > > removal again if failing to move on to ratified. > > > > - ratified: should implement without vendor prefix, > > > implementation > > > may not > > > > be removed again, web-developers can now trust this being > > > supported > > > by > > > > vendors. > > > > > > > > Please help me get this formalized to everybodies satisfaction, > > > so > > > we can > > > > create an extension guide from it. > > > Agree that we should formalize the process. I believe the > > > implementation lifetime should be as follows: > > > - Proposal: for discussion on the public mailing list only, in > > order > > > to move to draft status. Must not be implemented by any vendor in > > this > > > form. > > > - Draft: may be implemented with vendor prefix. For experimentation > > > purposes, to gain experience with the extension before finalizing. > > > - Ratified: should be implemented without vendor prefix. Should not > > > be removed except if there is a security issue or similar. > > > Thoughts? > > > Also, I'd like to propose we move OES_element_index_uint and > > > WEBGL_depth_texture from proposal state to draft state; these seem > > > non-controversial. Objections or support? > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ > > > http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ > > > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > > I know it seems consistent to do OES_element_index_uint.UNSIGNED_INT, > but will this token be duplicated later? Isn't it sufficient to > simply allow UNSIGNED_INT where the extension allows it? Would that mean that the getExtension calls adds a new property to the existing context object? That sounds a bit scary, and has corner cases that I'm not sure how to specify. What happens if the user has already defined a UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it on the extension object. Benoit > > -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 > > > ----------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 10:40:03 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Feb 2012 19:40:03 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: On Fri, Feb 24, 2012 at 7:21 PM, Kenneth Russell wrote: > Agree that we should formalize the process. I believe the > implementation lifetime should be as follows: > > - Proposal: for discussion on the public mailing list only, in order > to move to draft status. Must not be implemented by any vendor in this > form. > - Draft: may be implemented with vendor prefix. For experimentation > purposes, to gain experience with the extension before finalizing. > - Ratified: should be implemented without vendor prefix. Should not > be removed except if there is a security issue or similar. > > Thoughts? > I think that's fine, but it would need some definition as to how things move into proposal and into draft. I'd also like to suggest extensions get a champion or somesuch, which is basically the go-to person for questions about it and who is interested to supply patches to the specification, implementations and conformance tests. Also, I'd like to propose we move OES_element_index_uint and > WEBGL_depth_texture from proposal state to draft state; these seem > non-controversial. Objections or support? > No objection to move these to draft state. They're both a little more involved to implement and the sooner we start, the sooner we'll have some test implementations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bag...@ Fri Feb 24 10:40:49 2012 From: bag...@ (Patrick Baggett) Date: Fri, 24 Feb 2012 12:40:49 -0600 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: > > > Would that mean that the getExtension calls adds a new property to the > existing context object? That sounds a bit scary, and has corner cases that > I'm not sure how to specify. What happens if the user has already defined a > UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it > on the extension object. > > I was thinking that the context would already have the UNSIGNED_INT property, which would simply be rejected unless the extension was enabled. It doesn't seem like UNSIGNED_INT is really specific to that extension. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Feb 24 10:42:16 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 10:42:16 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Wait, UNSIGNED_INT is already defined on WebGL context. I'd *strongly* prefer not to have it on the extension object. On Fri, Feb 24, 2012 at 10:38 AM, Benoit Jacob wrote: > > > ------------------------------ > > > > On Fri, Feb 24, 2012 at 12:21 PM, Kenneth Russell wrote: > >> >> On Fri, Feb 24, 2012 at 2:01 AM, Florian B?sch wrote: >> > >> > >> > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell >> wrote: >> >> >> >> Are there any objections to moving this WebGL extension into draft >> >> state? I don't suspect there would be... >> > >> > No objection. >> > >> >> >> >> No objections to incorporating a conformance test for it as long as it >> >> passes without the extension being available >> > >> > This behavior is implemented by the conformance test. For cross-vendor >> > support the queried extension would have to be either of >> > MOZ_EXT_texture_filter_anisotropic, >> WEBKIT_EXT_texture_filter_anisotropic or >> > EXT_texture_filter_anisotropic, do you want me to provide a patch to the >> > conformance test for that? >> > >> >> >> >> and is prefixed with a >> >> minimum version of 1.0.2. >> > >> > How do I prefix the test? >> > >> >> All that's needed to change the state >> >> is change one keyword in the extension.xml, move it out of the >> >> "proposals" folder and re-run make. >> > >> > Should I provide the patch to the specification? >> > >> > >> > As to the life/implementation of specifications, I'm not entirely clear >> on >> > how that works. So I propose the following (arguable) formalization: >> > >> > Lifecycle of an extension: proposal -> draft -> ratified >> > Lifecycle of implementations: >> > - proposal: may implement but with vendor prefix, implementation is >> subject >> > to removal again if failing to move on to draft. >> > - draft: may implement without vendor prefix, implementation is subject >> to >> > removal again if failing to move on to ratified. >> > - ratified: should implement without vendor prefix, implementation may >> not >> > be removed again, web-developers can now trust this being supported by >> > vendors. >> > >> > Please help me get this formalized to everybodies satisfaction, so we >> can >> > create an extension guide from it. >> >> Agree that we should formalize the process. I believe the >> implementation lifetime should be as follows: >> >> - Proposal: for discussion on the public mailing list only, in order >> to move to draft status. Must not be implemented by any vendor in this >> form. >> - Draft: may be implemented with vendor prefix. For experimentation >> purposes, to gain experience with the extension before finalizing. >> - Ratified: should be implemented without vendor prefix. Should not >> be removed except if there is a security issue or similar. >> >> Thoughts? >> >> Also, I'd like to propose we move OES_element_index_uint and >> WEBGL_depth_texture from proposal state to draft state; these seem >> non-controversial. Objections or support? >> >> >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ >> >> http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ >> >> http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ >> >> > I know it seems consistent to do OES_element_index_uint.UNSIGNED_INT, but > will this token be duplicated later? Isn't it sufficient to simply allow > UNSIGNED_INT where the extension allows it? > > Would that mean that the getExtension calls adds a new property to the > existing context object? That sounds a bit scary, and has corner cases that > I'm not sure how to specify. What happens if the user has already defined a > UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it > on the extension object. > > Benoit > > > > > >> -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 >> ----------------------------------------------------------- >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Feb 24 10:43:15 2012 From: bja...@ (Benoit Jacob) Date: Fri, 24 Feb 2012 10:43:15 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > > Would that mean that the getExtension calls adds a new property to > > the existing context object? That sounds a bit scary, and has > > corner > > cases that I'm not sure how to specify. What happens if the user > > has > > already defined a UNSIGNED_INT property on it? Should it then be > > replaced? I'd rather keep it on the extension object. > > I was thinking that the context would already have the UNSIGNED_INT > property, which would simply be rejected unless the extension was > enabled. It doesn't seem like UNSIGNED_INT is really specific to > that extension. OK, that's sensible, the only problem is that this requires a new version of the WebGL spec, as opposed to just requiring an extension. _If_ there is consensus that we want the index_uint extension, then I'd be OK with your proposal for 1.0.2. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Feb 24 10:45:28 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 10:45:28 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Correct. Looks like depth_texture also defines its own versions of constants already defined on the main GL context, and they seems redundant there, too. On Fri, Feb 24, 2012 at 10:40 AM, Patrick Baggett wrote: > >> Would that mean that the getExtension calls adds a new property to the >> existing context object? That sounds a bit scary, and has corner cases that >> I'm not sure how to specify. What happens if the user has already defined a >> UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it >> on the extension object. >> >> > I was thinking that the context would already have the UNSIGNED_INT > property, which would simply be rejected unless the extension was enabled. > It doesn't seem like UNSIGNED_INT is really specific to that extension. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Feb 24 10:44:02 2012 From: bja...@ (Benoit Jacob) Date: Fri, 24 Feb 2012 10:44:02 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <1590313085.1164144.1330109042530.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > Wait, UNSIGNED_INT is already defined on WebGL context. Dang! It is. That's what I didn't realize. Thanks! Benoit > I'd *strongly* prefer not to have it on the extension object. > On Fri, Feb 24, 2012 at 10:38 AM, Benoit Jacob < bjacob...@ > > wrote: > > > On Fri, Feb 24, 2012 at 12:21 PM, Kenneth Russell < > > > kbr...@ > > > > > > > wrote: > > > > > > > On Fri, Feb 24, 2012 at 2:01 AM, Florian B?sch < > > > > pyalot...@ > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Feb 24, 2012 at 3:16 AM, Kenneth Russell < > > > > > kbr...@ > > > > > > > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > >> Are there any objections to moving this WebGL extension into > > > > >> draft > > > > > > > > > > >> state? I don't suspect there would be... > > > > > > > > > > > > > > > > > > > > > > No objection. > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > >> No objections to incorporating a conformance test for it as > > > > >> long > > > > >> as it > > > > > > > > > > >> passes without the extension being available > > > > > > > > > > > > > > > > > > > > > > This behavior is implemented by the conformance test. For > > > > > cross-vendor > > > > > > > > > > > support the queried extension would have to be either of > > > > > > > > > > > MOZ_EXT_texture_filter_anisotropic, > > > > > WEBKIT_EXT_texture_filter_anisotropic or > > > > > > > > > > > EXT_texture_filter_anisotropic, do you want me to provide a > > > > > patch > > > > > to the > > > > > > > > > > > conformance test for that? > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > >> and is prefixed with a > > > > > > > > > > >> minimum version of 1.0.2. > > > > > > > > > > > > > > > > > > > > > > How do I prefix the test? > > > > > > > > > > > > > > > > > > > > > >> All that's needed to change the state > > > > > > > > > > >> is change one keyword in the extension.xml, move it out of > > > > >> the > > > > > > > > > > >> "proposals" folder and re-run make. > > > > > > > > > > > > > > > > > > > > > > Should I provide the patch to the specification? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As to the life/implementation of specifications, I'm not > > > > > entirely > > > > > clear on > > > > > > > > > > > how that works. So I propose the following (arguable) > > > > > formalization: > > > > > > > > > > > > > > > > > > > > > > Lifecycle of an extension: proposal -> draft -> ratified > > > > > > > > > > > Lifecycle of implementations: > > > > > > > > > > > - proposal: may implement but with vendor prefix, > > > > > implementation > > > > > is > > > > > subject > > > > > > > > > > > to removal again if failing to move on to draft. > > > > > > > > > > > - draft: may implement without vendor prefix, implementation > > > > > is > > > > > subject to > > > > > > > > > > > removal again if failing to move on to ratified. > > > > > > > > > > > - ratified: should implement without vendor prefix, > > > > > implementation > > > > > may not > > > > > > > > > > > be removed again, web-developers can now trust this being > > > > > supported > > > > > by > > > > > > > > > > > vendors. > > > > > > > > > > > > > > > > > > > > > > Please help me get this formalized to everybodies > > > > > satisfaction, > > > > > so > > > > > we can > > > > > > > > > > > create an extension guide from it. > > > > > > > > > > Agree that we should formalize the process. I believe the > > > > > > > > > > implementation lifetime should be as follows: > > > > > > > > > > - Proposal: for discussion on the public mailing list only, in > > > > order > > > > > > > > > > to move to draft status. Must not be implemented by any vendor > > > > in > > > > this > > > > > > > > > > form. > > > > > > > > > > - Draft: may be implemented with vendor prefix. For > > > > experimentation > > > > > > > > > > purposes, to gain experience with the extension before > > > > finalizing. > > > > > > > > > > - Ratified: should be implemented without vendor prefix. Should > > > > not > > > > > > > > > > be removed except if there is a security issue or similar. > > > > > > > > > > Thoughts? > > > > > > > > > > Also, I'd like to propose we move OES_element_index_uint and > > > > > > > > > > WEBGL_depth_texture from proposal state to draft state; these > > > > seem > > > > > > > > > > non-controversial. Objections or support? > > > > > > > > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ > > > > > > > > > > http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ > > > > > > > > > > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > > > > > > > > > I know it seems consistent to do > > > OES_element_index_uint.UNSIGNED_INT, > > > but will this token be duplicated later? Isn't it sufficient to > > > simply allow UNSIGNED_INT where the extension allows it? > > > > > Would that mean that the getExtension calls adds a new property to > > the existing context object? That sounds a bit scary, and has > > corner > > cases that I'm not sure how to specify. What happens if the user > > has > > already defined a UNSIGNED_INT property on it? Should it then be > > replaced? I'd rather keep it on the extension object. > > > Benoit > > > > > -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 > > > > > > > > > > ----------------------------------------------------------- > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Feb 24 10:46:55 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo5YukKQ==?=) Date: Fri, 24 Feb 2012 10:46:55 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1344758967.1160748.1330108719781.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Yes, there's no reason to have UNSIGNED_INT on the OES_element_index_uint object. See OES_texture_float. It has no new contants. It uses the existing constant from WebGLRenderingContext On Fri, Feb 24, 2012 at 10:40 AM, Patrick Baggett wrote: > >> Would that mean that the getExtension calls adds a new property to the >> existing context object? That sounds a bit scary, and has corner cases that >> I'm not sure how to specify. What happens if the user has already defined a >> UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it >> on the extension object. >> >> > I was thinking that the context would already have the UNSIGNED_INT > property, which would simply be rejected unless the extension was enabled. > It doesn't seem like UNSIGNED_INT is really specific to that extension. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bag...@ Fri Feb 24 10:45:51 2012 From: bag...@ (Patrick Baggett) Date: Fri, 24 Feb 2012 12:45:51 -0600 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 12:43 PM, Benoit Jacob wrote: > > > ------------------------------ > > >> Would that mean that the getExtension calls adds a new property to the >> existing context object? That sounds a bit scary, and has corner cases that >> I'm not sure how to specify. What happens if the user has already defined a >> UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it >> on the extension object. >> >> > I was thinking that the context would already have the UNSIGNED_INT > property, which would simply be rejected unless the extension was enabled. > It doesn't seem like UNSIGNED_INT is really specific to that extension. > > OK, that's sensible, the only problem is that this requires a new version > of the WebGL spec, as opposed to just requiring an extension. _If_ there is > consensus that we want the index_uint extension, then I'd be OK with your > proposal for 1.0.2. > How does that require amending the spec? To write "UNSIGNED_INT" is allowed if this extension is enabled? Isn't that the purpose of the extension text? Anyways, if you specify "FLOAT", it is rejected; why would it require explicit language for negative cases? > > > Benoit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Feb 24 10:47:19 2012 From: bja...@ (Benoit Jacob) Date: Fri, 24 Feb 2012 10:47:19 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <395889802.1166827.1330109239768.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Fri, Feb 24, 2012 at 12:43 PM, Benoit Jacob < bjacob...@ > > wrote: > > > > Would that mean that the getExtension calls adds a new property > > > > to > > > > the existing context object? That sounds a bit scary, and has > > > > corner > > > > cases that I'm not sure how to specify. What happens if the > > > > user > > > > has > > > > already defined a UNSIGNED_INT property on it? Should it then > > > > be > > > > replaced? I'd rather keep it on the extension object. > > > > > > > > > I was thinking that the context would already have the > > > UNSIGNED_INT > > > property, which would simply be rejected unless the extension was > > > enabled. It doesn't seem like UNSIGNED_INT is really specific to > > > that extension. > > > > > OK, that's sensible, the only problem is that this requires a new > > version of the WebGL spec, as opposed to just requiring an > > extension. _If_ there is consensus that we want the index_uint > > extension, then I'd be OK with your proposal for 1.0.2. > > How does that require amending the spec? To write "UNSIGNED_INT" is > allowed if this extension is enabled? Isn't that the purpose of the > extension text? Anyways, if you specify "FLOAT", it is rejected; why > would it require explicit language for negative cases? See my reply to Ben Vanik --- I didn't realize that UNSIGNED_INT was already in the current spec. Benoit > > Benoit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Feb 24 10:52:22 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 10:52:22 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Indeed. Benoit - these constants are already defined on WebGLRenderingContext, and with the same constant values. No need to bump the spec. Hooray less work! On Fri, Feb 24, 2012 at 10:45 AM, Patrick Baggett wrote: > > > On Fri, Feb 24, 2012 at 12:43 PM, Benoit Jacob wrote: > >> >> >> ------------------------------ >> >> >>> Would that mean that the getExtension calls adds a new property to the >>> existing context object? That sounds a bit scary, and has corner cases that >>> I'm not sure how to specify. What happens if the user has already defined a >>> UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it >>> on the extension object. >>> >>> >> I was thinking that the context would already have the UNSIGNED_INT >> property, which would simply be rejected unless the extension was enabled. >> It doesn't seem like UNSIGNED_INT is really specific to that extension. >> >> OK, that's sensible, the only problem is that this requires a new version >> of the WebGL spec, as opposed to just requiring an extension. _If_ there is >> consensus that we want the index_uint extension, then I'd be OK with your >> proposal for 1.0.2. >> > > How does that require amending the spec? To write "UNSIGNED_INT" is > allowed if this extension is enabled? Isn't that the purpose of the > extension text? Anyways, if you specify "FLOAT", it is rejected; why would > it require explicit language for negative cases? > > >> >> >> Benoit >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bag...@ Fri Feb 24 10:48:03 2012 From: bag...@ (Patrick Baggett) Date: Fri, 24 Feb 2012 12:48:03 -0600 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <395889802.1166827.1330109239768.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <395889802.1166827.1330109239768.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 12:47 PM, Benoit Jacob wrote: > > > ------------------------------ > > > > On Fri, Feb 24, 2012 at 12:43 PM, Benoit Jacob wrote: > >> >> >> ------------------------------ >> >> >>> Would that mean that the getExtension calls adds a new property to the >>> existing context object? That sounds a bit scary, and has corner cases that >>> I'm not sure how to specify. What happens if the user has already defined a >>> UNSIGNED_INT property on it? Should it then be replaced? I'd rather keep it >>> on the extension object. >>> >>> >> I was thinking that the context would already have the UNSIGNED_INT >> property, which would simply be rejected unless the extension was enabled. >> It doesn't seem like UNSIGNED_INT is really specific to that extension. >> >> OK, that's sensible, the only problem is that this requires a new version >> of the WebGL spec, as opposed to just requiring an extension. _If_ there is >> consensus that we want the index_uint extension, then I'd be OK with your >> proposal for 1.0.2. >> > > How does that require amending the spec? To write "UNSIGNED_INT" is > allowed if this extension is enabled? Isn't that the purpose of the > extension text? Anyways, if you specify "FLOAT", it is rejected; why would > it require explicit language for negative cases? > > See my reply to Ben Vanik --- I didn't realize that UNSIGNED_INT was > already in the current spec. > > Benoit > > Ah, right. Email isn't a good real-time communication device. :\ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 10:50:22 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Feb 2012 19:50:22 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: So the basic issue is this: OpenGL et all use a global namespace for these names (as in GL_UNSIGNED_INT). There are a variety of extensions which may express some functionality with already present enumerants. In WebGL we do not (yet) have an gl.UNSIGNED_INT (but we do have a gl.UNSIGNED_BYTE and gl.UNSIGNED_SHORT) Adding the UNSIGNED_INT to the context if the extension is enabled may be problematic because: - some implementation issues in modifying the context - is not how extensions work so far Adding UNSIGNED_INT just to the extension object is problematic, because: - You end up referring to foo_ext.UNSIGNED_INT, bar_ext.UNSIGNED_INT, etc_ext.UNSIGNED_INT -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Feb 24 10:55:20 2012 From: kbr...@ (Kenneth Russell) Date: Fri, 24 Feb 2012 10:55:20 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 10:50 AM, Florian B?sch wrote: > So the basic issue is this: > > OpenGL et all use a global namespace for these names (as in > GL_UNSIGNED_INT). There are a variety of extensions which may express some > functionality with already present enumerants. > > In WebGL we do not (yet) have an gl.UNSIGNED_INT (but we do have a > gl.UNSIGNED_BYTE and gl.UNSIGNED_SHORT) UNSIGNED_INT is already present on WebGLRenderingContext. http://www.khronos.org/registry/webgl/specs/latest/ -Ken > Adding the UNSIGNED_INT to the context if the extension is enabled may be > problematic because: > - some implementation issues in modifying the context > - is not how extensions work so far > > Adding UNSIGNED_INT just to the extension object is problematic, because: > - You end up referring to foo_ext.UNSIGNED_INT, bar_ext.UNSIGNED_INT, > etc_ext.UNSIGNED_INT > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Feb 24 10:55:57 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Feb 2012 19:55:57 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: > > That's incorrect, see 5.14 on the spec > , const GLenum UNSIGNED_INT = 0x1405 > Alright, so at least for this enum it's unambiguous. So the extension specification should specify that it refers to the globally available unsigned int somehow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 11:13:17 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Feb 2012 20:13:17 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 7:55 PM, Florian B?sch wrote: > Alright, so at least for this enum it's unambiguous. So the extension >> specification should specify that it refers to the globally available >> unsigned int somehow. >> > Patch attached, removed the IDL definition for unsigned int following the texture float example. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 738 bytes Desc: not available URL: From ben...@ Fri Feb 24 13:31:01 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 13:31:01 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Playing with the EXT_texture_filter_anisotropic spec right now -- I think the constants should have the _EXT suffix. Looking at OES_texture_half_float and OES_standard_derivatives, the constants there have _OES. Since the original EXT_texture_filter_anisotropic constants have _EXT, they should probably match. On Fri, Feb 24, 2012 at 11:13 AM, Florian B?sch wrote: > On Fri, Feb 24, 2012 at 7:55 PM, Florian B?sch wrote: > >> Alright, so at least for this enum it's unambiguous. So the extension >>> specification should specify that it refers to the globally available >>> unsigned int somehow. >>> >> Patch attached, removed the IDL definition for unsigned int following the > texture float example. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 14:04:02 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 24 Feb 2012 23:04:02 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 10:31 PM, Ben Vanik wrote: > Playing with the EXT_texture_filter_anisotropic spec right now -- I think > the constants should have the _EXT suffix. Looking at > OES_texture_half_float and OES_standard_derivatives, the constants there > have _OES. Since the original EXT_texture_filter_anisotropic constants have > _EXT, they should probably match. I disagree. The EXT suffix on enumerants etc. serves the purpose to dissambiguate extensions in the global namespace so that vendor specific extensions (NV, ATI, SGI, etc.), non ratified but non vendor specific (EXT) fully ratified extensions (ARB) and incorporated functionality (no suffix at all) do not clash. WebGL however uses a different mechanism to serve extensions. We serve enumerants and symbols from the extension object, so no clashes with incorporated functions or other extensions can occur. A second motivation to append suffixes to enumerants and symbols is to make people aware of the fact that they are using an extension. This again stems from the fact that opengl et. al are one big global namespace. Again this is not an issue for WebGL because in order to obtain the required symbols specific to an extension, it is necessary to obtain the extension object, such as the code below: var extension = gl.getExtension('EXT_texture_filter_anisotropic') extension.MAX_TEXTURE_ANISOTROPY_EXT It is extremely unlikely that somebody would access the extension object without being aware of accessing the extension object if there was no EXT suffix. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Feb 24 14:19:55 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 14:19:55 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Hmm I almost-half-agree, but disagree more ;) 1) I'm writing optimized code and am not using the values off of the WebGLRenderingContext or the extensions, but instead defining my own constants that are inlined by a compiler. Having the suffixes helps me keep my constant namespace clean and *does* indicate that I am using an extension. (see http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/webgl/webgl.js - the Closure compiler can inline these, creating faster and smaller code) Even if not doing something as complex as a compiler pre-pass/custom constants/etc, in large code one would rarely be passing around a bunch of extension objects. Instead, since the constants are fixed values, it's easier to place them on a single object and pass that around, or keep them globally defined somewhere. 2) WebGL has tried to keep the API and constants as similar to GL as possible to aid in porting code/readability/discovery/etc. It of course is not 100% the same, but one of the goals is to not break from GL where not required. In this case, it's not required. Since the extension is EXT_.... and is designed to map to it, it follows that the constants and functions inside of it should be 1:1. If not, it shouldn't be prefixed with EXT_ for the same reasons. 3) The existing extensions are already following the pattern - as a bit of a pedant, it pains me to see inconsistency forming in the WebGL specs so early without good reason. Either we go back and change the existing specs, or we keep the new ones consistent. Since we can't go back and change the ratified specs without breaking code, I vote for keeping things the same. On Fri, Feb 24, 2012 at 2:04 PM, Florian B?sch wrote: > On Fri, Feb 24, 2012 at 10:31 PM, Ben Vanik wrote: > >> Playing with the EXT_texture_filter_anisotropic spec right now -- I think >> the constants should have the _EXT suffix. Looking at >> OES_texture_half_float and OES_standard_derivatives, the constants there >> have _OES. Since the original EXT_texture_filter_anisotropic constants have >> _EXT, they should probably match. > > I disagree. > > The EXT suffix on enumerants etc. serves the purpose to dissambiguate > extensions in the global namespace so that vendor specific extensions (NV, > ATI, SGI, etc.), non ratified but non vendor specific (EXT) fully ratified > extensions (ARB) and incorporated functionality (no suffix at all) do not > clash. > > WebGL however uses a different mechanism to serve extensions. We serve > enumerants and symbols from the extension object, so no clashes with > incorporated functions or other extensions can occur. > > A second motivation to append suffixes to enumerants and symbols is to > make people aware of the fact that they are using an extension. This again > stems from the fact that opengl et. al are one big global namespace. Again > this is not an issue for WebGL because in order to obtain the required > symbols specific to an extension, it is necessary to obtain the extension > object, such as the code below: > > var extension = gl.getExtension('EXT_texture_filter_anisotropic') > extension.MAX_TEXTURE_ANISOTROPY_EXT > > It is extremely unlikely that somebody would access the extension object > without being aware of accessing the extension object if there was no EXT > suffix. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 15:29:41 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 25 Feb 2012 00:29:41 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 11:19 PM, Ben Vanik wrote: How you structure your application and what you prefer doing with your namespaces has no bearing on the discussion. > 2) WebGL has tried to keep the API and constants as similar to GL as > possible to aid in porting code/readability/discovery/etc. It of course is > not 100% the same, but one of the goals is to not break from GL where not > required. In this case, it's not required. Since the extension is EXT_.... > and is designed to map to it, it follows that the constants and functions > inside of it should be 1:1. If not, it shouldn't be prefixed with EXT_ for > the same reasons. > 3) The existing extensions are already following the pattern - as a bit of > a pedant, it pains me to see inconsistency forming in the WebGL specs so > early without good reason. Either we go back and change the existing specs, > or we keep the new ones consistent. Since we can't go back and change the > ratified specs without breaking code, I vote for keeping things the same. > I do concede the point, it is inconsistent to other extensions thus far. Interestingly I did not notice that (and neither did anybody else except you), which kind of illustrates an intuitive point about it. On any account, I can provide patches to the specification and implementations if required. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Feb 24 15:33:17 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 15:33:17 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: It has a bearing when one of your reasons for dropping the suffix is that the namespace collisions are no longer a problem - I'm telling you they still are ;) Excellent. I've got a patch in the works for WebKit/Chrome for WEBKIT_EXT_texture_filter_anisotropic. On Fri, Feb 24, 2012 at 3:29 PM, Florian B?sch wrote: > On Fri, Feb 24, 2012 at 11:19 PM, Ben Vanik wrote: > How you structure your application and what you prefer doing with your > namespaces has no bearing on the discussion. > > >> 2) WebGL has tried to keep the API and constants as similar to GL as >> possible to aid in porting code/readability/discovery/etc. It of course is >> not 100% the same, but one of the goals is to not break from GL where not >> required. In this case, it's not required. Since the extension is EXT_.... >> and is designed to map to it, it follows that the constants and functions >> inside of it should be 1:1. If not, it shouldn't be prefixed with EXT_ for >> the same reasons. >> > 3) The existing extensions are already following the pattern - as a bit of >> a pedant, it pains me to see inconsistency forming in the WebGL specs so >> early without good reason. Either we go back and change the existing specs, >> or we keep the new ones consistent. Since we can't go back and change the >> ratified specs without breaking code, I vote for keeping things the same. >> > > I do concede the point, it is inconsistent to other extensions thus far. > Interestingly I did not notice that (and neither did anybody else except > you), which kind of illustrates an intuitive point about it. On any > account, I can provide patches to the specification and implementations if > required. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Feb 24 17:31:30 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 25 Feb 2012 02:31:30 +0100 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Adjusted the specifications (patch attached): - EXT_texture_filter_anisotropic: added name aliases for the extension name and added the EXT suffix to the enumerants. - OES_element_index_uint: added name aliases for the extension name and removed the enumerants from the IDL that are available in the core context. - WEBGL_depth_texture: added name aliases for the extension name and removed the enumerants from the IDL that are available in the core context. Added a patch to the firefox implementation ( https://bugzilla.mozilla.org/show_bug.cgi?id=728354#c17): - EXT suffix added to the enumerants - Conformance test updated to use the new suffix and added multiple vendor prefix recognition as well as the canonical extension name. On Sat, Feb 25, 2012 at 12:33 AM, Ben Vanik wrote: > Excellent. I've got a patch in the works for WebKit/Chrome for > WEBKIT_EXT_texture_filter_anisotropic. > Cool, any word on the Angle Direct3D support for it (I still haven't gotten around to setup a windows box)? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.diff Type: text/x-patch Size: 4982 bytes Desc: not available URL: From ben...@ Fri Feb 24 19:14:11 2012 From: ben...@ (Ben Vanik) Date: Fri, 24 Feb 2012 19:14:11 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Awesome! Will the tests make their way into the khronos repo? WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=79541 (it's been awhile since I've touched this stuff, may take some time to get it in ;) I'm willing to give the ANGLE bug a go if no one has touched it yet (and while waiting for the WebKit stuff to go through). On Fri, Feb 24, 2012 at 5:31 PM, Florian B?sch wrote: > Adjusted the specifications (patch attached): > - EXT_texture_filter_anisotropic: added name aliases for the extension > name and added the EXT suffix to the enumerants. > - OES_element_index_uint: added name aliases for the extension name and > removed the enumerants from the IDL that are available in the core context. > - WEBGL_depth_texture: added name aliases for the extension name and > removed the enumerants from the IDL that are available in the core context. > > Added a patch to the firefox implementation ( > https://bugzilla.mozilla.org/show_bug.cgi?id=728354#c17): > - EXT suffix added to the enumerants > - Conformance test updated to use the new suffix and added multiple vendor > prefix recognition as well as the canonical extension name. > > On Sat, Feb 25, 2012 at 12:33 AM, Ben Vanik wrote: > >> Excellent. I've got a patch in the works for WebKit/Chrome for >> WEBKIT_EXT_texture_filter_anisotropic. >> > Cool, any word on the Angle Direct3D support for it (I still haven't > gotten around to setup a windows box)? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Feb 24 21:06:54 2012 From: bja...@ (Benoit Jacob) Date: Fri, 24 Feb 2012 21:06:54 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <2108488051.1377002.1330146414861.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > Awesome! > Will the tests make their way into the khronos repo? That sure is the intent! I'll let you know. Benoit > WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=79541 (it's been > awhile since I've touched this stuff, may take some time to get it > in ;) > I'm willing to give the ANGLE bug a go if no one has touched it yet > (and while waiting for the WebKit stuff to go through). > On Fri, Feb 24, 2012 at 5:31 PM, Florian B?sch < pyalot...@ > > wrote: > > Adjusted the specifications (patch attached): > > > - EXT_texture_filter_anisotropic: added name aliases for the > > extension name and added the EXT suffix to the enumerants. > > > - OES_element_index_uint: added name aliases for the extension name > > and removed the enumerants from the IDL that are available in the > > core context. > > > - WEBGL_depth_texture: added name aliases for the extension name > > and > > removed the enumerants from the IDL that are available in the core > > context. > > > Added a patch to the firefox implementation ( > > https://bugzilla.mozilla.org/show_bug.cgi?id=728354#c17 ): > > > - EXT suffix added to the enumerants > > > - Conformance test updated to use the new suffix and added multiple > > vendor prefix recognition as well as the canonical extension name. > > > On Sat, Feb 25, 2012 at 12:33 AM, Ben Vanik < benvanik...@ > > > wrote: > > > > Excellent. I've got a patch in the works for WebKit/Chrome for > > > WEBKIT_EXT_texture_filter_anisotropic. > > > > > Cool, any word on the Angle Direct3D support for it (I still > > haven't > > gotten around to setup a windows box)? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Sun Feb 26 09:23:48 2012 From: bja...@ (Benoit Jacob) Date: Sun, 26 Feb 2012 09:23:48 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <1369977267.30026.1330277028947.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > Awesome! > Will the tests make their way into the khronos repo? Florian's test has just been checked in the Khronos repository: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/extensions/ext-texture-filter-anisotropic.html Cheers, Benoit > WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=79541 (it's been > awhile since I've touched this stuff, may take some time to get it > in ;) > I'm willing to give the ANGLE bug a go if no one has touched it yet > (and while waiting for the WebKit stuff to go through). > On Fri, Feb 24, 2012 at 5:31 PM, Florian B?sch < pyalot...@ > > wrote: > > Adjusted the specifications (patch attached): > > > - EXT_texture_filter_anisotropic: added name aliases for the > > extension name and added the EXT suffix to the enumerants. > > > - OES_element_index_uint: added name aliases for the extension name > > and removed the enumerants from the IDL that are available in the > > core context. > > > - WEBGL_depth_texture: added name aliases for the extension name > > and > > removed the enumerants from the IDL that are available in the core > > context. > > > Added a patch to the firefox implementation ( > > https://bugzilla.mozilla.org/show_bug.cgi?id=728354#c17 ): > > > - EXT suffix added to the enumerants > > > - Conformance test updated to use the new suffix and added multiple > > vendor prefix recognition as well as the canonical extension name. > > > On Sat, Feb 25, 2012 at 12:33 AM, Ben Vanik < benvanik...@ > > > wrote: > > > > Excellent. I've got a patch in the works for WebKit/Chrome for > > > WEBKIT_EXT_texture_filter_anisotropic. > > > > > Cool, any word on the Angle Direct3D support for it (I still > > haven't > > gotten around to setup a windows box)? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emo...@ Mon Feb 27 13:04:36 2012 From: emo...@ (=?utf-8?Q?Erik_M=C3=B6ller?=) Date: Mon, 27 Feb 2012 22:04:36 +0100 Subject: [Public WebGL] Opera Mobile 12 for android Message-ID: In case you've missed it Opera Mobile 12 was launched at MWC and sports WebGL on android. https://twitter.com/erikjmoller/statuses/174108159403769857 -- Erik M?ller Core Developer Opera Software twitter.com/erikjmoller ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Feb 27 15:35:45 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Feb 2012 15:35:45 -0800 Subject: [Public WebGL] Opera Mobile 12 for android In-Reply-To: References: Message-ID: Very nice! It's exciting to see more WebGL implementations showing up on mobile devices! -Ken On Mon, Feb 27, 2012 at 1:04 PM, Erik M?ller wrote: > > In case you've missed it Opera Mobile 12 was launched at MWC and sports > WebGL on android. > https://twitter.com/erikjmoller/statuses/174108159403769857 > > -- > Erik M?ller > Core Developer > Opera Software > twitter.com/erikjmoller > > ----------------------------------------------------------- > 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 jda...@ Mon Feb 27 16:06:35 2012 From: jda...@ (John Davis) Date: Mon, 27 Feb 2012 18:06:35 -0600 Subject: [Public WebGL] Opera Mobile 12 for android In-Reply-To: References: Message-ID: opera on ios to follow? On Monday, February 27, 2012, Erik M?ller wrote: > > In case you've missed it Opera Mobile 12 was launched at MWC and sports > WebGL on android. > https://twitter.com/**erikjmoller/statuses/**174108159403769857 > > -- > Erik M?ller > Core Developer > Opera Software > twitter.com/erikjmoller > > ------------------------------**----------------------------- > 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...@ Mon Feb 27 16:11:07 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 28 Feb 2012 01:11:07 +0100 Subject: [Public WebGL] Opera Mobile 12 for android In-Reply-To: References: Message-ID: On Tue, Feb 28, 2012 at 1:06 AM, John Davis wrote: > opera on ios to follow? Afaik you're not allowed to port an actual browser (as in interpreting a script language) to iOS. You've got to use the iOS mobile webkit view. That should support WebGL though (with a bit of trickery). -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Feb 27 17:06:04 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Feb 2012 17:06:04 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: Message-ID: On Fri, Feb 24, 2012 at 10:40 AM, Florian B?sch wrote: > On Fri, Feb 24, 2012 at 7:21 PM, Kenneth Russell wrote: >> >> Agree that we should formalize the process. I believe the >> implementation lifetime should be as follows: >> >> ?- Proposal: for discussion on the public mailing list only, in order >> to move to draft status. Must not be implemented by any vendor in this >> form. >> ?- Draft: may be implemented with vendor prefix. For experimentation >> purposes, to gain experience with the extension before finalizing. >> ?- Ratified: should be implemented without vendor prefix. Should not >> be removed except if there is a security issue or similar. >> >> Thoughts? > > I think that's fine, but it would need some definition as to how things move > into proposal and into draft. I'd also like to suggest extensions get a > champion or somesuch, which is basically the go-to person for questions > about it and who is interested to supply patches to the specification, > implementations and conformance tests. A section "Extension Development Process" has been added to http://www.khronos.org/registry/webgl/extensions/ . Please review. The contact and/or primary contributor to the extension is its champion, so it doesn't seem necessary to mention that separately. >> Also, I'd like to propose we move OES_element_index_uint and >> WEBGL_depth_texture from proposal state to draft state; these seem >> non-controversial. Objections or support? > > No objection to move these to draft state. They're both a little more > involved to implement and the sooner we start, the sooner we'll have some > test implementations. Great. I'll start a separate thread about this just in case anyone missed it buried deep in this one. -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 Feb 27 17:12:49 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Feb 2012 17:12:49 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <682080134.1142924.1330108577156.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <682080134.1142924.1330108577156.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 10:36 AM, Benoit Jacob wrote: >> Agree that we should formalize the process. I believe the >> implementation lifetime should be as follows: >> >> ? - Proposal: for discussion on the public mailing list only, in >> ? order >> to move to draft status. Must not be implemented by any vendor in >> this >> form. >> ? - Draft: may be implemented with vendor prefix. For experimentation >> purposes, to gain experience with the extension before finalizing. >> ? - Ratified: should be implemented without vendor prefix. Should not >> be removed except if there is a security issue or similar. >> >> Thoughts? > > OK to formalize the notion that proposals should be made drafts before implementation starts (will do next time). > > Could we also formalize that once an extension is ratified, not only it should be implemented without vendor prefix, but any browser that already has an implementation with prefix should remove support for the prefixed extension string as soon as possible, even if this breaks content? Does the text just added to http://www.khronos.org/registry/webgl/extensions/ address your concern? If not, let's make it more explicit. >> Also, I'd like to propose we move OES_element_index_uint and >> WEBGL_depth_texture from proposal state to draft state; these seem >> non-controversial. Objections or support? > > About OES_element_index_uint, is there a use case where this is a significant performance win, or is this is just a convenience extension? Is it worth the portability issues it introduces? The main portability issue with OES_element_index_uint has been addressed with support for the extension in iOS 5. See http://www.lastrayofhope.com/2011/07/24/ios-opengl-es-extension-support/ . > I support depth textures. Great. I'll still start up a separate thread about moving these out of proposals in case anyone missed this discussion here. -Ken > Benoit > > >> >> ? https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ >> ? http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ >> ? http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ >> >> -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 Feb 27 17:13:58 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Feb 2012 17:13:58 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: References: <1404201637.1163868.1330108995900.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, Feb 24, 2012 at 5:31 PM, Florian B?sch wrote: > Adjusted the specifications (patch attached): > - EXT_texture_filter_anisotropic: added name aliases for the extension name > and added the EXT suffix to the enumerants. > - OES_element_index_uint: added name aliases for the extension name and > removed the enumerants from the IDL that are available in the core context. > - WEBGL_depth_texture: added name aliases for the extension name and removed > the enumerants from the IDL that are available in the core context. > > Added a patch to the firefox implementation > (https://bugzilla.mozilla.org/show_bug.cgi?id=728354#c17): > - EXT suffix added to the enumerants > - Conformance test updated to use the new suffix and added multiple vendor > prefix recognition as well as the canonical extension name. Thanks for these updates and in particular for the conformance test. I've committed the changes to the extensions and also moved EXT_texture_filter_anisotropic from proposal to draft. -Ken > On Sat, Feb 25, 2012 at 12:33 AM, Ben Vanik wrote: >> >> Excellent. I've got a patch in the works for WebKit/Chrome for >> WEBKIT_EXT_texture_filter_anisotropic. > > Cool, any word on the Angle Direct3D support for it (I still haven't gotten > around to setup a windows box)? > ----------------------------------------------------------- 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...@ Mon Feb 27 18:22:24 2012 From: bja...@ (Benoit Jacob) Date: Mon, 27 Feb 2012 18:22:24 -0800 (PST) Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: Message-ID: <677694205.374247.1330395744145.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Fri, Feb 24, 2012 at 10:36 AM, Benoit Jacob > wrote: > >> Agree that we should formalize the process. I believe the > >> implementation lifetime should be as follows: > >> > >> ? - Proposal: for discussion on the public mailing list only, in > >> ? order > >> to move to draft status. Must not be implemented by any vendor in > >> this > >> form. > >> ? - Draft: may be implemented with vendor prefix. For > >> ? experimentation > >> purposes, to gain experience with the extension before finalizing. > >> ? - Ratified: should be implemented without vendor prefix. Should > >> ? not > >> be removed except if there is a security issue or similar. > >> > >> Thoughts? > > > > OK to formalize the notion that proposals should be made drafts > > before implementation starts (will do next time). > > > > Could we also formalize that once an extension is ratified, not > > only it should be implemented without vendor prefix, but any > > browser that already has an implementation with prefix should > > remove support for the prefixed extension string as soon as > > possible, even if this breaks content? > > Does the text just added to > http://www.khronos.org/registry/webgl/extensions/ address your > concern? If not, let's make it more explicit. What I'm trying to avoid, is the problem where prefixed features stay around long after they have been standardized and available without prefix. This leads to a situation where some Web content keeps using the prefixed feature, and thus, keeps working only with the browser engine that they initially targeted. To prevent that, I think that we should mandate that as soon as a feature becomes available without prefix, support for the prefix should be dropped. The downside is of course that this breaks content, but it could hopefully be made clear enough that prefixes can go away at any time, and content that cares about future compatibility could simply start checking for the non-prefixed name as a fallback, before the prefix gets dropped. Does that make sense? I'm happy to edit the document to that effect, if you agree. Cheers, Benoit > > > >> Also, I'd like to propose we move OES_element_index_uint and > >> WEBGL_depth_texture from proposal state to draft state; these seem > >> non-controversial. Objections or support? > > > > About OES_element_index_uint, is there a use case where this is a > > significant performance win, or is this is just a convenience > > extension? Is it worth the portability issues it introduces? > > The main portability issue with OES_element_index_uint has been > addressed with support for the extension in iOS 5. See > http://www.lastrayofhope.com/2011/07/24/ios-opengl-es-extension-support/ > . > > > I support depth textures. > > Great. I'll still start up a separate thread about moving these out > of > proposals in case anyone missed this discussion here. > > -Ken > > > > Benoit > > > > > >> > >> ? https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ > >> ? http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ > >> ? http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ > >> > >> -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 Feb 27 18:32:10 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Feb 2012 18:32:10 -0800 Subject: [Public WebGL] Move OES_element_index_uint and WEBGL_depth_texture proposals to draft Message-ID: All, Per email on the thread about EXT_texture_filter_anisotropic, I'd like to propose moving the OES_element_index_uint and WEBGL_depth_texture extension proposals to draft status. This would allow browsers to implement them for experimental purposes under a vendor prefix. http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ Note that for each of these extensions, the portability concerns have been addressed. OES_element_index_uint is supported in iOS 5, and WEBGL_depth_texture specifies enough restrictions that it is implementable on both desktop and mobile hardware. Are there any objections to moving them? Thanks, -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Feb 27 18:34:21 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 27 Feb 2012 18:34:21 -0800 Subject: [Public WebGL] proposal draft for EXT_texture_filter_anisotropic In-Reply-To: <677694205.374247.1330395744145.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <677694205.374247.1330395744145.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Mon, Feb 27, 2012 at 6:22 PM, Benoit Jacob wrote: > > > ----- Original Message ----- >> On Fri, Feb 24, 2012 at 10:36 AM, Benoit Jacob >> wrote: >> >> Agree that we should formalize the process. I believe the >> >> implementation lifetime should be as follows: >> >> >> >> ? - Proposal: for discussion on the public mailing list only, in >> >> ? order >> >> to move to draft status. Must not be implemented by any vendor in >> >> this >> >> form. >> >> ? - Draft: may be implemented with vendor prefix. For >> >> ? experimentation >> >> purposes, to gain experience with the extension before finalizing. >> >> ? - Ratified: should be implemented without vendor prefix. Should >> >> ? not >> >> be removed except if there is a security issue or similar. >> >> >> >> Thoughts? >> > >> > OK to formalize the notion that proposals should be made drafts >> > before implementation starts (will do next time). >> > >> > Could we also formalize that once an extension is ratified, not >> > only it should be implemented without vendor prefix, but any >> > browser that already has an implementation with prefix should >> > remove support for the prefixed extension string as soon as >> > possible, even if this breaks content? >> >> Does the text just added to >> http://www.khronos.org/registry/webgl/extensions/ address your >> concern? If not, let's make it more explicit. > > What I'm trying to avoid, is the problem where prefixed features stay around long after they have been standardized and available without prefix. This leads to a situation where some Web content keeps using the prefixed feature, and thus, keeps working only with the browser engine that they initially targeted. > > To prevent that, I think that we should mandate that as soon as a feature becomes available without prefix, support for the prefix should be dropped. The downside is of course that this breaks content, but it could hopefully be made clear enough that prefixes can go away at any time, and content that cares about future compatibility could simply start checking for the non-prefixed name as a fallback, before the prefix gets dropped. > > Does that make sense? I'm happy to edit the document to that effect, if you agree. Makes sense. Please do go ahead, edit the registry.html and re-execute the Makefile. Thanks, -Ken > Cheers, > Benoit > >> >> >> >> Also, I'd like to propose we move OES_element_index_uint and >> >> WEBGL_depth_texture from proposal state to draft state; these seem >> >> non-controversial. Objections or support? >> > >> > About OES_element_index_uint, is there a use case where this is a >> > significant performance win, or is this is just a convenience >> > extension? Is it worth the portability issues it introduces? >> >> The main portability issue with OES_element_index_uint has been >> addressed with support for the extension in iOS 5. See >> http://www.lastrayofhope.com/2011/07/24/ios-opengl-es-extension-support/ >> . >> >> > I support depth textures. >> >> Great. I'll still start up a separate thread about moving these out >> of >> proposals in case anyone missed this discussion here. >> >> -Ken >> >> >> > Benoit >> > >> > >> >> >> >> ? https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/extensions/proposals/ >> >> ? http://www.khronos.org/registry/webgl/extensions/proposals/OES_element_index_uint/ >> >> ? http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_depth_texture/ >> >> >> >> -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...@ Tue Feb 28 19:15:38 2012 From: kbr...@ (Kenneth Russell) Date: Tue, 28 Feb 2012 19:15:38 -0800 Subject: [Public WebGL] Spec updates Message-ID: WebGL community, A couple of updates regarding the WebGL spec: - A snapshot of the current Editor's Draft was sent to the board of the Khronos Group for approval last week. If all goes well, this will be ratified as WebGL version 1.0.1 in about six weeks' time. - An associated snapshot of the WebGL conformance tests was taken. This snapshot is still considered under development for bug fixing purposes, but again if all goes well it will be officially released as version 1.0.1 of the conformance suite. - The development version of the conformance tests [1] was updated to version 1.0.2 (beta). A number of additional tests are now being run in that version, and some of them are currently expected to fail. More tests, and clarifications to existing ones, are anticipated as the spec and implementations continue to evolve. Looking forward to continuing to work with you all to advance 3D on the web! -Ken [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html ----------------------------------------------------------- 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 emo...@ Wed Feb 29 07:59:30 2012 From: emo...@ (=?utf-8?Q?Erik_M=C3=B6ller?=) Date: Wed, 29 Feb 2012 16:59:30 +0100 Subject: [Public WebGL] WebGL tutorial video Message-ID: Sorry about the shameless selfpromotion. Just posted a looong WebGL tutorial video on youtube which will hopefully be a good complement to learningwebgl and the likes. Blog entry: http://my.opera.com/emoller/blog/2012/02/29/webgl-101 Video: http://www.youtube.com/watch?v=me3BviH3nZc Source: https://github.com/emoller/WebGL101 -- Erik M?ller Core Developer Opera Software twitter.com/erikjmoller ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Wed Feb 29 13:43:10 2012 From: kbr...@ (Kenneth Russell) Date: Wed, 29 Feb 2012 13:43:10 -0800 Subject: [Public WebGL] WebGL tutorial video In-Reply-To: References: Message-ID: Nice -- please add a link to http://www.khronos.org/webgl/wiki/User_Contributions . -Ken On Wed, Feb 29, 2012 at 7:59 AM, Erik M?ller wrote: > > Sorry about the shameless selfpromotion. Just posted a looong WebGL tutorial > video on youtube which will hopefully be a good complement to learningwebgl > and the likes. > > Blog entry: http://my.opera.com/emoller/blog/2012/02/29/webgl-101 > Video: http://www.youtube.com/watch?v=me3BviH3nZc > Source: https://github.com/emoller/WebGL101 > > -- > Erik M?ller > Core Developer > Opera Software > twitter.com/erikjmoller > > ----------------------------------------------------------- > 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 dan...@ Wed Feb 29 20:25:58 2012 From: dan...@ (Daniel Koch) Date: Wed, 29 Feb 2012 23:25:58 -0500 Subject: [Public WebGL] Depth Texture Extension In-Reply-To: References: <9B3BEF16CBC82A45900B3F159DF915960175762318DF@EU-MAIL-1-1.rws.ad.ea.com> <862FEEDB-9BF4-4B1C-8912-43B02C02A2BD@transgaming.com> <6EB4A909-F9EF-4335-ACD9-E5FF03EB4B72@transgaming.com> Message-ID: <5136C6F4-FA1A-4A93-B3B9-9302AF264AF4@transgaming.com> Hi folks, I brought the contradiction between OES_depth_texture and OES_packed_depth_stencil with respect to support for cube-depth textures to the attention of the ES Working Group. In a survey of the vendors which implement the OES_depth_texture extension it turns out that some of them support depth cube maps and others do not. As such, we have updated the specification for OES_depth_texture so that it only provides support for 2D depth textures. In the future, the depth cube map functionality will be advertised under a separate extension (not yet published). The OES_depth_texture specification (at http://www.khronos.org/registry/gles/extensions/OES/OES_depth_texture.txt) has been updated to reflect these changes. As such, the WEBGL_depth_texture proposal can be changed back to OES_depth_texture. Hope this helps, /Daniel/ On 2012-01-26, at 7:22 PM, Kenneth Russell wrote: > On Wed, Jan 25, 2012 at 7:55 AM, Florian B?sch wrote: >> Changed the draft to the prefix WEBGL, excluded cube depth maps, added the >> IDL and defined the error in case of attempted cube depth map usage, draft >> is attached (webgl_depth_texture.tar.bz2) > > Florian, > > Thanks for preparing this. It looks good. I've added it to the list of > proposed extensions as a draft. As it moves forward, could you please > submit changes in the form of patches? > > I agree with all of the points about exposing this under a different > name than OES_depth_texture, in order to indicate that this extension > exposes a subset of the other's functionality. > > -Ken --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: