From jda...@ Wed Jun 4 03:55:32 2014 From: jda...@ (John Davis) Date: Wed, 4 Jun 2014 06:55:32 -0400 Subject: [Public WebGL] Compute shaders Message-ID: Any chance we can get these in 2.0? Otherwise, my fear is we wait another 5 years. This is a big deal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Jun 4 03:57:11 2014 From: jda...@ (John Davis) Date: Wed, 4 Jun 2014 06:57:11 -0400 Subject: [Public WebGL] Re: Webgl In-Reply-To: References: Message-ID: Anything to report? On Tuesday, September 3, 2013, Chris Marrin > wrote: > > On Sep 2, 2013, at 5:28 PM, John Davis wrote: > > Any hope for webgl on iOS? > > > Nothing to report yet > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 4 04:15:18 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 4 Jun 2014 13:15:18 +0200 Subject: [Public WebGL] Compute shaders In-Reply-To: References: Message-ID: WebGL 2.0 would correspond to OpenGL ES 3.0. OpenGL ES 3.0 does not have compute shaders, so I'm guessing that WebGL 2.0 would neither have them. OpenGL ES 3.1 does have compute shaders and the specification was released in March. However, there is no OpenGL ES extension for compute shaders. This probably means that compute shaders would arrive with WebGL 2.1 (that would correspond to OpenGL ES 3.1). WebGL 2.0 might arrive this year, which would mark it around 2.5 years after release of the OpenGL ES 3.0 specification. Assuming this interval stays around the same, I think you would be able to expect WebGL 2.1 in 2-3 years, around 2017. On Wed, Jun 4, 2014 at 12:55 PM, John Davis wrote: > Any chance we can get these in 2.0? Otherwise, my fear is we wait another > 5 years. This is a big deal. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aas...@ Wed Jun 4 07:45:09 2014 From: aas...@ (Aashish Chaudhary) Date: Wed, 4 Jun 2014 10:45:09 -0400 Subject: [Public WebGL] Compute shaders In-Reply-To: References: Message-ID: It would be great if for minor webgl releases the time-duration stays between < 2 years so that we can provide best experience to our customers. - Aashish On Wed, Jun 4, 2014 at 7:15 AM, Florian B?sch wrote: > WebGL 2.0 would correspond to OpenGL ES 3.0. OpenGL ES 3.0 does not have > compute shaders, so I'm guessing that WebGL 2.0 would neither have them. > OpenGL ES 3.1 does have compute shaders and the specification was released > in March. However, there is no OpenGL ES extension for compute shaders. > > This probably means that compute shaders would arrive with WebGL 2.1 (that > would correspond to OpenGL ES 3.1). WebGL 2.0 might arrive this year, which > would mark it around 2.5 years after release of the OpenGL ES 3.0 > specification. Assuming this interval stays around the same, I think you > would be able to expect WebGL 2.1 in 2-3 years, around 2017. > > > On Wed, Jun 4, 2014 at 12:55 PM, John Davis > wrote: > >> Any chance we can get these in 2.0? Otherwise, my fear is we wait >> another 5 years. This is a big deal. >> >> > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 4 07:49:07 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 4 Jun 2014 16:49:07 +0200 Subject: [Public WebGL] Compute shaders In-Reply-To: References: Message-ID: I'm not sure why a minor release number was chosen by Khronos for ES 3.1. But the number of features introduced by OpenGL ES 3.1 does seem to me rather major. OpenGL ES 3.1 is also following over 2 years after OpenGL ES 3.0, which is the usual release cycle by Khronos for major releases. On Wed, Jun 4, 2014 at 4:45 PM, Aashish Chaudhary < aashish.chaudhary...@> wrote: > It would be great if for minor webgl releases the time-duration stays > between < 2 years so that we can provide best experience to our customers. > > - Aashish > > > > > On Wed, Jun 4, 2014 at 7:15 AM, Florian B?sch wrote: > >> WebGL 2.0 would correspond to OpenGL ES 3.0. OpenGL ES 3.0 does not have >> compute shaders, so I'm guessing that WebGL 2.0 would neither have them. >> OpenGL ES 3.1 does have compute shaders and the specification was released >> in March. However, there is no OpenGL ES extension for compute shaders. >> >> This probably means that compute shaders would arrive with WebGL 2.1 >> (that would correspond to OpenGL ES 3.1). WebGL 2.0 might arrive this year, >> which would mark it around 2.5 years after release of the OpenGL ES 3.0 >> specification. Assuming this interval stays around the same, I think you >> would be able to expect WebGL 2.1 in 2-3 years, around 2017. >> >> >> On Wed, Jun 4, 2014 at 12:55 PM, John Davis >> wrote: >> >>> Any chance we can get these in 2.0? Otherwise, my fear is we wait >>> another 5 years. This is a big deal. >>> >>> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Jun 4 15:45:33 2014 From: jgi...@ (Jeff Gilbert) Date: Wed, 4 Jun 2014 15:45:33 -0700 (PDT) Subject: [Public WebGL] Compute shaders In-Reply-To: References: Message-ID: <1158572898.7717692.1401921933759.JavaMail.zimbra@mozilla.com> I anticipate computer shaders will happen in some >2.0 version of WebGL. We've already decided that they won't make it into core WebGL 2.0. The turnaround time for a hypothetical WebGL 2.1 should be much lower than the 1.0->2.0 upgrade. -Jeff ----- Original Message ----- From: "Florian B?sch" To: "Aashish Chaudhary" Cc: "John Davis" , "public webgl" Sent: Wednesday, June 4, 2014 7:49:07 AM Subject: Re: [Public WebGL] Compute shaders I'm not sure why a minor release number was chosen by Khronos for ES 3.1. But the number of features introduced by OpenGL ES 3.1 does seem to me rather major. OpenGL ES 3.1 is also following over 2 years after OpenGL ES 3.0, which is the usual release cycle by Khronos for major releases. On Wed, Jun 4, 2014 at 4:45 PM, Aashish Chaudhary < aashish.chaudhary...@> wrote: > It would be great if for minor webgl releases the time-duration stays > between < 2 years so that we can provide best experience to our customers. > > - Aashish > > > > > On Wed, Jun 4, 2014 at 7:15 AM, Florian B?sch wrote: > >> WebGL 2.0 would correspond to OpenGL ES 3.0. OpenGL ES 3.0 does not have >> compute shaders, so I'm guessing that WebGL 2.0 would neither have them. >> OpenGL ES 3.1 does have compute shaders and the specification was released >> in March. However, there is no OpenGL ES extension for compute shaders. >> >> This probably means that compute shaders would arrive with WebGL 2.1 >> (that would correspond to OpenGL ES 3.1). WebGL 2.0 might arrive this year, >> which would mark it around 2.5 years after release of the OpenGL ES 3.0 >> specification. Assuming this interval stays around the same, I think you >> would be able to expect WebGL 2.1 in 2-3 years, around 2017. >> >> >> On Wed, Jun 4, 2014 at 12:55 PM, John Davis >> wrote: >> >>> Any chance we can get these in 2.0? Otherwise, my fear is we wait >>> another 5 years. This is a big deal. >>> >>> >> > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.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 vod...@ Thu Jun 5 03:10:38 2014 From: vod...@ (Michal Vodicka) Date: Thu, 5 Jun 2014 12:10:38 +0200 Subject: [Public WebGL] Re: Webgl In-Reply-To: References: Message-ID: http://www.extremetech.com/computing/183421-apple-wwdc-keynote-watch-the-live-video-unveil-of-ios-8-and-os-x-10-10-live-blog http://blog.ludei.com/webgl-ios-8-safari-webview/ On Wed, Jun 4, 2014 at 12:57 PM, John Davis wrote: > Anything to report? > > On Tuesday, September 3, 2013, Chris Marrin wrote: > >> >> On Sep 2, 2013, at 5:28 PM, John Davis wrote: >> >> Any hope for webgl on iOS? >> >> >> Nothing to report yet >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Jun 5 11:10:40 2014 From: kbr...@ (Kenneth Russell) Date: Thu, 5 Jun 2014 11:10:40 -0700 Subject: [Public WebGL] Compute shaders In-Reply-To: <1158572898.7717692.1401921933759.JavaMail.zimbra@mozilla.com> References: <1158572898.7717692.1401921933759.JavaMail.zimbra@mozilla.com> Message-ID: Yes. The WebGL 1 -> WebGL 2 upgrade is a major one and requires a significant amount of refactoring in Chrome and the ANGLE project. This will ease future updates to WebGL implementations in all browsers using ANGLE. An upgrade to WebGL exposing the new functionality in OpenGL ES 3.1 should come more quickly. -Ken On Wed, Jun 4, 2014 at 3:45 PM, Jeff Gilbert wrote: > > I anticipate computer shaders will happen in some >2.0 version of WebGL. We've already decided that they won't make it into core WebGL 2.0. > > The turnaround time for a hypothetical WebGL 2.1 should be much lower than the 1.0->2.0 upgrade. > > -Jeff > > ----- Original Message ----- > From: "Florian B?sch" > To: "Aashish Chaudhary" > Cc: "John Davis" , "public webgl" > Sent: Wednesday, June 4, 2014 7:49:07 AM > Subject: Re: [Public WebGL] Compute shaders > > I'm not sure why a minor release number was chosen by Khronos for ES 3.1. > But the number of features introduced by OpenGL ES 3.1 does seem to me > rather major. OpenGL ES 3.1 is also following over 2 years after OpenGL ES > 3.0, which is the usual release cycle by Khronos for major releases. > > > On Wed, Jun 4, 2014 at 4:45 PM, Aashish Chaudhary < > aashish.chaudhary...@> wrote: > >> It would be great if for minor webgl releases the time-duration stays >> between < 2 years so that we can provide best experience to our customers. >> >> - Aashish >> >> >> >> >> On Wed, Jun 4, 2014 at 7:15 AM, Florian B?sch wrote: >> >>> WebGL 2.0 would correspond to OpenGL ES 3.0. OpenGL ES 3.0 does not have >>> compute shaders, so I'm guessing that WebGL 2.0 would neither have them. >>> OpenGL ES 3.1 does have compute shaders and the specification was released >>> in March. However, there is no OpenGL ES extension for compute shaders. >>> >>> This probably means that compute shaders would arrive with WebGL 2.1 >>> (that would correspond to OpenGL ES 3.1). WebGL 2.0 might arrive this year, >>> which would mark it around 2.5 years after release of the OpenGL ES 3.0 >>> specification. Assuming this interval stays around the same, I think you >>> would be able to expect WebGL 2.1 in 2-3 years, around 2017. >>> >>> >>> On Wed, Jun 4, 2014 at 12:55 PM, John Davis >>> wrote: >>> >>>> Any chance we can get these in 2.0? Otherwise, my fear is we wait >>>> another 5 years. This is a big deal. >>>> >>>> >>> >> >> >> -- >> >> >> >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. * >> *| http://www.kitware.com/company/team/chaudhary.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 > ----------------------------------------------------------- > ----------------------------------------------------------- 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 van...@ Thu Jun 5 16:19:30 2014 From: van...@ (Vangelis Kokkevis) Date: Thu, 5 Jun 2014 16:19:30 -0700 Subject: [Public WebGL] Compute shaders In-Reply-To: References: <1158572898.7717692.1401921933759.JavaMail.zimbra@mozilla.com> Message-ID: One significant obstacle I see with supporting Compute in WebGL for Chrome on Windows is that doing the translation from GL ES Compute to DirectCompute is likely to be a large undertaking. As a result, it's currently unclear whether the D3D backend of ANGLE will get compute shaders. There are some large architectural changes taking place in both ANGLE and Chrome that should allow Chrome, via ANGLE, to directly target native GL ES drivers when available. If quality ES drivers become commonplace on Windows, that may be a viable way forward. Vangelis On Thu, Jun 5, 2014 at 11:10 AM, Kenneth Russell wrote: > > Yes. The WebGL 1 -> WebGL 2 upgrade is a major one and requires a > significant amount of refactoring in Chrome and the ANGLE project. > This will ease future updates to WebGL implementations in all browsers > using ANGLE. An upgrade to WebGL exposing the new functionality in > OpenGL ES 3.1 should come more quickly. > > -Ken > > > On Wed, Jun 4, 2014 at 3:45 PM, Jeff Gilbert wrote: > > > > I anticipate computer shaders will happen in some >2.0 version of WebGL. > We've already decided that they won't make it into core WebGL 2.0. > > > > The turnaround time for a hypothetical WebGL 2.1 should be much lower > than the 1.0->2.0 upgrade. > > > > -Jeff > > > > ----- Original Message ----- > > From: "Florian B?sch" > > To: "Aashish Chaudhary" > > Cc: "John Davis" , "public webgl" < > public_webgl...@> > > Sent: Wednesday, June 4, 2014 7:49:07 AM > > Subject: Re: [Public WebGL] Compute shaders > > > > I'm not sure why a minor release number was chosen by Khronos for ES 3.1. > > But the number of features introduced by OpenGL ES 3.1 does seem to me > > rather major. OpenGL ES 3.1 is also following over 2 years after OpenGL > ES > > 3.0, which is the usual release cycle by Khronos for major releases. > > > > > > On Wed, Jun 4, 2014 at 4:45 PM, Aashish Chaudhary < > > aashish.chaudhary...@> wrote: > > > >> It would be great if for minor webgl releases the time-duration stays > >> between < 2 years so that we can provide best experience to our > customers. > >> > >> - Aashish > >> > >> > >> > >> > >> On Wed, Jun 4, 2014 at 7:15 AM, Florian B?sch wrote: > >> > >>> WebGL 2.0 would correspond to OpenGL ES 3.0. OpenGL ES 3.0 does not > have > >>> compute shaders, so I'm guessing that WebGL 2.0 would neither have > them. > >>> OpenGL ES 3.1 does have compute shaders and the specification was > released > >>> in March. However, there is no OpenGL ES extension for compute shaders. > >>> > >>> This probably means that compute shaders would arrive with WebGL 2.1 > >>> (that would correspond to OpenGL ES 3.1). WebGL 2.0 might arrive this > year, > >>> which would mark it around 2.5 years after release of the OpenGL ES 3.0 > >>> specification. Assuming this interval stays around the same, I think > you > >>> would be able to expect WebGL 2.1 in 2-3 years, around 2017. > >>> > >>> > >>> On Wed, Jun 4, 2014 at 12:55 PM, John Davis > >>> wrote: > >>> > >>>> Any chance we can get these in 2.0? Otherwise, my fear is we wait > >>>> another 5 years. This is a big deal. > >>>> > >>>> > >>> > >> > >> > >> -- > >> > >> > >> > >> *| Aashish Chaudhary | Technical Leader | Kitware Inc. > * > >> *| http://www.kitware.com/company/team/chaudhary.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 > > ----------------------------------------------------------- > > > > ----------------------------------------------------------- > 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 ami...@ Thu Jun 5 16:33:25 2014 From: ami...@ (ami...@) Date: Thu, 05 Jun 2014 20:33:25 -0300 Subject: [Public WebGL] unsubscribe public_webgl Message-ID: <20140605233325.5320836.3651.142@gmail.com> An HTML attachment was scrubbed... URL: From pya...@ Mon Jun 9 03:32:13 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 9 Jun 2014 12:32:13 +0200 Subject: [Public WebGL] Proposal to ratify currently community approved extensions In-Reply-To: <1896479227.15010719.1395787890689.JavaMail.zimbra@mozilla.com> References: <706481114.7873085.1392239781229.JavaMail.zimbra@mozilla.com> <1896479227.15010719.1395787890689.JavaMail.zimbra@mozilla.com> Message-ID: On Tue, Mar 25, 2014 at 11:51 PM, Jeff Gilbert wrote: > Alright, our issue was a bad ANGLE pull. It's been fixed in newer > versions, so we should be fine moving these forward. Any progress on the ratification of WEBGL_draw_buffers, ANGLE_instanced_arrays, OES_texture_float_linear and OES_texture_half_float_linear? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jun 9 03:34:13 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 9 Jun 2014 12:34:13 +0200 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: <5389792A.50607@gmx.at> References: <5389792A.50607@gmx.at> Message-ID: Any progress on moving EXT_frag_depth to community approved? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 9 16:14:10 2014 From: kbr...@ (Kenneth Russell) Date: Mon, 9 Jun 2014 16:14:10 -0700 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> Message-ID: It sounds like all implementers that have responded are in favor of moving EXT_frag_depth to community approved. Thanks for pushing on this. Merged your pull request. On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch wrote: > Any progress on moving EXT_frag_depth to community approved? ----------------------------------------------------------- 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 Jun 9 21:18:59 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 10 Jun 2014 06:18:59 +0200 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> Message-ID: I think EXT_sRGB should be moved to community approved with all due haste so as to avoid Mozilla having to retract their implementation, and so that iOS can include the functionality. These devices support EXT_sRGB natively. - iPad 2 - iPad 3 - iPad 4 - iPhone 4s - iPhone 5 - iPhone 5C - iPhone 5s - iPad Air - iPad mini (and retina) - iPod touch 5th gen - Xiaomi MiniPad - Samsung SM-G870 But these devices are not OpenGL ES 3.0 compatible: - iPad 2 - iPad 3 - iPad 4 - iPhone 4s - iPhone 5 - iPHone 5C - iPod touch 5G Of These, the following are iOS8 compatible: - iPad 2 - iPad 3 - iPad 4 - iPhone 4s - iPhone 5 - iPhone 5C - iPod touch 5G If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not include support for it in iOS8. That would mean that until Apple appears with a WebGL2 implementation, sRGB will not be available on the the iPhone 5s, iPad Air and iPad mini. But worse, it would never be available on the iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which represent a sizable bulk (the majority?) of iOS devices in use, and cannot support WebGL2. On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell wrote: > It sounds like all implementers that have responded are in favor of > moving EXT_frag_depth to community approved. Thanks for pushing on > this. Merged your pull request. > > > > On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch wrote: > > Any progress on moving EXT_frag_depth to community approved? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Jun 10 14:51:46 2014 From: jgi...@ (Jeff Gilbert) Date: Tue, 10 Jun 2014 14:51:46 -0700 (PDT) Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> Message-ID: <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> Interesting, I was just wondering about this. FWIW, implementation of extensions that are core in WebGL 2 shouldn't be much of a burden, since the mechanisms are similar in WebGL2 and the extensions. Internally, we use basically the same paths for the extension as our WebGL2 implementation. -Jeff ----- Original Message ----- From: "Florian B?sch" To: "Kenneth Russell" Cc: "public webgl" Sent: Monday, June 9, 2014 9:18:59 PM Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved I think EXT_sRGB should be moved to community approved with all due haste so as to avoid Mozilla having to retract their implementation, and so that iOS can include the functionality. These devices support EXT_sRGB natively. - iPad 2 - iPad 3 - iPad 4 - iPhone 4s - iPhone 5 - iPhone 5C - iPhone 5s - iPad Air - iPad mini (and retina) - iPod touch 5th gen - Xiaomi MiniPad - Samsung SM-G870 But these devices are not OpenGL ES 3.0 compatible: - iPad 2 - iPad 3 - iPad 4 - iPhone 4s - iPhone 5 - iPHone 5C - iPod touch 5G Of These, the following are iOS8 compatible: - iPad 2 - iPad 3 - iPad 4 - iPhone 4s - iPhone 5 - iPhone 5C - iPod touch 5G If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not include support for it in iOS8. That would mean that until Apple appears with a WebGL2 implementation, sRGB will not be available on the the iPhone 5s, iPad Air and iPad mini. But worse, it would never be available on the iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which represent a sizable bulk (the majority?) of iOS devices in use, and cannot support WebGL2. On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell wrote: > It sounds like all implementers that have responded are in favor of > moving EXT_frag_depth to community approved. Thanks for pushing on > this. Merged your pull request. > > > > On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch wrote: > > Any progress on moving EXT_frag_depth to community approved? > ----------------------------------------------------------- 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 Jun 10 15:18:59 2014 From: kbr...@ (Kenneth Russell) Date: Tue, 10 Jun 2014 15:18:59 -0700 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> Message-ID: >From my standpoint it's a requirement that ANGLE expose the extension in its ES 2.0 backend before the EXT_sRGB WebGL extension be moved to community approved status. Shannon Woods from the ANGLE team has pointed out an essential difference between EXT_sRGB and ES 3.0's built-in sRGB functionality, which is that EXT_sRGB exposes sRGB texture formats, while ES 3.0 exposes sRGB texture internal formats. This might only be a minor issue to address but it needs to be investigated. I've filed https://code.google.com/p/angleproject/issues/detail?id=672 about it. -Ken On Tue, Jun 10, 2014 at 2:51 PM, Jeff Gilbert wrote: > Interesting, I was just wondering about this. FWIW, implementation of extensions that are core in WebGL 2 shouldn't be much of a burden, since the mechanisms are similar in WebGL2 and the extensions. Internally, we use basically the same paths for the extension as our WebGL2 implementation. > > -Jeff > > ----- Original Message ----- > From: "Florian B?sch" > To: "Kenneth Russell" > Cc: "public webgl" > Sent: Monday, June 9, 2014 9:18:59 PM > Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved > > I think EXT_sRGB should be moved to community approved with all due haste > so as to avoid Mozilla having to retract their implementation, and so that > iOS can include the functionality. > > These devices support EXT_sRGB natively. > > - iPad 2 > - iPad 3 > - iPad 4 > - iPhone 4s > - iPhone 5 > - iPhone 5C > - iPhone 5s > - iPad Air > - iPad mini (and retina) > - iPod touch 5th gen > - Xiaomi MiniPad > - Samsung SM-G870 > > But these devices are not OpenGL ES 3.0 compatible: > > - iPad 2 > - iPad 3 > - iPad 4 > - iPhone 4s > - iPhone 5 > - iPHone 5C > - iPod touch 5G > > Of These, the following are iOS8 compatible: > > - iPad 2 > - iPad 3 > - iPad 4 > - iPhone 4s > - iPhone 5 > - iPhone 5C > - iPod touch 5G > > If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not > include support for it in iOS8. That would mean that until Apple appears > with a WebGL2 implementation, sRGB will not be available on the the iPhone > 5s, iPad Air and iPad mini. But worse, it would never be available on the > iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which > represent a sizable bulk (the majority?) of iOS devices in use, and cannot > support WebGL2. > > > On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell wrote: > >> It sounds like all implementers that have responded are in favor of >> moving EXT_frag_depth to community approved. Thanks for pushing on >> this. Merged your pull request. >> >> >> >> On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch wrote: >> > Any progress on moving EXT_frag_depth to community approved? >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Tue Jun 10 16:19:38 2014 From: jgi...@ (Jeff Gilbert) Date: Tue, 10 Jun 2014 16:19:38 -0700 (PDT) Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> Message-ID: <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Why? WebGL as a spec should not be gated on ANGLE, even if sometimes we get de facto blocked on the translator. If UAs are able to support an agreed-upon extension in the absence of ANGLE-D3D-backend support, should it be possible to promote from Draft? Apple, in particular, has no interest in the D3D backend, and neither do two of Mozilla's products. In general, WebGL2 has a bunch of differences regarding how the internalFormat==format invariant no longer exists in ES3. sRGB won't be the only area with this issue. -Jeff ----- Original Message ----- From: "Kenneth Russell" To: "Jeff Gilbert" Cc: "Florian B?sch" , "public webgl" Sent: Tuesday, June 10, 2014 3:18:59 PM Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved >From my standpoint it's a requirement that ANGLE expose the extension in its ES 2.0 backend before the EXT_sRGB WebGL extension be moved to community approved status. Shannon Woods from the ANGLE team has pointed out an essential difference between EXT_sRGB and ES 3.0's built-in sRGB functionality, which is that EXT_sRGB exposes sRGB texture formats, while ES 3.0 exposes sRGB texture internal formats. This might only be a minor issue to address but it needs to be investigated. I've filed https://code.google.com/p/angleproject/issues/detail?id=672 about it. -Ken On Tue, Jun 10, 2014 at 2:51 PM, Jeff Gilbert wrote: > Interesting, I was just wondering about this. FWIW, implementation of extensions that are core in WebGL 2 shouldn't be much of a burden, since the mechanisms are similar in WebGL2 and the extensions. Internally, we use basically the same paths for the extension as our WebGL2 implementation. > > -Jeff > > ----- Original Message ----- > From: "Florian B?sch" > To: "Kenneth Russell" > Cc: "public webgl" > Sent: Monday, June 9, 2014 9:18:59 PM > Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved > > I think EXT_sRGB should be moved to community approved with all due haste > so as to avoid Mozilla having to retract their implementation, and so that > iOS can include the functionality. > > These devices support EXT_sRGB natively. > > - iPad 2 > - iPad 3 > - iPad 4 > - iPhone 4s > - iPhone 5 > - iPhone 5C > - iPhone 5s > - iPad Air > - iPad mini (and retina) > - iPod touch 5th gen > - Xiaomi MiniPad > - Samsung SM-G870 > > But these devices are not OpenGL ES 3.0 compatible: > > - iPad 2 > - iPad 3 > - iPad 4 > - iPhone 4s > - iPhone 5 > - iPHone 5C > - iPod touch 5G > > Of These, the following are iOS8 compatible: > > - iPad 2 > - iPad 3 > - iPad 4 > - iPhone 4s > - iPhone 5 > - iPhone 5C > - iPod touch 5G > > If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not > include support for it in iOS8. That would mean that until Apple appears > with a WebGL2 implementation, sRGB will not be available on the the iPhone > 5s, iPad Air and iPad mini. But worse, it would never be available on the > iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which > represent a sizable bulk (the majority?) of iOS devices in use, and cannot > support WebGL2. > > > On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell wrote: > >> It sounds like all implementers that have responded are in favor of >> moving EXT_frag_depth to community approved. Thanks for pushing on >> this. Merged your pull request. >> >> >> >> On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch wrote: >> > Any progress on moving EXT_frag_depth to community approved? >> ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From zmo...@ Tue Jun 10 16:44:12 2014 From: zmo...@ (Zhenyao Mo) Date: Tue, 10 Jun 2014 16:44:12 -0700 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: It is not to tie WebGL to ANGLE, but whatever we implement, it should be supported on all major platforms. If an extension doesn't have the potential to be supported on Windows, then maybe we should not support it at all. On Tue, Jun 10, 2014 at 4:19 PM, Jeff Gilbert wrote: > > Why? WebGL as a spec should not be gated on ANGLE, even if sometimes we > get de facto blocked on the translator. If UAs are able to support an > agreed-upon extension in the absence of ANGLE-D3D-backend support, should > it be possible to promote from Draft? Apple, in particular, has no interest > in the D3D backend, and neither do two of Mozilla's products. > > In general, WebGL2 has a bunch of differences regarding how the > internalFormat==format invariant no longer exists in ES3. sRGB won't be the > only area with this issue. > > -Jeff > > ----- Original Message ----- > From: "Kenneth Russell" > To: "Jeff Gilbert" > Cc: "Florian B?sch" , "public webgl" < > public_webgl...@> > Sent: Tuesday, June 10, 2014 3:18:59 PM > Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community > approved > > From my standpoint it's a requirement that ANGLE expose the extension > in its ES 2.0 backend before the EXT_sRGB WebGL extension be moved to > community approved status. Shannon Woods from the ANGLE team has > pointed out an essential difference between EXT_sRGB and ES 3.0's > built-in sRGB functionality, which is that EXT_sRGB exposes sRGB > texture formats, while ES 3.0 exposes sRGB texture internal formats. > This might only be a minor issue to address but it needs to be > investigated. I've filed > https://code.google.com/p/angleproject/issues/detail?id=672 about it. > > -Ken > > > On Tue, Jun 10, 2014 at 2:51 PM, Jeff Gilbert > wrote: > > Interesting, I was just wondering about this. FWIW, implementation of > extensions that are core in WebGL 2 shouldn't be much of a burden, since > the mechanisms are similar in WebGL2 and the extensions. Internally, we use > basically the same paths for the extension as our WebGL2 implementation. > > > > -Jeff > > > > ----- Original Message ----- > > From: "Florian B?sch" > > To: "Kenneth Russell" > > Cc: "public webgl" > > Sent: Monday, June 9, 2014 9:18:59 PM > > Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community > approved > > > > I think EXT_sRGB should be moved to community approved with all due haste > > so as to avoid Mozilla having to retract their implementation, and so > that > > iOS can include the functionality. > > > > These devices support EXT_sRGB natively. > > > > - iPad 2 > > - iPad 3 > > - iPad 4 > > - iPhone 4s > > - iPhone 5 > > - iPhone 5C > > - iPhone 5s > > - iPad Air > > - iPad mini (and retina) > > - iPod touch 5th gen > > - Xiaomi MiniPad > > - Samsung SM-G870 > > > > But these devices are not OpenGL ES 3.0 compatible: > > > > - iPad 2 > > - iPad 3 > > - iPad 4 > > - iPhone 4s > > - iPhone 5 > > - iPHone 5C > > - iPod touch 5G > > > > Of These, the following are iOS8 compatible: > > > > - iPad 2 > > - iPad 3 > > - iPad 4 > > - iPhone 4s > > - iPhone 5 > > - iPhone 5C > > - iPod touch 5G > > > > If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not > > include support for it in iOS8. That would mean that until Apple appears > > with a WebGL2 implementation, sRGB will not be available on the the > iPhone > > 5s, iPad Air and iPad mini. But worse, it would never be available on the > > iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which > > represent a sizable bulk (the majority?) of iOS devices in use, and > cannot > > support WebGL2. > > > > > > On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell wrote: > > > >> It sounds like all implementers that have responded are in favor of > >> moving EXT_frag_depth to community approved. Thanks for pushing on > >> this. Merged your pull request. > >> > >> > >> > >> On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch wrote: > >> > Any progress on moving EXT_frag_depth to community approved? > >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Tue Jun 10 16:46:52 2014 From: zmo...@ (Zhenyao Mo) Date: Tue, 10 Jun 2014 16:46:52 -0700 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: To be clear, I am not against this specific extension for WebGL 1. If anyone is willing to implement it in ANGLE for ES2, then definitely yes. On Tue, Jun 10, 2014 at 4:44 PM, Zhenyao Mo wrote: > It is not to tie WebGL to ANGLE, but whatever we implement, it should be > supported on all major platforms. If an extension doesn't have the > potential to be supported on Windows, then maybe we should not support it > at all. > > > On Tue, Jun 10, 2014 at 4:19 PM, Jeff Gilbert > wrote: > >> >> Why? WebGL as a spec should not be gated on ANGLE, even if sometimes we >> get de facto blocked on the translator. If UAs are able to support an >> agreed-upon extension in the absence of ANGLE-D3D-backend support, should >> it be possible to promote from Draft? Apple, in particular, has no interest >> in the D3D backend, and neither do two of Mozilla's products. >> >> In general, WebGL2 has a bunch of differences regarding how the >> internalFormat==format invariant no longer exists in ES3. sRGB won't be the >> only area with this issue. >> >> -Jeff >> >> ----- Original Message ----- >> From: "Kenneth Russell" >> To: "Jeff Gilbert" >> Cc: "Florian B?sch" , "public webgl" < >> public_webgl...@> >> Sent: Tuesday, June 10, 2014 3:18:59 PM >> Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community >> approved >> >> From my standpoint it's a requirement that ANGLE expose the extension >> in its ES 2.0 backend before the EXT_sRGB WebGL extension be moved to >> community approved status. Shannon Woods from the ANGLE team has >> pointed out an essential difference between EXT_sRGB and ES 3.0's >> built-in sRGB functionality, which is that EXT_sRGB exposes sRGB >> texture formats, while ES 3.0 exposes sRGB texture internal formats. >> This might only be a minor issue to address but it needs to be >> investigated. I've filed >> https://code.google.com/p/angleproject/issues/detail?id=672 about it. >> >> -Ken >> >> >> On Tue, Jun 10, 2014 at 2:51 PM, Jeff Gilbert >> wrote: >> > Interesting, I was just wondering about this. FWIW, implementation of >> extensions that are core in WebGL 2 shouldn't be much of a burden, since >> the mechanisms are similar in WebGL2 and the extensions. Internally, we use >> basically the same paths for the extension as our WebGL2 implementation. >> > >> > -Jeff >> > >> > ----- Original Message ----- >> > From: "Florian B?sch" >> > To: "Kenneth Russell" >> > Cc: "public webgl" >> > Sent: Monday, June 9, 2014 9:18:59 PM >> > Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to >> community approved >> > >> > I think EXT_sRGB should be moved to community approved with all due >> haste >> > so as to avoid Mozilla having to retract their implementation, and so >> that >> > iOS can include the functionality. >> > >> > These devices support EXT_sRGB natively. >> > >> > - iPad 2 >> > - iPad 3 >> > - iPad 4 >> > - iPhone 4s >> > - iPhone 5 >> > - iPhone 5C >> > - iPhone 5s >> > - iPad Air >> > - iPad mini (and retina) >> > - iPod touch 5th gen >> > - Xiaomi MiniPad >> > - Samsung SM-G870 >> > >> > But these devices are not OpenGL ES 3.0 compatible: >> > >> > - iPad 2 >> > - iPad 3 >> > - iPad 4 >> > - iPhone 4s >> > - iPhone 5 >> > - iPHone 5C >> > - iPod touch 5G >> > >> > Of These, the following are iOS8 compatible: >> > >> > - iPad 2 >> > - iPad 3 >> > - iPad 4 >> > - iPhone 4s >> > - iPhone 5 >> > - iPhone 5C >> > - iPod touch 5G >> > >> > If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not >> > include support for it in iOS8. That would mean that until Apple appears >> > with a WebGL2 implementation, sRGB will not be available on the the >> iPhone >> > 5s, iPad Air and iPad mini. But worse, it would never be available on >> the >> > iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which >> > represent a sizable bulk (the majority?) of iOS devices in use, and >> cannot >> > support WebGL2. >> > >> > >> > On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell >> wrote: >> > >> >> It sounds like all implementers that have responded are in favor of >> >> moving EXT_frag_depth to community approved. Thanks for pushing on >> >> this. Merged your pull request. >> >> >> >> >> >> >> >> On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch >> wrote: >> >> > Any progress on moving EXT_frag_depth to community approved? >> >> >> >> ----------------------------------------------------------- >> 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 juj...@ Tue Jun 10 18:46:10 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Wed, 11 Jun 2014 04:46:10 +0300 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? Message-ID: Hi there, I raised a discussion about the need for explicit API or spec-guaranteed mechanism for resizing a WebGL canvas size to be pixel-perfect in the WebGL issue tracker. In the interest of not retyping everything, here's a link to the details: https://github.com/KhronosGroup/WebGL/issues/587 The quick summary: When trying to come up the proper device pixel size for a WebGL canvas so that it properly matches the actual size displayed by the browser, fractional window.devicePixelRatio values in the wild (1.5 and 2.25 have been seen) pose problems, and to get the right result, one has to either floor, round or ceil the result depending on the devicePixelRatio and device resolution in question. We need to spec down a method that is guaranteed to work so that off-by-one-pixel errors cannot possibly occur. What should such a mechanism look like that can take into account arbitrarily fractional devicePixelRatios out there? Jukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 10 21:23:58 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Jun 2014 06:23:58 +0200 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: *Recap of sRGB functionality* The EXT_sRGB extension provides native support for the sRGB color format. sRGB is a non-linear color format, and most picture source data that WebGL will encounter will be encoded in it (such as jpeg, or PNGs with the sRGB color profile), additionally most display devices that WebGL will run on, will assume colors to be output in sRGB. More information about that format can be had here http://en.wikipedia.org/wiki/SRGB and here http://www.color.org/srgb.pdf A simple implementation of sRGB in a shader looks like this: vec3 gamma(vec3 color){ return mix( color * 12.92, 1.055*pow(color, vec3(1.0/2.4)) - 0.055, step(0.0031308, color) ); } vec3 degamma(vec3 color){ return mix( color/12.92, pow((color + 0.055)/1.055, vec3(2.4)), step(0.04045, color) ); } However there are some problems in supporting sRGB this way manually. - Linear interpolation on texture lookups would perform interpolation in non-linear space - Mipmapped lookups would perform level interpolation in non-linear space - Mipmap generation would perform generation in non-linear space - Blending to a framebuffer would perform blending in non-linear space - Anti-Aliasing would perform in non-linear space EXT_sRGB was introduced to solve these problems, and it solves them in the following fashion: - texImage2D and texSubImage2D accept SRGB_EXT and SRGB_ALPHA_EXT as an internal format descriptor. These should cause the following effects - Linear interpolation first performs the degamma on the 4 texels concerned, interpolates them, and returns that value to the shader. - Mipmap level interpolation first performs the degamma on the source data for the two levels, mixes the levels and returns that value to the shader - Mipmap generation does not work with sRGB, and will crap out with an INVALID_OPERATION (the user is responsibly to supply sRGB correct miplevels) - If a sRGB texture is attached to a framebuffer, it will cause blending/AA to use linear color space source values from the shader, and use these to mix the output before applying gamma. - renderBufferStorage accepts SRGB8_ALPHA8_EXT. In case of a color storage, this causes blending/AA to use linear color space source values from the shader, and use these to mix the output before applying gamma ES 3.0 supports sRGB in the core, the specification follows the same semantic as EXT_sRGB, in that: - texImage2D, texSubImage2D etc. accept SRGB8 and SRGB8_ALPHA8 - renderBufferStorage accepts SRGB8_ALPHA8 *Direct3D* The ability to perform degamma before read and gamma before write is present in Direct3D 9, specifically: - The sampler state D3DSAMP_SRGBTEXTURE performs the same function as OpenGL's SRGB and SRGB_ALPHA - The render state D3DRS_SRGBWRITEENABLE performs the same function as attaching an OpenGL sRGB texture to a framebuffer, or using the renderBufferStorage parameter SRGB8_ALPHA8 See more information here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb173460(v=vs.85).aspx *Angle gating* I don't think an extension should be Direct3D angle gated from community approved if the following conditions are met: - It is agreed that the extension is necessary - Implementations of the extension exist (which pass the unit tests) - It can be supported by Angle These conditions seem to be met for sRGB, barring any objection to this assertion to follow. This working principle is the same as was adopted for gating features on mobile functionality, where if those conditions where not met, an extension could not proceed. Quite a few extensions which didn't have mobile support at the time, made it to community approved on the grounds that it was agreed that the extension was necessary, that implementations of it exist that pass the unit tests and that a good portion of mobiles can support that extension. So I don't see a reason to provide preferential treatment to Direct3D angle in that regard. On Wed, Jun 11, 2014 at 1:46 AM, Zhenyao Mo wrote: > To be clear, I am not against this specific extension for WebGL 1. > > If anyone is willing to implement it in ANGLE for ES2, then definitely yes. > > > On Tue, Jun 10, 2014 at 4:44 PM, Zhenyao Mo wrote: > >> It is not to tie WebGL to ANGLE, but whatever we implement, it should be >> supported on all major platforms. If an extension doesn't have the >> potential to be supported on Windows, then maybe we should not support it >> at all. >> >> >> On Tue, Jun 10, 2014 at 4:19 PM, Jeff Gilbert >> wrote: >> >>> >>> Why? WebGL as a spec should not be gated on ANGLE, even if sometimes we >>> get de facto blocked on the translator. If UAs are able to support an >>> agreed-upon extension in the absence of ANGLE-D3D-backend support, should >>> it be possible to promote from Draft? Apple, in particular, has no interest >>> in the D3D backend, and neither do two of Mozilla's products. >>> >>> In general, WebGL2 has a bunch of differences regarding how the >>> internalFormat==format invariant no longer exists in ES3. sRGB won't be the >>> only area with this issue. >>> >>> -Jeff >>> >>> ----- Original Message ----- >>> From: "Kenneth Russell" >>> To: "Jeff Gilbert" >>> Cc: "Florian B?sch" , "public webgl" < >>> public_webgl...@> >>> Sent: Tuesday, June 10, 2014 3:18:59 PM >>> Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community >>> approved >>> >>> From my standpoint it's a requirement that ANGLE expose the extension >>> in its ES 2.0 backend before the EXT_sRGB WebGL extension be moved to >>> community approved status. Shannon Woods from the ANGLE team has >>> pointed out an essential difference between EXT_sRGB and ES 3.0's >>> built-in sRGB functionality, which is that EXT_sRGB exposes sRGB >>> texture formats, while ES 3.0 exposes sRGB texture internal formats. >>> This might only be a minor issue to address but it needs to be >>> investigated. I've filed >>> https://code.google.com/p/angleproject/issues/detail?id=672 about it. >>> >>> -Ken >>> >>> >>> On Tue, Jun 10, 2014 at 2:51 PM, Jeff Gilbert >>> wrote: >>> > Interesting, I was just wondering about this. FWIW, implementation of >>> extensions that are core in WebGL 2 shouldn't be much of a burden, since >>> the mechanisms are similar in WebGL2 and the extensions. Internally, we use >>> basically the same paths for the extension as our WebGL2 implementation. >>> > >>> > -Jeff >>> > >>> > ----- Original Message ----- >>> > From: "Florian B?sch" >>> > To: "Kenneth Russell" >>> > Cc: "public webgl" >>> > Sent: Monday, June 9, 2014 9:18:59 PM >>> > Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to >>> community approved >>> > >>> > I think EXT_sRGB should be moved to community approved with all due >>> haste >>> > so as to avoid Mozilla having to retract their implementation, and so >>> that >>> > iOS can include the functionality. >>> > >>> > These devices support EXT_sRGB natively. >>> > >>> > - iPad 2 >>> > - iPad 3 >>> > - iPad 4 >>> > - iPhone 4s >>> > - iPhone 5 >>> > - iPhone 5C >>> > - iPhone 5s >>> > - iPad Air >>> > - iPad mini (and retina) >>> > - iPod touch 5th gen >>> > - Xiaomi MiniPad >>> > - Samsung SM-G870 >>> > >>> > But these devices are not OpenGL ES 3.0 compatible: >>> > >>> > - iPad 2 >>> > - iPad 3 >>> > - iPad 4 >>> > - iPhone 4s >>> > - iPhone 5 >>> > - iPHone 5C >>> > - iPod touch 5G >>> > >>> > Of These, the following are iOS8 compatible: >>> > >>> > - iPad 2 >>> > - iPad 3 >>> > - iPad 4 >>> > - iPhone 4s >>> > - iPhone 5 >>> > - iPhone 5C >>> > - iPod touch 5G >>> > >>> > If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could >>> not >>> > include support for it in iOS8. That would mean that until Apple >>> appears >>> > with a WebGL2 implementation, sRGB will not be available on the the >>> iPhone >>> > 5s, iPad Air and iPad mini. But worse, it would never be available on >>> the >>> > iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which >>> > represent a sizable bulk (the majority?) of iOS devices in use, and >>> cannot >>> > support WebGL2. >>> > >>> > >>> > On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell >>> wrote: >>> > >>> >> It sounds like all implementers that have responded are in favor of >>> >> moving EXT_frag_depth to community approved. Thanks for pushing on >>> >> this. Merged your pull request. >>> >> >>> >> >>> >> >>> >> On Mon, Jun 9, 2014 at 3:34 AM, Florian B?sch >>> wrote: >>> >> > Any progress on moving EXT_frag_depth to community approved? >>> >> >>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> unsubscribe public_webgl >>> ----------------------------------------------------------- >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 10 21:53:47 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Jun 2014 06:53:47 +0200 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: Your issue description mentions trying to do a pixel perfect canvas under conditions of zoom by the user. I think this can be understood to mean either that: - You want to display the same resolution pixel perfectly disregarding user zoom level, which would be impossible, because unless you adjust the resolution, you cannot get pixel perfection. - You want to resize the resolution to be pixel perfect given the soom level, which would also be impossible, because if the user say, zooms in 10x, then your canvas size would bloat to 10x its size, say it was 1600x1600 at 1:1 zoom, at 10:1 zoom it would now be 16kx16k, which is larger than the framebuffer supported by any existing hardware. It would seem to me that the argument for pixel perfection in respect to device pixel ratio can only apply when there is no user-zoom. Additionally, pixel perfection will be marred if a scroll is applied by a user, that's 1 pixel in the pixel device ratio, but would be 0.5 pixels in the "pretend" resolution. In this case the underlying texels to be blit would meet in the middle of "pretend" pixels. I too think, this case cannot be handled, because the only way to handle it would be to "pretend" pixel clamp the canvas position, which would lead to an undesirable stepping effect on scroll. As far as I can see, the remaining beef lies with how to make sure that a canvas of given pretend pixel size, uses an underlying renderbuffer of device pixel size. Traditionally the ratio would have been 1 or 2, but the fractional ratios certainly complicate things. But isn't it the case that if you floor the size, that you should be fine, because you can discount the impossible cases discussed above? On Wed, Jun 11, 2014 at 3:46 AM, Jukka Jyl?nki wrote: > Hi there, > > I raised a discussion about the need for explicit API or spec-guaranteed > mechanism for resizing a WebGL canvas size to be pixel-perfect in the WebGL > issue tracker. In the interest of not retyping everything, here's a link to > the details: > > https://github.com/KhronosGroup/WebGL/issues/587 > > The quick summary: When trying to come up the proper device pixel size for > a WebGL canvas so that it properly matches the actual size displayed by the > browser, fractional window.devicePixelRatio values in the wild (1.5 and > 2.25 have been seen) pose problems, and to get the right result, one has to > either floor, round or ceil the result depending on the devicePixelRatio > and device resolution in question. > > We need to spec down a method that is guaranteed to work so that > off-by-one-pixel errors cannot possibly occur. What should such a mechanism > look like that can take into account arbitrarily fractional > devicePixelRatios out there? > > Jukka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cab...@ Tue Jun 10 22:25:21 2014 From: cab...@ (Rik Cabanier) Date: Tue, 10 Jun 2014 22:25:21 -0700 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: On Tue, Jun 10, 2014 at 6:46 PM, Jukka Jyl?nki wrote: > Hi there, > > I raised a discussion about the need for explicit API or spec-guaranteed > mechanism for resizing a WebGL canvas size to be pixel-perfect in the WebGL > issue tracker. In the interest of not retyping everything, here's a link to > the details: > > https://github.com/KhronosGroup/WebGL/issues/587 > > The quick summary: When trying to come up the proper device pixel size for > a WebGL canvas so that it properly matches the actual size displayed by the > browser, fractional window.devicePixelRatio values in the wild (1.5 and > 2.25 have been seen) pose problems, and to get the right result, one has to > either floor, round or ceil the result depending on the devicePixelRatio > and device resolution in question. > Browser zoom (= ctrl/cmd +/-) also affects DPR. Someone from Google maps stated that 15% of all users have some level of browser zoom enabled. > We need to spec down a method that is guaranteed to work so that > off-by-one-pixel errors cannot possibly occur. What should such a mechanism > look like that can take into account arbitrarily fractional > devicePixelRatios out there? > Canvas 2D is suffering from the same issue. There was a thread on this on WhatWG: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/252483.html We went through the issues but it seemed too complex to solve this in the browser. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 10 22:31:35 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Jun 2014 07:31:35 +0200 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier wrote: > Browser zoom (= ctrl/cmd +/-) also affects DPR. > Someone from Google maps stated that 15% of all users have some level of > browser zoom enabled. > I didn't know that. That's quite odd, and completely unusable for WebGL because there are limits to the size you can set a framebuffer to as well as that rendering to ridiculous resolutions would become very slow, very quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Tue Jun 10 22:41:03 2014 From: tpa...@ (Tony Parisi) Date: Tue, 10 Jun 2014 22:41:03 -0700 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> I am skeptical of that figure... Where is the data to support it? My guess is that less than 5% of users even know about the zoom features... And yeah it's bad for WebGL graphics Tony Parisi CTO at Large 415.902.8002 > On Jun 10, 2014, at 10:31 PM, Florian B?sch wrote: > >> On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier wrote: >> Browser zoom (= ctrl/cmd +/-) also affects DPR. >> Someone from Google maps stated that 15% of all users have some level of browser zoom enabled. > I didn't know that. That's quite odd, and completely unusable for WebGL because there are limits to the size you can set a framebuffer to as well as that rendering to ridiculous resolutions would become very slow, very quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cab...@ Tue Jun 10 22:55:13 2014 From: cab...@ (Rik Cabanier) Date: Tue, 10 Jun 2014 22:55:13 -0700 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> References: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> Message-ID: On Tue, Jun 10, 2014 at 10:41 PM, Tony Parisi wrote: > I am skeptical of that figure... Where is the data to support it? > > My guess is that less than 5% of users even know about the zoom > features... > I was very surprised about that figure too. It's been over a year since he sent that out and I'm having trouble finding his message. > And yeah it's bad for WebGL graphics > > Tony Parisi > CTO at Large > 415.902.8002 > > > On Jun 10, 2014, at 10:31 PM, Florian B?sch wrote: > > On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier wrote: > >> Browser zoom (= ctrl/cmd +/-) also affects DPR. >> Someone from Google maps stated that 15% of all users have some level of >> browser zoom enabled. >> > I didn't know that. That's quite odd, and completely unusable for WebGL > because there are limits to the size you can set a framebuffer to as well > as that rendering to ridiculous resolutions would become very slow, very > quickly. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eva...@ Wed Jun 11 00:05:29 2014 From: eva...@ (Evan Wallace) Date: Wed, 11 Jun 2014 00:05:29 -0700 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> Message-ID: This is an issue I'm struggling with too. There aren't any problems with framebuffer size in my case though. I'm trying to cover most of the screen with a WebGL canvas and that area has the same number of physical pixels regardless of zoom level (well, it's really a little less after you zoom in because the UI around the canvas grows in size a bit). DPI handling works by setting the canvas width/height to the CSS width/height times the devicePixelRatio, so the canvas framebuffer is approximately scaled 1:1 with physical pixels. For fullscreen WebGL apps, zooming in makes the window size go down and the devicePixelRatio go up to match. The problem is that CSS only lets you set the canvas size to integer values, and most of the time it's impossible to specify an integer width/height such that the zoomed canvas is exactly the size you need. Demo showing the problem: http://fiddle.jshell.net/V884T/show/ (zoom in and the grid won't match 1:1). Strawman API proposal: add a "scaled: false" parameter to the WebGL context creation attributes that would always render the framebuffer from the top left corner at 1:1 with physical pixels (i.e. not scaled) without affecting the size of the canvas element itself. On Tuesday, June 10, 2014, Rik Cabanier wrote: > > > > On Tue, Jun 10, 2014 at 10:41 PM, Tony Parisi > wrote: > >> I am skeptical of that figure... Where is the data to support it? >> >> My guess is that less than 5% of users even know about the zoom >> features... >> > > I was very surprised about that figure too. It's been over a year since he > sent that out and I'm having trouble finding his message. > > >> And yeah it's bad for WebGL graphics >> >> Tony Parisi >> CTO at Large >> 415.902.8002 >> >> >> On Jun 10, 2014, at 10:31 PM, Florian B?sch > > wrote: >> >> On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier > > wrote: >> >>> Browser zoom (= ctrl/cmd +/-) also affects DPR. >>> Someone from Google maps stated that 15% of all users have some level of >>> browser zoom enabled. >>> >> I didn't know that. That's quite odd, and completely unusable for WebGL >> because there are limits to the size you can set a framebuffer to as well >> as that rendering to ridiculous resolutions would become very slow, very >> quickly. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed Jun 11 00:25:02 2014 From: cal...@ (Mark Callow) Date: Wed, 11 Jun 2014 16:25:02 +0900 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: <5398044E.4000804@artspark.co.jp> On 11/06/2014 14:31, Florian B?sch wrote: > > I didn't know that. That's quite odd, and completely unusable for > WebGL because there are limits to the size you can set a framebuffer > to as well as that rendering to ridiculous resolutions would become > very slow, very quickly. I don't think the size of the framebuffer is an issue, it's the viewport size restriction. You can use a smaller framebuffer and appropriate viewport and scissor settings to render just the zoomed-in part of your scene into the framebuffer. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed Jun 11 00:27:59 2014 From: cal...@ (Mark Callow) Date: Wed, 11 Jun 2014 16:27:59 +0900 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> References: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> Message-ID: <539804FF.2050207@artspark.co.jp> On 11/06/2014 14:41, Tony Parisi wrote: > I am skeptical of that figure... Where is the data to support it? > > My guess is that less than 5% of users even know about the zoom > features... > Is pinch-zoom different that the effect of CTRL/CMD [+-]? Are they not both browser zoom? I am certain that more than 5% of users know about pinch-zoom. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kir...@ Wed Jun 11 02:34:57 2014 From: kir...@ (Kirill Prazdnikov) Date: Wed, 11 Jun 2014 13:34:57 +0400 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: <539822C1.6070405@jetbrains.com> Hi Jukka I've spent much time with this issue. Unfortunately, the problem is VERY serious because all HTML 5 API is based on Integer. All page layout (almost all except one method) operates with integer numbers. And this is the root of problem. For some zoom factors and some lay-outing you can not achieve pixel-to-pixel match. For example: assume devicePixelRatio is 1.3333333 (33% zoom) and all you HTML Elements coordinates will be divided by 1.(33) and then ROUNDED. So then if you get the element coordinated back and multiply by 1.(33) to get display pixels, you may get +-1 pixel error after second rounding: What browser does: > HTML.element.x = Math.round(Layout.x(y) / devicePixelRatio); > Then you get this value and do reverse > int deviceCoord = Math.round(HTML.element.x * devicePixelRatio); > Canvas.setPos(deviceCoord); Two sequential rounds may produce 1 pixel error which will result to blurry image. Unfortunately, this is a fundamental HTML API issue. In perfect world all HTML elements layout API sould be in double precision. -Kirill On 11.06.2014 5:46, Jukka Jyl?nki wrote: > Hi there, > > I raised a discussion about the need for explicit API or > spec-guaranteed mechanism for resizing a WebGL canvas size to be > pixel-perfect in the WebGL issue tracker. In the interest of not > retyping everything, here's a link to the details: > > https://github.com/KhronosGroup/WebGL/issues/587 > > The quick summary: When trying to come up the proper device pixel size > for a WebGL canvas so that it properly matches the actual size > displayed by the browser, fractional window.devicePixelRatio values in > the wild (1.5 and 2.25 have been seen) pose problems, and to get the > right result, one has to either floor, round or ceil the result > depending on the devicePixelRatio and device resolution in question. > > We need to spec down a method that is guaranteed to work so that > off-by-one-pixel errors cannot possibly occur. What should such a > mechanism look like that can take into account arbitrarily fractional > devicePixelRatios out there? > > Jukka ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From juj...@ Wed Jun 11 06:03:53 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Wed, 11 Jun 2014 16:03:53 +0300 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: Good points Florian. I agree with these: - I care about rendering pixel-perfect only if page has not been zoomed, i.e. if user had zoomed to 150%, I don't have a need to get a larger GL framebuffer size that'd natively match that resized area. If window.devicePixelRatio changes according to zoom level, that sounds bad, exactly due to the max framebuffer size restrictions. - Also, if a page has been scrolled to sub-pixel offsets, that could produce cases where precise match doesn't occur. Regarding scrolling, I would only care that there is a programmatic way to set the scroll position of a page to a value where pixels are guaranteed to align up, and/or that scroll = 0 would always guarantee pixels to align up. 2014-06-11 7:53 GMT+03:00 Florian B?sch : > Your issue description mentions trying to do a pixel perfect canvas under > conditions of zoom by the user. I think this can be understood to mean > either that: > > - You want to display the same resolution pixel perfectly disregarding > user zoom level, which would be impossible, because unless you adjust the > resolution, you cannot get pixel perfection. > - You want to resize the resolution to be pixel perfect given the soom > level, which would also be impossible, because if the user say, zooms in > 10x, then your canvas size would bloat to 10x its size, say it was > 1600x1600 at 1:1 zoom, at 10:1 zoom it would now be 16kx16k, which is > larger than the framebuffer supported by any existing hardware. > > It would seem to me that the argument for pixel perfection in respect to > device pixel ratio can only apply when there is no user-zoom. > > Additionally, pixel perfection will be marred if a scroll is applied by a > user, that's 1 pixel in the pixel device ratio, but would be 0.5 pixels in > the "pretend" resolution. In this case the underlying texels to be blit > would meet in the middle of "pretend" pixels. I too think, this case cannot > be handled, because the only way to handle it would be to "pretend" pixel > clamp the canvas position, which would lead to an undesirable stepping > effect on scroll. > > As far as I can see, the remaining beef lies with how to make sure that a > canvas of given pretend pixel size, uses an underlying renderbuffer of > device pixel size. Traditionally the ratio would have been 1 or 2, but the > fractional ratios certainly complicate things. But isn't it the case that > if you floor the size, that you should be fine, because you can discount > the impossible cases discussed above? > > > On Wed, Jun 11, 2014 at 3:46 AM, Jukka Jyl?nki wrote: > >> Hi there, >> >> I raised a discussion about the need for explicit API or spec-guaranteed >> mechanism for resizing a WebGL canvas size to be pixel-perfect in the WebGL >> issue tracker. In the interest of not retyping everything, here's a link to >> the details: >> >> https://github.com/KhronosGroup/WebGL/issues/587 >> >> The quick summary: When trying to come up the proper device pixel size >> for a WebGL canvas so that it properly matches the actual size displayed by >> the browser, fractional window.devicePixelRatio values in the wild (1.5 and >> 2.25 have been seen) pose problems, and to get the right result, one has to >> either floor, round or ceil the result depending on the devicePixelRatio >> and device resolution in question. >> >> We need to spec down a method that is guaranteed to work so that >> off-by-one-pixel errors cannot possibly occur. What should such a mechanism >> look like that can take into account arbitrarily fractional >> devicePixelRatios out there? >> >> Jukka >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzb...@ Wed Jun 11 06:21:09 2014 From: bzb...@ (Boris Zbarsky) Date: Wed, 11 Jun 2014 09:21:09 -0400 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: <539857C5.1020104@mit.edu> On 6/11/14, 1:31 AM, Florian B?sch wrote: > That's quite odd It's not odd at all. Web site designers consistently use tiny fonts that are not very readable on higher-resolution (but not high enough to be considered "hidpi") screens. It's not uncommon to have text people are actually expected to read in a 12px or even 10px font. For browsers that have such a setting, and for users that know about it, setting a minimal font size is one way to handle the situation. But it's _way_ easier for most users to just bump the zoom a bit when faced with unreadably small text. -Boris ----------------------------------------------------------- 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 Jun 11 06:30:15 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Jun 2014 15:30:15 +0200 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: <539857C5.1020104@mit.edu> References: <539857C5.1020104@mit.edu> Message-ID: I wasn't refering to "odd" as the fact that people zoom. I was referring to odd that the pixel device ratio changes. Because the only way to make use of that information, will require breaking the application, inevitably. On Wed, Jun 11, 2014 at 3:21 PM, Boris Zbarsky wrote: > > On 6/11/14, 1:31 AM, Florian B?sch wrote: > >> That's quite odd >> > > It's not odd at all. Web site designers consistently use tiny fonts that > are not very readable on higher-resolution (but not high enough to be > considered "hidpi") screens. It's not uncommon to have text people are > actually expected to read in a 12px or even 10px font. > > For browsers that have such a setting, and for users that know about it, > setting a minimal font size is one way to handle the situation. But it's > _way_ easier for most users to just bump the zoom a bit when faced with > unreadably small text. > > -Boris > > > ----------------------------------------------------------- > 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 bzb...@ Wed Jun 11 06:44:49 2014 From: bzb...@ (Boris Zbarsky) Date: Wed, 11 Jun 2014 09:44:49 -0400 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: <539822C1.6070405@jetbrains.com> References: <539822C1.6070405@jetbrains.com> Message-ID: <53985D51.8010902@mit.edu> On 6/11/14, 5:34 AM, Kirill Prazdnikov wrote: > All page layout (almost all except one method) operates with integer > numbers. Not internally in browsers. > What browser does: >> HTML.element.x = Math.round(Layout.x(y) / devicePixelRatio); No modern browser does this internally, I believe. > Unfortunately, this is a fundamental HTML API issue. In perfect world > all HTML elements layout API sould be in double precision. getBoundingClientRect, getClientRects, and getBoxQuads return unrounded (or rather rounded to the browser's internal layout precision, not to integer CSS pixels) coordinates. -Boris ----------------------------------------------------------- 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 bzb...@ Wed Jun 11 07:01:38 2014 From: bzb...@ (Boris Zbarsky) Date: Wed, 11 Jun 2014 10:01:38 -0400 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: <539857C5.1020104@mit.edu> Message-ID: <53986142.1060004@mit.edu> On 6/11/14, 9:30 AM, Florian B?sch wrote: > I wasn't refering to "odd" as the fact that people zoom. I was referring > to odd that the pixel device ratio changes. Ah. It might or might not, depending on the zoom mode. Browsers have two distinct zoom modes in the wild: 1) The mobile browser zoom-and-pan mode (called "pinch zoom" in the cssom-view spec): zooming doesn't change layout, and simply performs a draw-time upscale or something close to it (font rasterization here is complicated). The size of the viewport (e.g. as measured by window.innerWidth) does not actually change in this mode. Instead, the page spills out of the viewport if you zoom in and you can pan around it. 2) The desktop browser page zoom mode (called "page zoom" in the spec): zooming changes the size of a CSS pixel as measured in device pixels (and hence the size of the viewport) then redoes the page layout using the new viewport size. Effectively, this corresponds more or less (again, with some font rasterization complications) to resizing the window and then doing a paint-time upscale back to the original size. This can change where linebreaks happen and whatnot. Typically the resulting layout will not spill out of the viewport horizontally. devicePixelRatio does not change when zoom mode #1 is used. In zoom mode #2, the actual ratio of device to CSS pixels is in fact changing. Some browsers correspondingly change the value of devicePixelRatio. Others seem not to. Per spec at http://dev.w3.org/csswg/cssom-view/#dom-window-devicepixelratio it should change in zoom mode #2. > Because the only way to make use of that information, will require breaking the application, inevitably. What are you trying to do with devicePixelRatio, exactly, where having it accurately reflect the ratio of CSS to device pixels won't work? -Boris ----------------------------------------------------------- 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 Jun 11 14:09:23 2014 From: kbr...@ (Kenneth Russell) Date: Wed, 11 Jun 2014 14:09:23 -0700 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> Message-ID: This issue is a deep one which can't be solved in isolation in the WebGL spec. Even ignoring page zoom, adding a context creation attribute like "scaled: false" will break many invariants in the web platform. For example, it would cause changes to the CSS width and height properties to have the side-effect of resizing the WebGL canvas's backing store. Resizes would start coming in asynchronously to the WebGL app. I don't think any browser implements per-element resize events. There would likely be other surprising and undesirable side-effects. It's possible that https://www.khronos.org/webgl/wiki/HandlingHighDPI just needs to be updated. If there are better ways to measure the number of device pixels that a given region or canvas will cover then let's update the page. Boris Zbarsky pointed out the getBoundingClientRect, getClientRects, and getBoxQuads APIs. Could someone who's been investigating this in depth please try them and see whether they solve the problem? I suggest considering the unzoomed case first because it seems to be the most common case. -Ken On Wed, Jun 11, 2014 at 12:05 AM, Evan Wallace wrote: > This is an issue I'm struggling with too. There aren't any problems with > framebuffer size in my case though. I'm trying to cover most of the screen > with a WebGL canvas and that area has the same number of physical pixels > regardless of zoom level (well, it's really a little less after you zoom in > because the UI around the canvas grows in size a bit). > > DPI handling works by setting the canvas width/height to the CSS > width/height times the devicePixelRatio, so the canvas framebuffer is > approximately scaled 1:1 with physical pixels. For fullscreen WebGL apps, > zooming in makes the window size go down and the devicePixelRatio go up to > match. > > The problem is that CSS only lets you set the canvas size to integer values, > and most of the time it's impossible to specify an integer width/height such > that the zoomed canvas is exactly the size you need. Demo showing the > problem: http://fiddle.jshell.net/V884T/show/ (zoom in and the grid won't > match 1:1). > > Strawman API proposal: add a "scaled: false" parameter to the WebGL context > creation attributes that would always render the framebuffer from the top > left corner at 1:1 with physical pixels (i.e. not scaled) without affecting > the size of the canvas element itself. > > > On Tuesday, June 10, 2014, Rik Cabanier wrote: >> >> >> >> >> On Tue, Jun 10, 2014 at 10:41 PM, Tony Parisi wrote: >>> >>> I am skeptical of that figure... Where is the data to support it? >>> >>> My guess is that less than 5% of users even know about the zoom >>> features... >> >> >> I was very surprised about that figure too. It's been over a year since he >> sent that out and I'm having trouble finding his message. >> >>> >>> And yeah it's bad for WebGL graphics >>> >>> Tony Parisi >>> CTO at Large >>> 415.902.8002 >>> >>> >>> On Jun 10, 2014, at 10:31 PM, Florian B?sch wrote: >>> >>> On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier wrote: >>>> >>>> Browser zoom (= ctrl/cmd +/-) also affects DPR. >>>> Someone from Google maps stated that 15% of all users have some level of >>>> browser zoom enabled. >>> >>> I didn't know that. That's quite odd, and completely unusable for WebGL >>> because there are limits to the size you can set a framebuffer to as well as >>> that rendering to ridiculous resolutions would become very slow, very >>> quickly. >> >> > ----------------------------------------------------------- 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 Jun 11 15:02:37 2014 From: kbr...@ (Kenneth Russell) Date: Wed, 11 Jun 2014 15:02:37 -0700 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: On Tue, Jun 10, 2014 at 9:23 PM, Florian B?sch wrote: > I don't think an extension should be Direct3D angle gated from community > approved if the following conditions are met: > > It is agreed that the extension is necessary > Implementations of the extension exist (which pass the unit tests) > It can be supported by Angle We're simply doing due diligence. Please give the ANGLE team a couple of days. A significant number of Chrome users are on Windows, and I am not ready to support moving this extension to community approved until it's known it can be supported in ANGLE's ES2 implementation. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From juj...@ Wed Jun 11 15:15:52 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Thu, 12 Jun 2014 01:15:52 +0300 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: <716A5772-50DC-4232-8F4C-F0E92564BB71@gmail.com> Message-ID: I tried getBoundingClientRect yesterday, only to realize that that or others can't solve the issue. If I build a canvas element like and even if my page has no scroll offset or zoom, getBoundingClientRect will of course return 800x600 pixels, but I can't know what the device pixel size is that I should set to canvas to make it work. I would recommend having an api that can query for a given dom element, what its size is in device pixels when viewed unzoomed, call it domElement.devicePixelSizeWhenViewedUnzoomed() that returns an object { width: x; height: y}. I can understand the need for two different zooming: page zoom being one that affects layout and the page is aware of, and pinch zoom being one that the page doesn't know about. Under page zoom, the values returned by devicePixelSizeWhenViewedUnzoomed() would be allowed to change, and under pinch zoom, they shouldn't. Now, coming back to the specific use case where an application simply wants to have a mobile web page with a single canvas element that fills the whole screen, the following scenario seems to work at least on Firefox OS mobile devices: 1. Set CSS style of to "margin: 0px; width: 100%; height: 100%;". 2. Set as child of body, and make sure it expands to cover its parent fully by setting its style to "width: 100%; height: 100%;" as well. 3. Make sure there are no other elements whatsoever on the page that would affect the layout. 4. Then you can call document.documentElement.getBoundingClientRect(), and it will properly return fractional CSS pixel size of the device, which one can convert to device pixel sizes with the formula var devicePixelWidth = Math.round(document.documentElement.getBoundingClientRect().width * window.devicePixelRatio); var devicePixelHeight = Math.round(document.documentElement.getBoundingClientRect().height * window.devicePixelRatio); the .round() is not to round due to off-by-one-pixel issues, but to round to nearest due to imprecise floating point computation, e.g. when testing on a FFOS device with window.devicePixelRatio of 1.5, I would otherwise get a screen width of 399.99999999998, so the purpose of .round() is just to remove that. In that scheme, I am able to reconstruct back the real pixel resolution of the mobile device and size my canvas accordingly. This is enabled by the fact that document.documentElement.getBoundingClientRect().height will return a fractional value because a) I did not set any styles to body or canvas in absolute pixels and b) I made sure that there's just one DOM element that fills the whole screen. However these are pretty heavy restrictions, since some pages want to have other web content in it as well. Also I observed that the scheme is very brittle, since document.documentElement.getBoundingClientRect() stops working as soon as any other elements disrupt the layout, or if I failed to style the canvas such that it really causes the body to expand to full screen. It would be much more ideal if I could ask any arbitrarily placed dom element for domElement.devicePixelSizeWhenViewedUnzoomed() or domElement.bestMatchingDevicePixelSizeForPixelPerfectCanvasRendering(). 2014-06-12 0:09 GMT+03:00 Kenneth Russell : > This issue is a deep one which can't be solved in isolation in the > WebGL spec. Even ignoring page zoom, adding a context creation > attribute like "scaled: false" will break many invariants in the web > platform. For example, it would cause changes to the CSS width and > height properties to have the side-effect of resizing the WebGL > canvas's backing store. Resizes would start coming in asynchronously > to the WebGL app. I don't think any browser implements per-element > resize events. There would likely be other surprising and undesirable > side-effects. > > It's possible that https://www.khronos.org/webgl/wiki/HandlingHighDPI > just needs to be updated. If there are better ways to measure the > number of device pixels that a given region or canvas will cover then > let's update the page. Boris Zbarsky pointed out the > getBoundingClientRect, getClientRects, and getBoxQuads APIs. Could > someone who's been investigating this in depth please try them and see > whether they solve the problem? I suggest considering the unzoomed > case first because it seems to be the most common case. > > -Ken > > > On Wed, Jun 11, 2014 at 12:05 AM, Evan Wallace wrote: > > This is an issue I'm struggling with too. There aren't any problems with > > framebuffer size in my case though. I'm trying to cover most of the > screen > > with a WebGL canvas and that area has the same number of physical pixels > > regardless of zoom level (well, it's really a little less after you zoom > in > > because the UI around the canvas grows in size a bit). > > > > DPI handling works by setting the canvas width/height to the CSS > > width/height times the devicePixelRatio, so the canvas framebuffer is > > approximately scaled 1:1 with physical pixels. For fullscreen WebGL apps, > > zooming in makes the window size go down and the devicePixelRatio go up > to > > match. > > > > The problem is that CSS only lets you set the canvas size to integer > values, > > and most of the time it's impossible to specify an integer width/height > such > > that the zoomed canvas is exactly the size you need. Demo showing the > > problem: http://fiddle.jshell.net/V884T/show/ (zoom in and the grid > won't > > match 1:1). > > > > Strawman API proposal: add a "scaled: false" parameter to the WebGL > context > > creation attributes that would always render the framebuffer from the top > > left corner at 1:1 with physical pixels (i.e. not scaled) without > affecting > > the size of the canvas element itself. > > > > > > On Tuesday, June 10, 2014, Rik Cabanier wrote: > >> > >> > >> > >> > >> On Tue, Jun 10, 2014 at 10:41 PM, Tony Parisi > wrote: > >>> > >>> I am skeptical of that figure... Where is the data to support it? > >>> > >>> My guess is that less than 5% of users even know about the zoom > >>> features... > >> > >> > >> I was very surprised about that figure too. It's been over a year since > he > >> sent that out and I'm having trouble finding his message. > >> > >>> > >>> And yeah it's bad for WebGL graphics > >>> > >>> Tony Parisi > >>> CTO at Large > >>> 415.902.8002 > >>> > >>> > >>> On Jun 10, 2014, at 10:31 PM, Florian B?sch wrote: > >>> > >>> On Wed, Jun 11, 2014 at 7:25 AM, Rik Cabanier > wrote: > >>>> > >>>> Browser zoom (= ctrl/cmd +/-) also affects DPR. > >>>> Someone from Google maps stated that 15% of all users have some level > of > >>>> browser zoom enabled. > >>> > >>> I didn't know that. That's quite odd, and completely unusable for WebGL > >>> because there are limits to the size you can set a framebuffer to as > well as > >>> that rendering to ridiculous resolutions would become very slow, very > >>> quickly. > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed Jun 11 18:59:53 2014 From: cal...@ (Mark Callow) Date: Thu, 12 Jun 2014 10:59:53 +0900 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: <53986142.1060004@mit.edu> References: <539857C5.1020104@mit.edu> <53986142.1060004@mit.edu> Message-ID: <53990999.9010303@artspark.co.jp> On 11/06/2014 23:01, Boris Zbarsky wrote: > Browsers have two distinct zoom modes in the wild: > > 1) The mobile browser zoom-and-pan mode (called "pinch zoom" in the > cssom-view spec): zooming doesn't change layout, and simply performs a > draw-time upscale or something close to it (font rasterization here is > complicated). The size of the viewport (e.g. as measured by > window.innerWidth) does not actually change in this mode. Instead, > the page spills out of the viewport if you zoom in and you can pan > around it. > > 2) The desktop browser page zoom mode (called "page zoom" in the > spec): zooming changes the size of a CSS pixel as measured in device > pixels (and hence the size of the viewport) then redoes the page > layout using the new viewport size. Effectively, this corresponds > more or less (again, with some font rasterization complications) to > resizing the window and then doing a paint-time upscale back to the > original size. This can change where linebreaks happen and whatnot. > Typically the resulting layout will not spill out of the viewport > horizontally. > In Firefox Mobile text is usually re-flowed on pinch zoom. Sometimes the text layout does spill out of the screen but adjusting the pinch zoom a bit remedies that. This is an observation as an end-user. I have read neither the spec's around this nor source code. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 11 20:48:39 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 12 Jun 2014 05:48:39 +0200 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: On Thu, Jun 12, 2014 at 12:02 AM, Kenneth Russell wrote: > > We're simply doing due diligence. Please give the ANGLE team a couple > of days. A significant number of Chrome users are on Windows, and I am > not ready to support moving this extension to community approved until > it's known it can be supported in ANGLE's ES2 implementation. > By all means perform due diligence on it. The all due haste I suggest stems from two factors, the first one is that EXT_sRGB has been in draft for 1.5 years. The second factor is that a scenario I was not not sure would come to pass (support for EXT_sRGB natively, but no support for ES3) has now come to pass with Apples foray into WebGL. So the import of clarifying the unequivocal support for this extension (which had been cast in doubt before) is that if it isn't done, the majority of iOS devices in use today, will never get to enjoy the improved graphics/performance this extension offers for high quality rendering. In a cruel twist of fate, it could turn out that the tardiness to ensure support on desktop, dooms mobiles yet again to second-class WebGL citizens. And that's what I'd like to avoid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Thu Jun 12 09:03:43 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Thu, 12 Jun 2014 19:03:43 +0300 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: <53990999.9010303@artspark.co.jp> References: <539857C5.1020104@mit.edu> <53986142.1060004@mit.edu> <53990999.9010303@artspark.co.jp> Message-ID: Playing around with this more, I realize that in the "single fullscreen canvas" use case both limitations a) and b) can be overcome if the existing browser APIs changed slightly. I raised this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1024493 to discuss about that. 2014-06-12 4:59 GMT+03:00 Mark Callow : > On 11/06/2014 23:01, Boris Zbarsky wrote: > > Browsers have two distinct zoom modes in the wild: > > 1) The mobile browser zoom-and-pan mode (called "pinch zoom" in the > cssom-view spec): zooming doesn't change layout, and simply performs a > draw-time upscale or something close to it (font rasterization here is > complicated). The size of the viewport (e.g. as measured by > window.innerWidth) does not actually change in this mode. Instead, the > page spills out of the viewport if you zoom in and you can pan around it. > > 2) The desktop browser page zoom mode (called "page zoom" in the spec): > zooming changes the size of a CSS pixel as measured in device pixels (and > hence the size of the viewport) then redoes the page layout using the new > viewport size. Effectively, this corresponds more or less (again, with > some font rasterization complications) to resizing the window and then > doing a paint-time upscale back to the original size. This can change where > linebreaks happen and whatnot. Typically the resulting layout will not > spill out of the viewport horizontally. > > In Firefox Mobile text is usually re-flowed on pinch zoom. Sometimes the > text layout does spill out of the screen but adjusting the pinch zoom a bit > remedies that. This is an observation as an end-user. I have read neither > the spec's around this nor source code. > > Regards > > -Mark > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??. > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Thu Jun 12 10:31:48 2014 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Thu, 12 Jun 2014 20:31:48 +0300 Subject: [Public WebGL] How to unambiguously set canvas pixel size to be pixel-perfect? In-Reply-To: References: Message-ID: I think .getBoundingClientRect(), .getClientRects() and .getBoxQuads() all share the same problem: I must first build the geometry to the correct size before I can measure it. But that requires me to mutate the DOM, so it's not so easy to use those apis to query the different sizes of the screen/viewport. 2014-06-12 20:26 GMT+03:00 Nat Duca : > Does this help? > https://hacks.mozilla.org/2014/03/introducing-the-getboxquads-api/ > > > > > On Thu, Jun 12, 2014 at 9:03 AM, Jukka Jyl?nki wrote: > >> Playing around with this more, I realize that in the "single fullscreen >> canvas" use case both limitations a) and b) can be overcome if the existing >> browser APIs changed slightly. I raised this bug >> https://bugzilla.mozilla.org/show_bug.cgi?id=1024493 to discuss about >> that. >> >> >> 2014-06-12 4:59 GMT+03:00 Mark Callow : >> >> On 11/06/2014 23:01, Boris Zbarsky wrote: >>> >>> Browsers have two distinct zoom modes in the wild: >>> >>> 1) The mobile browser zoom-and-pan mode (called "pinch zoom" in the >>> cssom-view spec): zooming doesn't change layout, and simply performs a >>> draw-time upscale or something close to it (font rasterization here is >>> complicated). The size of the viewport (e.g. as measured by >>> window.innerWidth) does not actually change in this mode. Instead, the >>> page spills out of the viewport if you zoom in and you can pan around it. >>> >>> 2) The desktop browser page zoom mode (called "page zoom" in the spec): >>> zooming changes the size of a CSS pixel as measured in device pixels (and >>> hence the size of the viewport) then redoes the page layout using the new >>> viewport size. Effectively, this corresponds more or less (again, with >>> some font rasterization complications) to resizing the window and then >>> doing a paint-time upscale back to the original size. This can change where >>> linebreaks happen and whatnot. Typically the resulting layout will not >>> spill out of the viewport horizontally. >>> >>> In Firefox Mobile text is usually re-flowed on pinch zoom. Sometimes >>> the text layout does spill out of the screen but adjusting the pinch zoom a >>> bit remedies that. This is an observation as an end-user. I have read >>> neither the spec's around this nor source code. >>> >>> Regards >>> >>> -Mark >>> -- >>> ???????????????????????????????????????????????????????????????? >>> ???????????????????????????????????????????????????????????????? ??. >>> >>> NOTE: This electronic mail message may contain confidential and >>> privileged information from HI Corporation. If you are not the intended >>> recipient, any disclosure, photocopying, distribution or use of the >>> contents of the received information is prohibited. If you have received >>> this e-mail in error, please notify the sender immediately and permanently >>> delete this message and all related copies. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 18 00:34:14 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 18 Jun 2014 09:34:14 +0200 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: On Thu, Jun 12, 2014 at 12:02 AM, Kenneth Russell wrote: > > We're simply doing due diligence. Please give the ANGLE team a couple > of days. A significant number of Chrome users are on Windows, and I am > not ready to support moving this extension to community approved until > it's known it can be supported in ANGLE's ES2 implementation. > Any progress on the Angle due diligence? - Direct3D 9 sRGB documentation (separate sampler state): http://msdn.microsoft.com/en-us/library/windows/desktop/bb173460(v=vs.85).aspx - Direct3D 11 sRGB documentation (just a texture format): http://msdn.microsoft.com/en-us/library/windows/desktop/bb173059(v=vs.85).aspx - Capability query in Direct3D: http://msdn.microsoft.com/en-us/library/bb172583%28v=vs.85%29.aspx - Direct3D variable controlling post blending conversion: POSTBLENDSRGBCONVERT -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Jun 18 10:48:06 2014 From: kbr...@ (Kenneth Russell) Date: Wed, 18 Jun 2014 10:48:06 -0700 Subject: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved In-Reply-To: References: <5389792A.50607@gmx.at> <739040100.8736857.1402437106692.JavaMail.zimbra@mozilla.com> <672901867.8757633.1402442378131.JavaMail.zimbra@mozilla.com> Message-ID: On Wed, Jun 18, 2014 at 12:34 AM, Florian B?sch wrote: > On Thu, Jun 12, 2014 at 12:02 AM, Kenneth Russell wrote: >> >> We're simply doing due diligence. Please give the ANGLE team a couple >> of days. A significant number of Chrome users are on Windows, and I am >> not ready to support moving this extension to community approved until >> it's known it can be supported in ANGLE's ES2 implementation. > > > Any progress on the Angle due diligence? > > - Direct3D 9 sRGB documentation (separate sampler state): > http://msdn.microsoft.com/en-us/library/windows/desktop/bb173460(v=vs.85).aspx > - Direct3D 11 sRGB documentation (just a texture format): > http://msdn.microsoft.com/en-us/library/windows/desktop/bb173059(v=vs.85).aspx > - Capability query in Direct3D: > http://msdn.microsoft.com/en-us/library/bb172583%28v=vs.85%29.aspx > - Direct3D variable controlling post blending conversion: > POSTBLENDSRGBCONVERT Yes. The ANGLE team's confirmed they are both able to implement, and are currently implementing, EXT_sRGB for their ES 2.0 backend. I withdraw my objections to moving this extension to community approved, and since there weren't any other objections, will merge your pull request now. Thanks for pushing on this. Note that they discovered some differences between EXT_sRGB's and ES 3.0's requirements around mipmapping support for sRGB texture formats (and internal formats). For this reason it is likely that EXT_sRGB will be exposed as an extension in WebGL 1.0 in Chrome, but not in WebGL 2.0, where sRGB support is built in to the core spec. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Jun 23 02:40:11 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 23 Jun 2014 11:40:11 +0200 Subject: [Public WebGL] color buffer (half) float Message-ID: Firefox has started to roll out WEBGL_color_buffer_float and OES_color_buffer_half_float unprefixed/on by default. 1) Given that Mozilla doesn't ship fetaures that have no tests, I suspect there's a conformance test present for these extensions in Mozillas repositories. However, the conformance test is not present in the canonical conformance test suite of Khronos on Github. Could Mozilla please contribute those tests to the canonical conformance suite? 2) Are there any principal objections to start moving WEBGL_color_buffer_float and OES_color_buffer_float to community approved once test suites have been provided? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 23 10:51:36 2014 From: kbr...@ (Kenneth Russell) Date: Mon, 23 Jun 2014 10:51:36 -0700 Subject: [Public WebGL] color buffer (half) float In-Reply-To: References: Message-ID: On Mon, Jun 23, 2014 at 2:40 AM, Florian B?sch wrote: > Firefox has started to roll out WEBGL_color_buffer_float and > OES_color_buffer_half_float unprefixed/on by default. That's surprising. Thanks for pointing this out. I've emailed Mozilla about this. The WebGL ecosystem has been successful to this point because of rigorous testing of new features, and shipping these extensions without tests -- and against the WebGL extension development process -- breaks this track record. > 1) Given that Mozilla doesn't ship fetaures that have no tests, I suspect > there's a conformance test present for these extensions in Mozillas > repositories. However, the conformance test is not present in the canonical > conformance test suite of Khronos on Github. Could Mozilla please contribute > those tests to the canonical conformance suite? > > 2) Are there any principal objections to start moving > WEBGL_color_buffer_float and OES_color_buffer_float to community approved > once test suites have been provided? Yes. There is a significant technical issue with implementing WEBGL_color_buffer_float on top of OpenGL ES 2.0, which is that there is no ES 2.0 extension defining the behavior of color_buffer_float. There was an attempt to implement EXT_color_buffer_half_float and WEBGL_color_buffer_float both in ANGLE and Chrome a few months ago and the code was simply incorrect. Adding these extensions to WebGL 2.0 will be trivial because it's based on OpenGL ES 3.0, on top of which the underlying extensions are defined. I think that all WebGL implementers' time should be invested in WebGL 2.0 specification, conformance suite, and implementation work at this point, not adding more extensions to WebGL 1.0 implementations. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Jun 23 11:03:30 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 23 Jun 2014 20:03:30 +0200 Subject: [Public WebGL] color buffer (half) float In-Reply-To: References: Message-ID: On Mon, Jun 23, 2014 at 7:51 PM, Kenneth Russell wrote: > Yes. There is a significant technical issue with implementing > WEBGL_color_buffer_float on top of OpenGL ES 2.0, which is that there > is no ES 2.0 extension defining the behavior of color_buffer_float. > That shouldn't matter really. On platforms that define no queryable extension/capability for the permissability to attach a floating point texture to a framebuffer, a straightforward test by the browser can be performed by simply checking if it works: 1) Create a floating point texture (if there isn't one, it can't work anyway) 2) Create a byte texture 3) Create a framebuffer and attach the floating point texture 4) check for errors and framebuffer completeness, if error or incomplete, it can't work. 5) fill the floating point texture with a simple shader 6) bind the floating point texture as a sampler 7) attach the byte texture to another framebuffer 8) render the contents of the floating point texture to the byte texture 9) readPixels on the byte texture 10) if the values are as expected, floating point texture framebuffers work -> enable the extension, if not, don't enable it. I implement that in JS to emulate that extension. Helps a great deal in picking renderingpaths and prevent undue "black screens". Would be nice if that snippet wasn't required to be included by everybody, but I ain't crying if browsers can't agree on how to provide 20 lines of utility code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jun 23 12:54:16 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 23 Jun 2014 21:54:16 +0200 Subject: [Public WebGL] color buffer (half) float In-Reply-To: References: Message-ID: But on thinking about this, what you're actually saying is, these extensions shouldn't be implemented. At all. So how about we drop em instead? Any objections to that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Jun 23 14:09:41 2014 From: jgi...@ (Jeff Gilbert) Date: Mon, 23 Jun 2014 14:09:41 -0700 (PDT) Subject: [Public WebGL] color buffer (half) float In-Reply-To: References: Message-ID: <1172211680.2427839.1403557781253.JavaMail.zimbra@mozilla.com> No objection here. If we decide that we won't ever move an extension forward, we should remove it from the 'approval track'. We should either just delete the extensions, or put them in an 'Abandoned Extensions' category, with a note about why we decided not to move them forward. As always, fixing the extensions to be implementable should be on the table as well, particularly for WEBGL_ extensions. -Jeff ----- Original Message ----- From: "Florian B?sch" To: "Kenneth Russell" Cc: "public webgl" Sent: Monday, June 23, 2014 12:54:16 PM Subject: Re: [Public WebGL] color buffer (half) float But on thinking about this, what you're actually saying is, these extensions shouldn't be implemented. At all. So how about we drop em instead? Any objections to that? ----------------------------------------------------------- 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 Jun 23 14:19:09 2014 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 23 Jun 2014 23:19:09 +0200 Subject: [Public WebGL] color buffer (half) float In-Reply-To: <1172211680.2427839.1403557781253.JavaMail.zimbra@mozilla.com> References: <1172211680.2427839.1403557781253.JavaMail.zimbra@mozilla.com> Message-ID: On Mon, Jun 23, 2014 at 11:09 PM, Jeff Gilbert wrote: > As always, fixing the extensions to be implementable should be on the > table as well, particularly for WEBGL_ extensions. > What's the issue with implementing these extensions? I mean other than that WEBGL_color_buffer_float doesn't work on any ES 2.0 mobile device (which is fine, because there's also EXT_color_buffer_half_float which can stand in for it sometimes). -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 23 14:54:07 2014 From: kbr...@ (Kenneth Russell) Date: Mon, 23 Jun 2014 14:54:07 -0700 Subject: [Public WebGL] color buffer (half) float In-Reply-To: References: <1172211680.2427839.1403557781253.JavaMail.zimbra@mozilla.com> Message-ID: On Mon, Jun 23, 2014 at 2:19 PM, Florian B?sch wrote: > On Mon, Jun 23, 2014 at 11:09 PM, Jeff Gilbert wrote: >> >> As always, fixing the extensions to be implementable should be on the >> table as well, particularly for WEBGL_ extensions. > > What's the issue with implementing these extensions? I mean other than that > WEBGL_color_buffer_float doesn't work on any ES 2.0 mobile device (which is > fine, because there's also EXT_color_buffer_half_float which can stand in > for it sometimes). https://codereview.appspot.com/11238044/ and https://codereview.chromium.org/18246005/ show the background of implementation in ANGLE and Chrome. It's simply a matter of priorities. It's going to take a nonzero amount of time to get these extensions working against WebGL 1.0 and I think that effort would be better spent on WebGL 2.0 specification and implementation. ----------------------------------------------------------- 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...@ Mon Jun 23 19:35:48 2014 From: cal...@ (Mark Callow) Date: Tue, 24 Jun 2014 11:35:48 +0900 Subject: [Public WebGL] color buffer (half) float In-Reply-To: References: Message-ID: <53A8E404.1010102@artspark.co.jp> On 24/06/2014 02:51, Kenneth Russell wrote: > > Yes. There is a significant technical issue with implementing > WEBGL_color_buffer_float on top of OpenGL ES 2.0, which is that there > is no ES 2.0 extension defining the behavior of color_buffer_float. > There was an attempt to implement EXT_color_buffer_half_float and > WEBGL_color_buffer_float both in ANGLE and Chrome a few months ago and > the code was simply incorrect. Adding these extensions to WebGL 2.0 > will be trivial because it's based on OpenGL ES 3.0, on top of which > the underlying extensions are defined. I think that all WebGL > implementers' time should be invested in WebGL 2.0 specification, > conformance suite, and implementation work at this point, not adding > more extensions to WebGL 1.0 implementations. While I do not object to Florian's proposal to move these extension specs to abandoned and to concentrate on WebGL 2.0, I feel a need to point out a few issues in the above statements. While there is no ES 2.0 extension, WEBGL_color_buffer_float defines the required behavior for float32 as precisely as OES_color_buffer_half_float does for float16. I see no technical issue. The lack of an ES extension merely means that you would never advertise WEBGL_color_buffer_float when running atop ES 2.0. You would only advertise it when running atop desktop. One of the failed/abandoned patches Ken pointed at in his later mail refers to issues with ANGLE and DX11 supporting only R32F and RG32F. That issue is going to have to be dealt with for WebGL 2.0 implementations on ANGLE. It is not cured because OES_color_buffer_float exists for ES 3.x. In fact it might be worse because the OES extension requires a bunch of sized internal formats to be color-renderable not just an unsized format. BTW, when you all implement WebGL 2.0 please ensure that linear filtering of float32 textures is NOT accidentally enabled when running atop desktop. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Jun 25 12:32:12 2014 From: kbr...@ (Kenneth Russell) Date: Wed, 25 Jun 2014 12:32:12 -0700 Subject: [Public WebGL] Proposal to ratify currently community approved extensions In-Reply-To: References: <706481114.7873085.1392239781229.JavaMail.zimbra@mozilla.com> <1896479227.15010719.1395787890689.JavaMail.zimbra@mozilla.com> Message-ID: Sorry for the delay. These extensions have just been submitted to Khronos for ratification. Will update the mailing list when this process is completed. -Ken On Mon, Jun 9, 2014 at 3:32 AM, Florian B?sch wrote: > On Tue, Mar 25, 2014 at 11:51 PM, Jeff Gilbert wrote: >> >> Alright, our issue was a bad ANGLE pull. It's been fixed in newer >> versions, so we should be fine moving these forward. > > Any progress on the ratification of WEBGL_draw_buffers, > ANGLE_instanced_arrays, OES_texture_float_linear and > OES_texture_half_float_linear? > ----------------------------------------------------------- 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 Jun 26 15:04:09 2014 From: kbr...@ (Kenneth Russell) Date: Thu, 26 Jun 2014 15:04:09 -0700 Subject: [Public WebGL] Proposal to move more draft extensions to community approved Message-ID: With the recent announcement of WebGL support coming in iOS 8, it would be advantageous to promote draft extensions that might be able to be supported in this OS release. I'd like to propose that the following extensions be promoted to community approved: WEBGL_compressed_texture_atc WEBGL_compressed_texture_pvrtc WEBGL_compressed_texture_etc1 EXT_blend_minmax EXT_shader_texture_lod The EXT_ extensions are widely supported. iOS hardware supports PVRTC texture compression. The WebGL conformance suite contains tests for all of these extensions. Any bugs in these tests (in particular, there's one known issue in the pvrtc tests) can be fixed after the fact. Any comments in favor or against? 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 jgi...@ Fri Jun 27 14:48:38 2014 From: jgi...@ (Jeff Gilbert) Date: Fri, 27 Jun 2014 14:48:38 -0700 (PDT) Subject: [Public WebGL] Proposal to move more draft extensions to community approved In-Reply-To: References: Message-ID: <1110732404.3396609.1403905718672.JavaMail.zimbra@mozilla.com> We're in favor. -Jeff ----- Original Message ----- From: "Kenneth Russell" To: "public webgl" Sent: Thursday, June 26, 2014 3:04:09 PM Subject: [Public WebGL] Proposal to move more draft extensions to community approved With the recent announcement of WebGL support coming in iOS 8, it would be advantageous to promote draft extensions that might be able to be supported in this OS release. I'd like to propose that the following extensions be promoted to community approved: WEBGL_compressed_texture_atc WEBGL_compressed_texture_pvrtc WEBGL_compressed_texture_etc1 EXT_blend_minmax EXT_shader_texture_lod The EXT_ extensions are widely supported. iOS hardware supports PVRTC texture compression. The WebGL conformance suite contains tests for all of these extensions. Any bugs in these tests (in particular, there's one known issue in the pvrtc tests) can be fixed after the fact. Any comments in favor or against? Thanks, -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Fri Jun 27 15:18:57 2014 From: baj...@ (Brandon Jones) Date: Fri, 27 Jun 2014 22:18:57 +0000 Subject: [Public WebGL] Proposal to move more draft extensions to community approved References: <1110732404.3396609.1403905718672.JavaMail.zimbra@mozilla.com> Message-ID: I'm in favor. On 1403905756417, Jeff Gilbert wrote: > > We're in favor. > > -Jeff > > ----- Original Message ----- > From: "Kenneth Russell" > To: "public webgl" > Sent: Thursday, June 26, 2014 3:04:09 PM > Subject: [Public WebGL] Proposal to move more draft extensions to > community approved > > > With the recent announcement of WebGL support coming in iOS 8, it > would be advantageous to promote draft extensions that might be able > to be supported in this OS release. I'd like to propose that the > following extensions be promoted to community approved: > > WEBGL_compressed_texture_atc > WEBGL_compressed_texture_pvrtc > WEBGL_compressed_texture_etc1 > EXT_blend_minmax > EXT_shader_texture_lod > > The EXT_ extensions are widely supported. iOS hardware supports PVRTC > texture compression. The WebGL conformance suite contains tests for > all of these extensions. Any bugs in these tests (in particular, > there's one known issue in the pvrtc tests) can be fixed after the > fact. > > Any comments in favor or against? > > Thanks, > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Jun 27 15:55:21 2014 From: din...@ (Dean Jackson) Date: Sat, 28 Jun 2014 08:55:21 +1000 Subject: [Public WebGL] Proposal to move more draft extensions to community approved In-Reply-To: References: Message-ID: <723C1035-1378-475F-B0FD-AB7C79E9C0AC@apple.com> +1 from me. Dean > On 27 Jun 2014, at 8:04 am, Kenneth Russell wrote: > > > With the recent announcement of WebGL support coming in iOS 8, it > would be advantageous to promote draft extensions that might be able > to be supported in this OS release. I'd like to propose that the > following extensions be promoted to community approved: > > WEBGL_compressed_texture_atc > WEBGL_compressed_texture_pvrtc > WEBGL_compressed_texture_etc1 > EXT_blend_minmax > EXT_shader_texture_lod > > The EXT_ extensions are widely supported. iOS hardware supports PVRTC > texture compression. The WebGL conformance suite contains tests for > all of these extensions. Any bugs in these tests (in particular, > there's one known issue in the pvrtc tests) can be fixed after the > fact. > > Any comments in favor or against? > > Thanks, > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Jun 27 16:05:11 2014 From: kbr...@ (Kenneth Russell) Date: Fri, 27 Jun 2014 16:05:11 -0700 Subject: [Public WebGL] Proposal to move more draft extensions to community approved In-Reply-To: <723C1035-1378-475F-B0FD-AB7C79E9C0AC@apple.com> References: <723C1035-1378-475F-B0FD-AB7C79E9C0AC@apple.com> Message-ID: Fantastic. Given consensus among the implementers, have moved these to community approved. -Ken On Fri, Jun 27, 2014 at 3:55 PM, Dean Jackson wrote: > +1 from me. > > Dean > >> On 27 Jun 2014, at 8:04 am, Kenneth Russell wrote: >> >> >> With the recent announcement of WebGL support coming in iOS 8, it >> would be advantageous to promote draft extensions that might be able >> to be supported in this OS release. I'd like to propose that the >> following extensions be promoted to community approved: >> >> WEBGL_compressed_texture_atc >> WEBGL_compressed_texture_pvrtc >> WEBGL_compressed_texture_etc1 >> EXT_blend_minmax >> EXT_shader_texture_lod >> >> The EXT_ extensions are widely supported. iOS hardware supports PVRTC >> texture compression. The WebGL conformance suite contains tests for >> all of these extensions. Any bugs in these tests (in particular, >> there's one known issue in the pvrtc tests) can be fixed after the >> fact. >> >> Any comments in favor or against? >> >> Thanks, >> >> -Ken >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From che...@ Mon Jun 30 07:40:32 2014 From: che...@ (Amit Kumar) Date: Mon, 30 Jun 2014 20:10:32 +0530 Subject: [Public WebGL] WebGL conformance test Message-ID: Hi, I am new to webgl and this mailing list. I have a query. Can someone explain me what conformance/rendering/multisample-corruption.html test is doing, I couldn't find 'what does multisample-corruption means? -- Regards, Amit Kumar Noida 91 9971115174 -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Mon Jun 30 10:04:54 2014 From: baj...@ (Brandon Jones) Date: Mon, 30 Jun 2014 17:04:54 +0000 Subject: [Public WebGL] WebGL conformance test References: Message-ID: The conformance tests check to ensure that the browser is conforming to the WebGL specs by running a bunch of WEbGL commands and checking the results. A lot of times the basic pattern is: DoSomethingWrong(); CheckToMakeSureTheRightErrorWasGenerated(); DoSomethingWrite(); CheckToMakeSureThereWasNoError(); CheckToMakeSureTheOutputWasRight(); The conformance tests also check known issues in various drivers to make sure they don't affect the output of WebGL content. The MultisampleCorruption test, for example, creates many large multisampled surfaces and ensures you can render to them correctly because we've observed problems on some GPUs where doing that resulted in garbage rendering. The WebGL implementation needs to be aware of that issue and work around it. On 1404139280393, Amit Kumar wrote: > Hi, > I am new to webgl and this mailing list. I have a query. Can someone > explain me what conformance/rendering/multisample-corruption.html > test > is doing, I couldn't find 'what does multisample-corruption means? > > > -- > Regards, > Amit Kumar > Noida > 91 9971115174 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 30 10:18:36 2014 From: kbr...@ (Kenneth Russell) Date: Mon, 30 Jun 2014 10:18:36 -0700 Subject: [Public WebGL] WebGL conformance test In-Reply-To: References: Message-ID: The original bug for which the multisample-corruption.html test was written was considered a security bug at the time because it allowed uninitialized video memory to be read back by WebGL applications. At this point the bug has been worked around and is publicly visible, so a link to the original bug report has been added to the test. Thanks for the feedback. -Ken On Mon, Jun 30, 2014 at 10:04 AM, Brandon Jones wrote: > The conformance tests check to ensure that the browser is conforming to the > WebGL specs by running a bunch of WEbGL commands and checking the results. A > lot of times the basic pattern is: > > DoSomethingWrong(); > CheckToMakeSureTheRightErrorWasGenerated(); > > DoSomethingWrite(); > CheckToMakeSureThereWasNoError(); > CheckToMakeSureTheOutputWasRight(); > > The conformance tests also check known issues in various drivers to make > sure they don't affect the output of WebGL content. The > MultisampleCorruption test, for example, creates many large multisampled > surfaces and ensures you can render to them correctly because we've observed > problems on some GPUs where doing that resulted in garbage rendering. The > WebGL implementation needs to be aware of that issue and work around it. > > On 1404139280393, Amit Kumar wrote: >> >> Hi, >> I am new to webgl and this mailing list. I have a query. Can someone >> explain me what conformance/rendering/multisample-corruption.html test is >> doing, I couldn't find 'what does multisample-corruption means? >> >> >> -- >> Regards, >> Amit Kumar >> Noida >> 91 9971115174 ----------------------------------------------------------- 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 -----------------------------------------------------------