From jco...@ Fri Apr 1 03:23:51 2011 From: jco...@ (John Congote) Date: Fri, 1 Apr 2011 12:23:51 +0200 Subject: [Public WebGL] Volume Textures In-Reply-To: <0F56B94025EFF74B94BF26E1E6DA46676DB41C0DF9@NALASEXMB13.na.qualcomm.com> References: <0F56B94025EFF74B94BF26E1E6DA46676DB41C0DF9@NALASEXMB13.na.qualcomm.com> Message-ID: Hello We have published a demo of out Volume Rendering implementation, you can find it here: http://demos.vicomtech.org/volren/ Feel free to give us any comments, they will be very appreciated. John 2011/3/29 Ribble, Maurice : > John, that sounds interesting. ?I did some volume rendering many years ago and I always find alternate techniques interesting. ?I'm going to keep an eye out for that. ?Thanks for sharing! > > I wanted to clarify that all Adreno 200, 205, and 220 GPUs support the OES_texture_3D extension. ?There is very wide spread market adoption of the Adreno 200 family of GPUs. ?Qualcomm will continue supporting 3D textures with future versions of our Adreno GPUs in OpenGL ES. > > While I can't speak for WebGL I can say that with OpenGL ES it is common for application developers to detect extension strings and have various paths depending on what extensions are supported. ?This gives developers the choice with a little extra work to optimize their apps for different hardware. ?To me it doesn't seem that different from a web app supporting different browsers. ?That said, I do realize that extensions adds complexity and I'm very happy to see that the first version of WebGL has been finished. ?I hope various extensions, including 3D textures, are something that can be added as extensions to future WebGL implementations. > > -Maurice > > -----Original Message----- > From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of John Congote > Sent: Tuesday, March 29, 2011 6:58 AM > To: Ginsburg, Daniel > Cc: jdavis...@; Kenneth Russell; Thatcher Ulrich; public webgl; Gregg Tavares (wrk); Gavriel State; Daniel Koch > Subject: Re: [Public WebGL] Volume Textures > > > Hello, > > As you mentioned, 3D texture support would be very useful for medical > imaging. Although, some workarounds exist in order to obtain the same > graphical results with some penalization on dedicated platforms > (Desktop-Workstation), but also gives the possibility to get the > results in other devices like tablet pcs and mobile phones. > > We are presenting our approach for volume rendering in webgl in a > publication. We had been working on it for about 1 year, the reason > why we publish it now is because the WebGL specification has just been > released. Our work is a volume rendering implementation using Ray > Casting in a volume dataset stored as a 2D texture. > > We have intention to show a public demo at the end of the week. > > Thanks. > > > 2011/3/24 Ginsburg, Daniel : >> >> I agree. ?Having 3D texture support would be especially useful in the medical imaging domain. ?Since 3D textures have been supported on desktop GPUs since 2000-ish, it would be great to see this available as an extension for desktop WebGL implementations. >> >> Thanks. >> >> -- Dan >> >> >> On 3/24/11 7:18 AM, "John Davis" wrote: >> >> In the meantime, is there any chance we could add an extension to WebGL and Angle to support volume textures for the rather large use case of Chrome and FireFox? ?This is very low hanging fruit that will add considerable bang on the fragment shader side. >> >> On Mon, Mar 7, 2011 at 3:57 PM, Kenneth Russell wrote: >> GL_OES_texture_3D seems to be unsupported on current iOS hardware, >> which means that content using that extension wouldn't be portable to >> a significant percentage of mobile devices. For this reason there >> currently is no plan to incorporate that extension into the WebGL >> registry as a "core" extension. A browser vendor would be welcome to >> add it as a vendor-specific extension. >> >> That having been said, the WebGL spec aims to track the OpenGL ES >> spec, and we anticipate a revision of the WebGL spec later this year >> which is likely to add this functionality. >> >> -Ken >> >> On Sun, Mar 6, 2011 at 2:44 PM, John Davis wrote: >>> Correct, but trilinear filtering in hardware is typically faster, and >>> doesn't increase the instruction count. ?Not to mention, it's also much >>> easier to have trilinear filtering that just works rather than implementing >>> it with 2D. >>> >>> On Sun, Mar 6, 2011 at 3:16 PM, Thatcher Ulrich wrote: >>>> >>>> It doesn't seem that hard to simulate a volume texture using a large >>>> 2D texture. ?Am I wrong? >>>> >>>> -T >>>> >>>> On Sun, Mar 6, 2011 at 4:57 PM, John Davis >>>> wrote: >>>> > Are any webgl implementations adding volume textures as an extension? >>>> > ?This >>>> > is pretty key for those of us needing fast 3D noise. >>>> > Any updates on VTL in Angle? >>>> > JD >>>> > >>>> >>> >>> >> >> >> >> >> -- >> Dan Ginsburg / email: daniel.ginsburg...@ >> Principal Software Architect >> Fetal-Neonatal Neuroimaging and Development Science Center >> Children's Hospital Boston >> 300 Longwood Avenue >> Boston, MA 02115 >> Phone: 857-218-5140 >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> >> > > > > -- > M.Sc. John Edgar Congote Calle > Sistemas de transporte inteligentes e Ingenier?a / Intelligent > Transport Systems and Engineering > Vicomtech-IK4 - Visual Interaction Communication Technologies > Mikeletegi Pasealekua, 57 - Parque Tecnol?gico > 20009 Donostia - San Sebasti?n - Spain > Tel: +[34] 943 30 92 30 > Fax: +[34] 943 30 93 93 > e-mail: jcongote...@ > www.vicomtech.org > > *** member of IK4 Research Alliance **** > www.ik4.es > *** member of GraphicsMedia.net **** > www.graphicsmedia.net > > ----------------------------------------------------- > Vicomtech-IK4 is an ISO 9001:2000 certified institute > ----------------------------------------------------- > > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > > -- M.Sc. John Edgar Congote Calle Sistemas de transporte inteligentes e Ingenier?a / Intelligent Transport Systems and Engineering Vicomtech-IK4 - Visual Interaction Communication Technologies Mikeletegi Pasealekua, 57 - Parque Tecnol?gico 20009 Donostia - San Sebasti?n - Spain Tel: +[34] 943 30 92 30 Fax: +[34] 943 30 93 93 e-mail: jcongote...@ www.vicomtech.org *** member of IK4 Research Alliance **** www.ik4.es *** member of GraphicsMedia.net **** www.graphicsmedia.net ----------------------------------------------------- Vicomtech-IK4 is an ISO 9001:2000 certified institute ----------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tu...@ Fri Apr 1 09:45:02 2011 From: tu...@ (Thatcher Ulrich) Date: Fri, 1 Apr 2011 09:45:02 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <0F56B94025EFF74B94BF26E1E6DA46676DB41C0DF9@NALASEXMB13.na.qualcomm.com> Message-ID: Nice! Abstract says "The new WebGL standard may enable volume visualization on the Web." I think you can delete the "may"! -T On Fri, Apr 1, 2011 at 3:23 AM, John Congote wrote: > Hello > > We have published a demo of out Volume Rendering implementation, you > can find it here: > http://demos.vicomtech.org/volren/ > > Feel free to give us any comments, they will be very appreciated. > > John > > 2011/3/29 Ribble, Maurice : >> John, that sounds interesting. ?I did some volume rendering many years ago and I always find alternate techniques interesting. ?I'm going to keep an eye out for that. ?Thanks for sharing! >> >> I wanted to clarify that all Adreno 200, 205, and 220 GPUs support the OES_texture_3D extension. ?There is very wide spread market adoption of the Adreno 200 family of GPUs. ?Qualcomm will continue supporting 3D textures with future versions of our Adreno GPUs in OpenGL ES. >> >> While I can't speak for WebGL I can say that with OpenGL ES it is common for application developers to detect extension strings and have various paths depending on what extensions are supported. ?This gives developers the choice with a little extra work to optimize their apps for different hardware. ?To me it doesn't seem that different from a web app supporting different browsers. ?That said, I do realize that extensions adds complexity and I'm very happy to see that the first version of WebGL has been finished. ?I hope various extensions, including 3D textures, are something that can be added as extensions to future WebGL implementations. >> >> -Maurice >> >> -----Original Message----- >> From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of John Congote >> Sent: Tuesday, March 29, 2011 6:58 AM >> To: Ginsburg, Daniel >> Cc: jdavis...@; Kenneth Russell; Thatcher Ulrich; public webgl; Gregg Tavares (wrk); Gavriel State; Daniel Koch >> Subject: Re: [Public WebGL] Volume Textures >> >> >> Hello, >> >> As you mentioned, 3D texture support would be very useful for medical >> imaging. Although, some workarounds exist in order to obtain the same >> graphical results with some penalization on dedicated platforms >> (Desktop-Workstation), but also gives the possibility to get the >> results in other devices like tablet pcs and mobile phones. >> >> We are presenting our approach for volume rendering in webgl in a >> publication. We had been working on it for about 1 year, the reason >> why we publish it now is because the WebGL specification has just been >> released. Our work is a volume rendering implementation using Ray >> Casting in a volume dataset stored as a 2D texture. >> >> We have intention to show a public demo at the end of the week. >> >> Thanks. >> >> >> 2011/3/24 Ginsburg, Daniel : >>> >>> I agree. ?Having 3D texture support would be especially useful in the medical imaging domain. ?Since 3D textures have been supported on desktop GPUs since 2000-ish, it would be great to see this available as an extension for desktop WebGL implementations. >>> >>> Thanks. >>> >>> -- Dan >>> >>> >>> On 3/24/11 7:18 AM, "John Davis" wrote: >>> >>> In the meantime, is there any chance we could add an extension to WebGL and Angle to support volume textures for the rather large use case of Chrome and FireFox? ?This is very low hanging fruit that will add considerable bang on the fragment shader side. >>> >>> On Mon, Mar 7, 2011 at 3:57 PM, Kenneth Russell wrote: >>> GL_OES_texture_3D seems to be unsupported on current iOS hardware, >>> which means that content using that extension wouldn't be portable to >>> a significant percentage of mobile devices. For this reason there >>> currently is no plan to incorporate that extension into the WebGL >>> registry as a "core" extension. A browser vendor would be welcome to >>> add it as a vendor-specific extension. >>> >>> That having been said, the WebGL spec aims to track the OpenGL ES >>> spec, and we anticipate a revision of the WebGL spec later this year >>> which is likely to add this functionality. >>> >>> -Ken >>> >>> On Sun, Mar 6, 2011 at 2:44 PM, John Davis wrote: >>>> Correct, but trilinear filtering in hardware is typically faster, and >>>> doesn't increase the instruction count. ?Not to mention, it's also much >>>> easier to have trilinear filtering that just works rather than implementing >>>> it with 2D. >>>> >>>> On Sun, Mar 6, 2011 at 3:16 PM, Thatcher Ulrich wrote: >>>>> >>>>> It doesn't seem that hard to simulate a volume texture using a large >>>>> 2D texture. ?Am I wrong? >>>>> >>>>> -T >>>>> >>>>> On Sun, Mar 6, 2011 at 4:57 PM, John Davis >>>>> wrote: >>>>> > Are any webgl implementations adding volume textures as an extension? >>>>> > ?This >>>>> > is pretty key for those of us needing fast 3D noise. >>>>> > Any updates on VTL in Angle? >>>>> > JD >>>>> > >>>>> >>>> >>>> >>> >>> >>> >>> >>> -- >>> Dan Ginsburg / email: daniel.ginsburg...@ >>> Principal Software Architect >>> Fetal-Neonatal Neuroimaging and Development Science Center >>> Children's Hospital Boston >>> 300 Longwood Avenue >>> Boston, MA 02115 >>> Phone: 857-218-5140 >>> >>> ----------------------------------------------------------- >>> 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 >>> ----------------------------------------------------------- >>> >>> >> >> >> >> -- >> M.Sc. John Edgar Congote Calle >> Sistemas de transporte inteligentes e Ingenier?a / Intelligent >> Transport Systems and Engineering >> Vicomtech-IK4 - Visual Interaction Communication Technologies >> Mikeletegi Pasealekua, 57 - Parque Tecnol?gico >> 20009 Donostia - San Sebasti?n - Spain >> Tel: +[34] 943 30 92 30 >> Fax: +[34] 943 30 93 93 >> e-mail: jcongote...@ >> www.vicomtech.org >> >> *** member of IK4 Research Alliance **** >> www.ik4.es >> *** member of GraphicsMedia.net **** >> www.graphicsmedia.net >> >> ----------------------------------------------------- >> Vicomtech-IK4 is an ISO 9001:2000 certified institute >> ----------------------------------------------------- >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> >> > > > > -- > M.Sc. John Edgar Congote Calle > Sistemas de transporte inteligentes e Ingenier?a / Intelligent > Transport Systems and Engineering > > Vicomtech-IK4 - Visual Interaction Communication Technologies > Mikeletegi Pasealekua, 57 - Parque Tecnol?gico > 20009 Donostia - San Sebasti?n - Spain > Tel: +[34] 943 30 92 30 > Fax: +[34] 943 30 93 93 > e-mail: jcongote...@ > www.vicomtech.org > > *** member of IK4 Research Alliance **** > www.ik4.es > *** member of GraphicsMedia.net **** > www.graphicsmedia.net > > ----------------------------------------------------- > Vicomtech-IK4 is an ISO 9001:2000 certified institute > ----------------------------------------------------- > ----------------------------------------------------------- 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 Apr 1 09:50:40 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 1 Apr 2011 09:50:40 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <0F56B94025EFF74B94BF26E1E6DA46676DB41C0DF9@NALASEXMB13.na.qualcomm.com> Message-ID: Wow, that's really cool! Do any of the other buttons aside from Aorta LowRes Color work at the moment? It could use a loading progress indicator. -Ken P.S. Please post to https://groups.google.com/group/webgl-dev-list , although your post is certainly relevant to this preexisting thread and a good existence proof that the techniques are currently possible. :) On Fri, Apr 1, 2011 at 3:23 AM, John Congote wrote: > Hello > > We have published a demo of out Volume Rendering implementation, you > can find it here: > http://demos.vicomtech.org/volren/ > > Feel free to give us any comments, they will be very appreciated. > > John > > 2011/3/29 Ribble, Maurice : >> John, that sounds interesting. ?I did some volume rendering many years ago and I always find alternate techniques interesting. ?I'm going to keep an eye out for that. ?Thanks for sharing! >> >> I wanted to clarify that all Adreno 200, 205, and 220 GPUs support the OES_texture_3D extension. ?There is very wide spread market adoption of the Adreno 200 family of GPUs. ?Qualcomm will continue supporting 3D textures with future versions of our Adreno GPUs in OpenGL ES. >> >> While I can't speak for WebGL I can say that with OpenGL ES it is common for application developers to detect extension strings and have various paths depending on what extensions are supported. ?This gives developers the choice with a little extra work to optimize their apps for different hardware. ?To me it doesn't seem that different from a web app supporting different browsers. ?That said, I do realize that extensions adds complexity and I'm very happy to see that the first version of WebGL has been finished. ?I hope various extensions, including 3D textures, are something that can be added as extensions to future WebGL implementations. >> >> -Maurice >> >> -----Original Message----- >> From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of John Congote >> Sent: Tuesday, March 29, 2011 6:58 AM >> To: Ginsburg, Daniel >> Cc: jdavis...@; Kenneth Russell; Thatcher Ulrich; public webgl; Gregg Tavares (wrk); Gavriel State; Daniel Koch >> Subject: Re: [Public WebGL] Volume Textures >> >> >> Hello, >> >> As you mentioned, 3D texture support would be very useful for medical >> imaging. Although, some workarounds exist in order to obtain the same >> graphical results with some penalization on dedicated platforms >> (Desktop-Workstation), but also gives the possibility to get the >> results in other devices like tablet pcs and mobile phones. >> >> We are presenting our approach for volume rendering in webgl in a >> publication. We had been working on it for about 1 year, the reason >> why we publish it now is because the WebGL specification has just been >> released. Our work is a volume rendering implementation using Ray >> Casting in a volume dataset stored as a 2D texture. >> >> We have intention to show a public demo at the end of the week. >> >> Thanks. >> >> >> 2011/3/24 Ginsburg, Daniel : >>> >>> I agree. ?Having 3D texture support would be especially useful in the medical imaging domain. ?Since 3D textures have been supported on desktop GPUs since 2000-ish, it would be great to see this available as an extension for desktop WebGL implementations. >>> >>> Thanks. >>> >>> -- Dan >>> >>> >>> On 3/24/11 7:18 AM, "John Davis" wrote: >>> >>> In the meantime, is there any chance we could add an extension to WebGL and Angle to support volume textures for the rather large use case of Chrome and FireFox? ?This is very low hanging fruit that will add considerable bang on the fragment shader side. >>> >>> On Mon, Mar 7, 2011 at 3:57 PM, Kenneth Russell wrote: >>> GL_OES_texture_3D seems to be unsupported on current iOS hardware, >>> which means that content using that extension wouldn't be portable to >>> a significant percentage of mobile devices. For this reason there >>> currently is no plan to incorporate that extension into the WebGL >>> registry as a "core" extension. A browser vendor would be welcome to >>> add it as a vendor-specific extension. >>> >>> That having been said, the WebGL spec aims to track the OpenGL ES >>> spec, and we anticipate a revision of the WebGL spec later this year >>> which is likely to add this functionality. >>> >>> -Ken >>> >>> On Sun, Mar 6, 2011 at 2:44 PM, John Davis wrote: >>>> Correct, but trilinear filtering in hardware is typically faster, and >>>> doesn't increase the instruction count. ?Not to mention, it's also much >>>> easier to have trilinear filtering that just works rather than implementing >>>> it with 2D. >>>> >>>> On Sun, Mar 6, 2011 at 3:16 PM, Thatcher Ulrich wrote: >>>>> >>>>> It doesn't seem that hard to simulate a volume texture using a large >>>>> 2D texture. ?Am I wrong? >>>>> >>>>> -T >>>>> >>>>> On Sun, Mar 6, 2011 at 4:57 PM, John Davis >>>>> wrote: >>>>> > Are any webgl implementations adding volume textures as an extension? >>>>> > ?This >>>>> > is pretty key for those of us needing fast 3D noise. >>>>> > Any updates on VTL in Angle? >>>>> > JD >>>>> > >>>>> >>>> >>>> >>> >>> >>> >>> >>> -- >>> Dan Ginsburg / email: daniel.ginsburg...@ >>> Principal Software Architect >>> Fetal-Neonatal Neuroimaging and Development Science Center >>> Children's Hospital Boston >>> 300 Longwood Avenue >>> Boston, MA 02115 >>> Phone: 857-218-5140 >>> >>> ----------------------------------------------------------- >>> 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 >>> ----------------------------------------------------------- >>> >>> >> >> >> >> -- >> M.Sc. John Edgar Congote Calle >> Sistemas de transporte inteligentes e Ingenier?a / Intelligent >> Transport Systems and Engineering >> Vicomtech-IK4 - Visual Interaction Communication Technologies >> Mikeletegi Pasealekua, 57 - Parque Tecnol?gico >> 20009 Donostia - San Sebasti?n - Spain >> Tel: +[34] 943 30 92 30 >> Fax: +[34] 943 30 93 93 >> e-mail: jcongote...@ >> www.vicomtech.org >> >> *** member of IK4 Research Alliance **** >> www.ik4.es >> *** member of GraphicsMedia.net **** >> www.graphicsmedia.net >> >> ----------------------------------------------------- >> Vicomtech-IK4 is an ISO 9001:2000 certified institute >> ----------------------------------------------------- >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> >> > > > > -- > M.Sc. John Edgar Congote Calle > Sistemas de transporte inteligentes e Ingenier?a / Intelligent > Transport Systems and Engineering > > Vicomtech-IK4 - Visual Interaction Communication Technologies > Mikeletegi Pasealekua, 57 - Parque Tecnol?gico > 20009 Donostia - San Sebasti?n - Spain > Tel: +[34] 943 30 92 30 > Fax: +[34] 943 30 93 93 > e-mail: jcongote...@ > www.vicomtech.org > > *** member of IK4 Research Alliance **** > www.ik4.es > *** member of GraphicsMedia.net **** > www.graphicsmedia.net > > ----------------------------------------------------- > Vicomtech-IK4 is an ISO 9001:2000 certified institute > ----------------------------------------------------- > ----------------------------------------------------------- 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 vla...@ Fri Apr 1 10:18:32 2011 From: vla...@ (Vladimir Vukicevic) Date: Fri, 1 Apr 2011 17:18:32 +0000 (GMT) Subject: [Public WebGL] Volume Textures In-Reply-To: Message-ID: <25539797.5196.1301678312086.JavaMail.root@zimbra.off.net> Hires Color worked for me -- and it's quite cool! John, I'm curious, what are the resolutions of the lowres/highres datasets? (Both as a 2d texture and the equivalent volume texture.) - Vlad ----- Original Message ----- > Wow, that's really cool! > > Do any of the other buttons aside from Aorta LowRes Color work at the > moment? It could use a loading progress indicator. > > -Ken > > P.S. Please post to https://groups.google.com/group/webgl-dev-list , > although your post is certainly relevant to this preexisting thread > and a good existence proof that the techniques are currently possible. > :) > > On Fri, Apr 1, 2011 at 3:23 AM, John Congote > wrote: > > Hello > > > > We have published a demo of out Volume Rendering implementation, you > > can find it here: > > http://demos.vicomtech.org/volren/ > > > > Feel free to give us any comments, they will be very appreciated. > > > > John > > > > 2011/3/29 Ribble, Maurice : > >> John, that sounds interesting. I did some volume rendering many > >> years ago and I always find alternate techniques interesting. I'm > >> going to keep an eye out for that. Thanks for sharing! > >> > >> I wanted to clarify that all Adreno 200, 205, and 220 GPUs support > >> the OES_texture_3D extension. There is very wide spread market > >> adoption of the Adreno 200 family of GPUs. Qualcomm will continue > >> supporting 3D textures with future versions of our Adreno GPUs in > >> OpenGL ES. > >> > >> While I can't speak for WebGL I can say that with OpenGL ES it is > >> common for application developers to detect extension strings and > >> have various paths depending on what extensions are supported. This > >> gives developers the choice with a little extra work to optimize > >> their apps for different hardware. To me it doesn't seem that > >> different from a web app supporting different browsers. That said, > >> I do realize that extensions adds complexity and I'm very happy to > >> see that the first version of WebGL has been finished. I hope > >> various extensions, including 3D textures, are something that can > >> be added as extensions to future WebGL implementations. > >> > >> -Maurice > >> > >> -----Original Message----- > >> From: owner-public_webgl...@ > >> [mailto:owner-public_webgl...@] On Behalf Of John Congote > >> Sent: Tuesday, March 29, 2011 6:58 AM > >> To: Ginsburg, Daniel > >> Cc: jdavis...@; Kenneth Russell; Thatcher Ulrich; > >> public webgl; Gregg Tavares (wrk); Gavriel State; Daniel Koch > >> Subject: Re: [Public WebGL] Volume Textures > >> > >> > >> Hello, > >> > >> As you mentioned, 3D texture support would be very useful for > >> medical imaging. Although, some workarounds exist in order to > >> obtain the same > >> graphical results with some penalization on dedicated platforms > >> (Desktop-Workstation), but also gives the possibility to get the > >> results in other devices like tablet pcs and mobile phones. > >> > >> We are presenting our approach for volume rendering in webgl in a > >> publication. We had been working on it for about 1 year, the reason > >> why we publish it now is because the WebGL specification has just > >> been released. Our work is a volume rendering implementation using > >> Ray Casting in a volume dataset stored as a 2D texture. > >> > >> We have intention to show a public demo at the end of the week. > >> > >> Thanks. > >> > >> > >> 2011/3/24 Ginsburg, Daniel : > >>> > >>> I agree. Having 3D texture support would be especially useful in > >>> the medical imaging domain. Since 3D textures have been supported > >>> on desktop GPUs since 2000-ish, it would be great to see this > >>> available as an extension for desktop WebGL implementations. > >>> > >>> Thanks. > >>> > >>> -- Dan > >>> > >>> > >>> On 3/24/11 7:18 AM, "John Davis" wrote: > >>> > >>> In the meantime, is there any chance we could add an extension to > >>> WebGL and Angle to support volume textures for the rather large > >>> use case of Chrome and FireFox? This is very low hanging fruit > >>> that will add considerable bang on the fragment shader side. > >>> > >>> On Mon, Mar 7, 2011 at 3:57 PM, Kenneth Russell > >>> wrote: GL_OES_texture_3D seems to be unsupported on current iOS > >>> hardware, which means that content using that extension wouldn't > >>> be portable to > >>> a significant percentage of mobile devices. For this reason there > >>> currently is no plan to incorporate that extension into the WebGL > >>> registry as a "core" extension. A browser vendor would be welcome > >>> to add it as a vendor-specific extension. > >>> > >>> That having been said, the WebGL spec aims to track the OpenGL ES > >>> spec, and we anticipate a revision of the WebGL spec later this > >>> year which is likely to add this functionality. > >>> > >>> -Ken > >>> > >>> On Sun, Mar 6, 2011 at 2:44 PM, John Davis > >>> wrote: > >>>> Correct, but trilinear filtering in hardware is typically faster, > >>>> and doesn't increase the instruction count. Not to mention, it's > >>>> also much > >>>> easier to have trilinear filtering that just works rather than > >>>> implementing it with 2D. > >>>> > >>>> On Sun, Mar 6, 2011 at 3:16 PM, Thatcher Ulrich > >>>> wrote: > >>>>> > >>>>> It doesn't seem that hard to simulate a volume texture using a > >>>>> large 2D texture. Am I wrong? > >>>>> > >>>>> -T > >>>>> > >>>>> On Sun, Mar 6, 2011 at 4:57 PM, John Davis > >>>>> > >>>>> wrote: > >>>>> > Are any webgl implementations adding volume textures as an > >>>>> > extension? > >>>>> > ?This > >>>>> > is pretty key for those of us needing fast 3D noise. > >>>>> > Any updates on VTL in Angle? > >>>>> > JD > >>>>> > > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> -- Dan Ginsburg / email: daniel.ginsburg...@ > >>> Principal Software Architect > >>> Fetal-Neonatal Neuroimaging and Development Science Center > >>> Children's Hospital Boston > >>> 300 Longwood Avenue > >>> Boston, MA 02115 > >>> Phone: 857-218-5140 > >>> > >>> ----------------------------------------------------------- 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 > >>> ----------------------------------------------------------- > >>> > >>> > >> > >> > >> > >> -- M.Sc. John Edgar Congote Calle > >> Sistemas de transporte inteligentes e Ingenier?a / Intelligent > >> Transport Systems and Engineering > >> Vicomtech-IK4 - Visual Interaction Communication Technologies > >> Mikeletegi Pasealekua, 57 - Parque Tecnol?gico > >> 20009 Donostia - San Sebasti?n - Spain > >> Tel: +[34] 943 30 92 30 > >> Fax: +[34] 943 30 93 93 > >> e-mail: jcongote...@ > >> www.vicomtech.org > >> > >> *** member of IK4 Research Alliance **** > >> www.ik4.es *** member of GraphicsMedia.net **** > >> www.graphicsmedia.net > >> > >> ----------------------------------------------------- Vicomtech-IK4 > >> is an ISO 9001:2000 certified institute > >> ----------------------------------------------------- > >> > >> ----------------------------------------------------------- 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 > >> ----------------------------------------------------------- > >> > >> > > > > > > > > -- M.Sc. John Edgar Congote Calle > > Sistemas de transporte inteligentes e Ingenier?a / Intelligent > > Transport Systems and Engineering > > > > Vicomtech-IK4 - Visual Interaction Communication Technologies > > Mikeletegi Pasealekua, 57 - Parque Tecnol?gico > > 20009 Donostia - San Sebasti?n - Spain > > Tel: +[34] 943 30 92 30 > > Fax: +[34] 943 30 93 93 > > e-mail: jcongote...@ > > www.vicomtech.org > > > > *** member of IK4 Research Alliance **** > > www.ik4.es *** member of GraphicsMedia.net **** > > www.graphicsmedia.net > > > > ----------------------------------------------------- Vicomtech-IK4 > > is an ISO 9001:2000 certified institute > > ----------------------------------------------------- > > > > ----------------------------------------------------------- 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 jco...@ Fri Apr 1 10:25:02 2011 From: jco...@ (John Congote) Date: Fri, 1 Apr 2011 19:25:02 +0200 Subject: [Public WebGL] Volume Textures In-Reply-To: <25539797.5196.1301678312086.JavaMail.root@zimbra.off.net> References: <25539797.5196.1301678312086.JavaMail.root@zimbra.off.net> Message-ID: Hello. The 2D textures can be download from: http://demos.vicomtech.org/volren/aorta-low.jpg (1024x1024) http://demos.vicomtech.org/volren/aorta-high.jpg (4096x4096) There is not a Volume Texture, all the information for the ray casting algorithm is extracted from the 2D texture. We detect a minor bug in the b/w version that we are going to correct soon. John. 2011/4/1 Vladimir Vukicevic : > Hires Color worked for me -- and it's quite cool! ?John, I'm curious, what are the resolutions of the lowres/highres datasets? ?(Both as a 2d texture and the equivalent volume texture.) > > ? ?- Vlad > > ----- Original Message ----- >> Wow, that's really cool! >> >> Do any of the other buttons aside from Aorta LowRes Color work at the >> moment? It could use a loading progress indicator. >> >> -Ken >> >> P.S. Please post to https://groups.google.com/group/webgl-dev-list , >> although your post is certainly relevant to this preexisting thread >> and a good existence proof that the techniques are currently possible. >> :) >> >> On Fri, Apr 1, 2011 at 3:23 AM, John Congote >> wrote: >> > Hello >> > >> > We have published a demo of out Volume Rendering implementation, you >> > can find it here: >> > http://demos.vicomtech.org/volren/ >> > >> > Feel free to give us any comments, they will be very appreciated. >> > >> > John >> > >> > 2011/3/29 Ribble, Maurice : >> >> John, that sounds interesting. I did some volume rendering many >> >> years ago and I always find alternate techniques interesting. I'm >> >> going to keep an eye out for that. Thanks for sharing! >> >> >> >> I wanted to clarify that all Adreno 200, 205, and 220 GPUs support >> >> the OES_texture_3D extension. There is very wide spread market >> >> adoption of the Adreno 200 family of GPUs. Qualcomm will continue >> >> supporting 3D textures with future versions of our Adreno GPUs in >> >> OpenGL ES. >> >> >> >> While I can't speak for WebGL I can say that with OpenGL ES it is >> >> common for application developers to detect extension strings and >> >> have various paths depending on what extensions are supported. This >> >> gives developers the choice with a little extra work to optimize >> >> their apps for different hardware. To me it doesn't seem that >> >> different from a web app supporting different browsers. That said, >> >> I do realize that extensions adds complexity and I'm very happy to >> >> see that the first version of WebGL has been finished. I hope >> >> various extensions, including 3D textures, are something that can >> >> be added as extensions to future WebGL implementations. >> >> >> >> -Maurice >> >> >> >> -----Original Message----- >> >> From: owner-public_webgl...@ >> >> [mailto:owner-public_webgl...@] On Behalf Of John Congote >> >> Sent: Tuesday, March 29, 2011 6:58 AM >> >> To: Ginsburg, Daniel >> >> Cc: jdavis...@; Kenneth Russell; Thatcher Ulrich; >> >> public webgl; Gregg Tavares (wrk); Gavriel State; Daniel Koch >> >> Subject: Re: [Public WebGL] Volume Textures >> >> >> >> >> >> Hello, >> >> >> >> As you mentioned, 3D texture support would be very useful for >> >> medical imaging. Although, some workarounds exist in order to >> >> obtain the same >> >> graphical results with some penalization on dedicated platforms >> >> (Desktop-Workstation), but also gives the possibility to get the >> >> results in other devices like tablet pcs and mobile phones. >> >> >> >> We are presenting our approach for volume rendering in webgl in a >> >> publication. We had been working on it for about 1 year, the reason >> >> why we publish it now is because the WebGL specification has just >> >> been released. Our work is a volume rendering implementation using >> >> Ray Casting in a volume dataset stored as a 2D texture. >> >> >> >> We have intention to show a public demo at the end of the week. >> >> >> >> Thanks. >> >> >> >> >> >> 2011/3/24 Ginsburg, Daniel : >> >>> >> >>> I agree. Having 3D texture support would be especially useful in >> >>> the medical imaging domain. Since 3D textures have been supported >> >>> on desktop GPUs since 2000-ish, it would be great to see this >> >>> available as an extension for desktop WebGL implementations. >> >>> >> >>> Thanks. >> >>> >> >>> -- Dan >> >>> >> >>> >> >>> On 3/24/11 7:18 AM, "John Davis" wrote: >> >>> >> >>> In the meantime, is there any chance we could add an extension to >> >>> WebGL and Angle to support volume textures for the rather large >> >>> use case of Chrome and FireFox? This is very low hanging fruit >> >>> that will add considerable bang on the fragment shader side. >> >>> >> >>> On Mon, Mar 7, 2011 at 3:57 PM, Kenneth Russell >> >>> wrote: GL_OES_texture_3D seems to be unsupported on current iOS >> >>> hardware, which means that content using that extension wouldn't >> >>> be portable to >> >>> a significant percentage of mobile devices. For this reason there >> >>> currently is no plan to incorporate that extension into the WebGL >> >>> registry as a "core" extension. A browser vendor would be welcome >> >>> to add it as a vendor-specific extension. >> >>> >> >>> That having been said, the WebGL spec aims to track the OpenGL ES >> >>> spec, and we anticipate a revision of the WebGL spec later this >> >>> year which is likely to add this functionality. >> >>> >> >>> -Ken >> >>> >> >>> On Sun, Mar 6, 2011 at 2:44 PM, John Davis >> >>> wrote: >> >>>> Correct, but trilinear filtering in hardware is typically faster, >> >>>> and doesn't increase the instruction count. Not to mention, it's >> >>>> also much >> >>>> easier to have trilinear filtering that just works rather than >> >>>> implementing it with 2D. >> >>>> >> >>>> On Sun, Mar 6, 2011 at 3:16 PM, Thatcher Ulrich >> >>>> wrote: >> >>>>> >> >>>>> It doesn't seem that hard to simulate a volume texture using a >> >>>>> large 2D texture. Am I wrong? >> >>>>> >> >>>>> -T >> >>>>> >> >>>>> On Sun, Mar 6, 2011 at 4:57 PM, John Davis >> >>>>> >> >>>>> wrote: >> >>>>> > Are any webgl implementations adding volume textures as an >> >>>>> > extension? >> >>>>> > ?This >> >>>>> > is pretty key for those of us needing fast 3D noise. >> >>>>> > Any updates on VTL in Angle? >> >>>>> > JD >> >>>>> > >> >>>>> >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >>> -- Dan Ginsburg / email: daniel.ginsburg...@ >> >>> Principal Software Architect >> >>> Fetal-Neonatal Neuroimaging and Development Science Center >> >>> Children's Hospital Boston >> >>> 300 Longwood Avenue >> >>> Boston, MA 02115 >> >>> Phone: 857-218-5140 >> >>> >> >>> ----------------------------------------------------------- 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 >> >>> ----------------------------------------------------------- >> >>> >> >>> >> >> >> >> >> >> >> >> -- M.Sc. John Edgar Congote Calle >> >> Sistemas de transporte inteligentes e Ingenier?a / Intelligent >> >> Transport Systems and Engineering >> >> Vicomtech-IK4 - Visual Interaction Communication Technologies >> >> Mikeletegi Pasealekua, 57 - Parque Tecnol?gico >> >> 20009 Donostia - San Sebasti?n - Spain >> >> Tel: +[34] 943 30 92 30 >> >> Fax: +[34] 943 30 93 93 >> >> e-mail: jcongote...@ >> >> www.vicomtech.org >> >> >> >> *** member of IK4 Research Alliance **** >> >> www.ik4.es *** member of GraphicsMedia.net **** >> >> www.graphicsmedia.net >> >> >> >> ----------------------------------------------------- Vicomtech-IK4 >> >> is an ISO 9001:2000 certified institute >> >> ----------------------------------------------------- >> >> >> >> ----------------------------------------------------------- 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 >> >> ----------------------------------------------------------- >> >> >> >> >> > >> > >> > >> > -- M.Sc. John Edgar Congote Calle >> > Sistemas de transporte inteligentes e Ingenier?a / Intelligent >> > Transport Systems and Engineering >> > >> > Vicomtech-IK4 - Visual Interaction Communication Technologies >> > Mikeletegi Pasealekua, 57 - Parque Tecnol?gico >> > 20009 Donostia - San Sebasti?n - Spain >> > Tel: +[34] 943 30 92 30 >> > Fax: +[34] 943 30 93 93 >> > e-mail: jcongote...@ >> > www.vicomtech.org >> > >> > *** member of IK4 Research Alliance **** >> > www.ik4.es *** member of GraphicsMedia.net **** >> > www.graphicsmedia.net >> > >> > ----------------------------------------------------- Vicomtech-IK4 >> > is an ISO 9001:2000 certified institute >> > ----------------------------------------------------- >> > >> >> ----------------------------------------------------------- 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 >> ----------------------------------------------------------- > -- M.Sc. John Edgar Congote Calle Sistemas de transporte inteligentes e Ingenier?a / Intelligent Transport Systems and Engineering Vicomtech-IK4 - Visual Interaction Communication Technologies Mikeletegi Pasealekua, 57 - Parque Tecnol?gico 20009 Donostia - San Sebasti?n - Spain Tel: +[34] 943 30 92 30 Fax: +[34] 943 30 93 93 e-mail: jcongote...@ www.vicomtech.org *** member of IK4 Research Alliance **** www.ik4.es *** member of GraphicsMedia.net **** www.graphicsmedia.net ----------------------------------------------------- Vicomtech-IK4 is an ISO 9001:2000 certified institute ----------------------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. La informaci?n incluida en el presente correo es confidencial sometida a secreto profesional, especialmente en lo que respecta a los datos de car?cter personal, cuya divulgaci?n est? prohibida, en virtud de la legislaci?n vigente. Si usted no es el destinatario leg?timo y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo. En todo caso abstengase de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje as? como los ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. Cualquier opini?n contenida en este correo es exclusiva de su autor y no representa necesariamente la opini?n de ASOCIACI?N CENTRO DE TECNOLOG?AS DE INTERACCI?N VISUAL Y COMUNICACIONES VICOMTECH (en adelante Vicomtech-IK4) El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. Con motivo de la entrada en vigor de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Informaci?n y de Comercio Electr?nico, le informamos que pueden revocar en cualquier momento, de forma sencilla y gratuita, el consentimiento para la recepci?n de mensajes de vicomtech.org en info.lopd...@ ----------------------------------------------------------- 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 jco...@ Fri Apr 1 10:50:30 2011 From: jco...@ (John Congote) Date: Fri, 1 Apr 2011 19:50:30 +0200 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <0F56B94025EFF74B94BF26E1E6DA46676DB41C0DF9@NALASEXMB13.na.qualcomm.com> Message-ID: Hello All the buttons should work now, but may be some configurations or hardware present problems. We would check if it is possible to add a progress indicator for the loading images and shader compilation, which are the bottlenecks now. John 2011/4/1 Kenneth Russell : > Wow, that's really cool! > > Do any of the other buttons aside from Aorta LowRes Color work at the > moment? It could use a loading progress indicator. > > -Ken > > P.S. Please post to https://groups.google.com/group/webgl-dev-list , > although your post is certainly relevant to this preexisting thread > and a good existence proof that the techniques are currently possible. > :) > > On Fri, Apr 1, 2011 at 3:23 AM, John Congote wrote: >> Hello >> >> We have published a demo of out Volume Rendering implementation, you >> can find it here: >> http://demos.vicomtech.org/volren/ >> >> Feel free to give us any comments, they will be very appreciated. >> >> John >> >> 2011/3/29 Ribble, Maurice : >>> John, that sounds interesting. ?I did some volume rendering many years ago and I always find alternate techniques interesting. ?I'm going to keep an eye out for that. ?Thanks for sharing! >>> >>> I wanted to clarify that all Adreno 200, 205, and 220 GPUs support the OES_texture_3D extension. ?There is very wide spread market adoption of the Adreno 200 family of GPUs. ?Qualcomm will continue supporting 3D textures with future versions of our Adreno GPUs in OpenGL ES. >>> >>> While I can't speak for WebGL I can say that with OpenGL ES it is common for application developers to detect extension strings and have various paths depending on what extensions are supported. ?This gives developers the choice with a little extra work to optimize their apps for different hardware. ?To me it doesn't seem that different from a web app supporting different browsers. ?That said, I do realize that extensions adds complexity and I'm very happy to see that the first version of WebGL has been finished. ?I hope various extensions, including 3D textures, are something that can be added as extensions to future WebGL implementations. >>> >>> -Maurice >>> >>> -----Original Message----- >>> From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of John Congote >>> Sent: Tuesday, March 29, 2011 6:58 AM >>> To: Ginsburg, Daniel >>> Cc: jdavis...@; Kenneth Russell; Thatcher Ulrich; public webgl; Gregg Tavares (wrk); Gavriel State; Daniel Koch >>> Subject: Re: [Public WebGL] Volume Textures >>> >>> >>> Hello, >>> >>> As you mentioned, 3D texture support would be very useful for medical >>> imaging. Although, some workarounds exist in order to obtain the same >>> graphical results with some penalization on dedicated platforms >>> (Desktop-Workstation), but also gives the possibility to get the >>> results in other devices like tablet pcs and mobile phones. >>> >>> We are presenting our approach for volume rendering in webgl in a >>> publication. We had been working on it for about 1 year, the reason >>> why we publish it now is because the WebGL specification has just been >>> released. Our work is a volume rendering implementation using Ray >>> Casting in a volume dataset stored as a 2D texture. >>> >>> We have intention to show a public demo at the end of the week. >>> >>> Thanks. >>> >>> >>> 2011/3/24 Ginsburg, Daniel : >>>> >>>> I agree. ?Having 3D texture support would be especially useful in the medical imaging domain. ?Since 3D textures have been supported on desktop GPUs since 2000-ish, it would be great to see this available as an extension for desktop WebGL implementations. >>>> >>>> Thanks. >>>> >>>> -- Dan >>>> >>>> >>>> On 3/24/11 7:18 AM, "John Davis" wrote: >>>> >>>> In the meantime, is there any chance we could add an extension to WebGL and Angle to support volume textures for the rather large use case of Chrome and FireFox? ?This is very low hanging fruit that will add considerable bang on the fragment shader side. >>>> >>>> On Mon, Mar 7, 2011 at 3:57 PM, Kenneth Russell wrote: >>>> GL_OES_texture_3D seems to be unsupported on current iOS hardware, >>>> which means that content using that extension wouldn't be portable to >>>> a significant percentage of mobile devices. For this reason there >>>> currently is no plan to incorporate that extension into the WebGL >>>> registry as a "core" extension. A browser vendor would be welcome to >>>> add it as a vendor-specific extension. >>>> >>>> That having been said, the WebGL spec aims to track the OpenGL ES >>>> spec, and we anticipate a revision of the WebGL spec later this year >>>> which is likely to add this functionality. >>>> >>>> -Ken >>>> >>>> On Sun, Mar 6, 2011 at 2:44 PM, John Davis wrote: >>>>> Correct, but trilinear filtering in hardware is typically faster, and >>>>> doesn't increase the instruction count. ?Not to mention, it's also much >>>>> easier to have trilinear filtering that just works rather than implementing >>>>> it with 2D. >>>>> >>>>> On Sun, Mar 6, 2011 at 3:16 PM, Thatcher Ulrich wrote: >>>>>> >>>>>> It doesn't seem that hard to simulate a volume texture using a large >>>>>> 2D texture. ?Am I wrong? >>>>>> >>>>>> -T >>>>>> >>>>>> On Sun, Mar 6, 2011 at 4:57 PM, John Davis >>>>>> wrote: >>>>>> > Are any webgl implementations adding volume textures as an extension? >>>>>> > ?This >>>>>> > is pretty key for those of us needing fast 3D noise. >>>>>> > Any updates on VTL in Angle? >>>>>> > JD >>>>>> > >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Dan Ginsburg / email: daniel.ginsburg...@ >>>> Principal Software Architect >>>> Fetal-Neonatal Neuroimaging and Development Science Center >>>> Children's Hospital Boston >>>> 300 Longwood Avenue >>>> Boston, MA 02115 >>>> Phone: 857-218-5140 >>>> >>>> ----------------------------------------------------------- >>>> 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 >>>> ----------------------------------------------------------- >>>> >>>> >>> >>> >>> >>> -- >>> M.Sc. John Edgar Congote Calle >>> Sistemas de transporte inteligentes e Ingenier?a / Intelligent >>> Transport Systems and Engineering >>> Vicomtech-IK4 - Visual Interaction Communication Technologies >>> Mikeletegi Pasealekua, 57 - Parque Tecnol?gico >>> 20009 Donostia - San Sebasti?n - Spain >>> Tel: +[34] 943 30 92 30 >>> Fax: +[34] 943 30 93 93 >>> e-mail: jcongote...@ >>> www.vicomtech.org >>> >>> *** member of IK4 Research Alliance **** >>> www.ik4.es >>> *** member of GraphicsMedia.net **** >>> www.graphicsmedia.net >>> >>> ----------------------------------------------------- >>> Vicomtech-IK4 is an ISO 9001:2000 certified institute >>> ----------------------------------------------------- >>> >>> ----------------------------------------------------------- >>> 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 >>> ----------------------------------------------------------- >>> >>> >> >> >> >> -- >> M.Sc. John Edgar Congote Calle >> Sistemas de transporte inteligentes e Ingenier?a / Intelligent >> Transport Systems and Engineering >> >> Vicomtech-IK4 - Visual Interaction Communication Technologies >> Mikeletegi Pasealekua, 57 - Parque Tecnol?gico >> 20009 Donostia - San Sebasti?n - Spain >> Tel: +[34] 943 30 92 30 >> Fax: +[34] 943 30 93 93 >> e-mail: jcongote...@ >> www.vicomtech.org >> >> *** member of IK4 Research Alliance **** >> www.ik4.es >> *** member of GraphicsMedia.net **** >> www.graphicsmedia.net >> >> ----------------------------------------------------- >> Vicomtech-IK4 is an ISO 9001:2000 certified institute >> ----------------------------------------------------- >> > -- M.Sc. John Edgar Congote Calle Sistemas de transporte inteligentes e Ingenier?a / Intelligent Transport Systems and Engineering Vicomtech-IK4 - Visual Interaction Communication Technologies Mikeletegi Pasealekua, 57 - Parque Tecnol?gico 20009 Donostia - San Sebasti?n - Spain Tel: +[34] 943 30 92 30 Fax: +[34] 943 30 93 93 e-mail: jcongote...@ www.vicomtech.org *** member of IK4 Research Alliance **** www.ik4.es *** member of GraphicsMedia.net **** www.graphicsmedia.net ----------------------------------------------------- Vicomtech-IK4 is an ISO 9001:2000 certified institute ----------------------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. La informaci?n incluida en el presente correo es confidencial sometida a secreto profesional, especialmente en lo que respecta a los datos de car?cter personal, cuya divulgaci?n est? prohibida, en virtud de la legislaci?n vigente. Si usted no es el destinatario leg?timo y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo. En todo caso abstengase de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje as? como los ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. Cualquier opini?n contenida en este correo es exclusiva de su autor y no representa necesariamente la opini?n de ASOCIACI?N CENTRO DE TECNOLOG?AS DE INTERACCI?N VISUAL Y COMUNICACIONES VICOMTECH (en adelante Vicomtech-IK4) El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. Con motivo de la entrada en vigor de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Informaci?n y de Comercio Electr?nico, le informamos que pueden revocar en cualquier momento, de forma sencilla y gratuita, el consentimiento para la recepci?n de mensajes de vicomtech.org en info.lopd...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Sat Apr 2 05:46:35 2011 From: jda...@ (John Davis) Date: Sat, 2 Apr 2011 07:46:35 -0500 Subject: [Public WebGL] Volume Textures In-Reply-To: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> Message-ID: >all of the extensions there are available on at least one OpenGL ES implementation on mobile devices (iPhone). Chris, Why does the above matter if WebGL is never going to be available on iPhone/iPad/AppleTV? Why don't we focus on what IS available? JD On Thu, Mar 24, 2011 at 11:30 AM, Chris Marrin wrote: > > > On Mar 24, 2011, at 4:18 AM, John Davis wrote: > > > In the meantime, is there any chance we could add an extension to WebGL > and Angle to support volume textures for the rather large use case of Chrome > and FireFox? This is very low hanging fruit that will add considerable bang > on the fragment shader side. > > Let's be careful about what we call "low hanging fruit". WebGL attempts to > allow content to be written across a wide range of hardware. That's why we > based the spec on OpenGL ES 2.0 rather than desktop OpenGL. If you look at > the WebGL extension registry ( > http://www.khronos.org/registry/webgl/extensions/), all of the extensions > there are available on at least one OpenGL ES implementation on mobile > devices (iPhone). > > That doesn't mean we can't discuss other extensions (like this one). But I > would be very against adding any and all extensions just because they exist > on some driver in some version of OpenGL on some platform. I even agree that > 3D textures are available in a majority of desktop OpenGL implementations. > And GL_OES_texture_3D is defined for OpenGL ES. But I don't know of any > current implementations of OpenGL ES that support it. > > My concern is that WebGL will get fragmented and that authors will start > using extensions that are available on a small number of implementations > degrading the WebGL experience for everyone else. I don't think we want to > go there at this early stage of development. > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Sat Apr 2 07:54:23 2011 From: bja...@ (Benoit Jacob) Date: Sat, 2 Apr 2011 07:54:23 -0700 (PDT) Subject: [Public WebGL] Volume Textures In-Reply-To: Message-ID: <1376695059.12281.1301756063313.JavaMail.root@cm-mail03.mozilla.org> >all of the extensions there are available on at least one OpenGL ES implementation on mobile devices (iPhone). Chris, Why does the above matter if WebGL is never going to be available on iPhone/iPad/AppleTV? Why don't we focus on what IS available? We won't make much progress if we keep re-debating the same topics again and again. It's always been clear that we want WebGL content to be readily viewable on mobile devices, see for example http://blog.vlad1.com/2009/12/01/webgl-goes-mobile/ and that involves making sure that WebGL doesn't rely on features that aren't widely available in cell phones. The iPhone/iPad might not support WebGL content today, but that's not something we want to set in stone. On the contrary we want to keep it as easy as possible for Apple to fix. Moreover, WebGL is readily available on other cell phones, which have the same kind of embedded GPUs with similar limitations. Cheers, Benoit JD On Thu, Mar 24, 2011 at 11:30 AM, Chris Marrin < cmarrin...@ > wrote: On Mar 24, 2011, at 4:18 AM, John Davis wrote: > In the meantime, is there any chance we could add an extension to WebGL and Angle to support volume textures for the rather large use case of Chrome and FireFox? This is very low hanging fruit that will add considerable bang on the fragment shader side. Let's be careful about what we call "low hanging fruit". WebGL attempts to allow content to be written across a wide range of hardware. That's why we based the spec on OpenGL ES 2.0 rather than desktop OpenGL. If you look at the WebGL extension registry ( http://www.khronos.org/registry/webgl/extensions/ ), all of the extensions there are available on at least one OpenGL ES implementation on mobile devices (iPhone). That doesn't mean we can't discuss other extensions (like this one). But I would be very against adding any and all extensions just because they exist on some driver in some version of OpenGL on some platform. I even agree that 3D textures are available in a majority of desktop OpenGL implementations. And GL_OES_texture_3D is defined for OpenGL ES. But I don't know of any current implementations of OpenGL ES that support it. My concern is that WebGL will get fragmented and that authors will start using extensions that are available on a small number of implementations degrading the WebGL experience for everyone else. I don't think we want to go there at this early stage of development. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Tue Apr 5 09:09:39 2011 From: cma...@ (Chris Marrin) Date: Tue, 05 Apr 2011 09:09:39 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> Message-ID: <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> On Apr 2, 2011, at 5:46 AM, John Davis wrote: > >all of the extensions there are available on at least one OpenGL ES implementation on mobile devices (iPhone). > > Chris, > > Why does the above matter if WebGL is never going to be available on iPhone/iPad/AppleTV? Why don't we focus on what IS available? Are you just making a fatalistic complaint that you're unhappy with the fact that iOS devices don't publicly support WebGL today? Or did you get the impression from me or someone else that iOS will never support WebGL? If you interpreted something I said in that way, then I apologize. No one at Apple can comment on if or when WebGL will be available on iOS. If you've gotten that information from a blog somewhere then you should ignore it (as is a general rule about bloggers and Apple rumors). ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Tue Apr 5 19:56:33 2011 From: jda...@ (John Davis) Date: Tue, 5 Apr 2011 21:56:33 -0500 Subject: [Public WebGL] Volume Textures In-Reply-To: <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: I'm frustrated we are hamstringing the spec due to limitations on the mobile side. The majority of web browsers out there are not being used on mobile devices. Call me nuts, but this just doesn't make sense. Look at the Web clients table. http://en.wikipedia.org/wiki/Usage_share_of_operating_systems Percentage-wise mobile web clients don't amount to squat. On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin wrote: > > On Apr 2, 2011, at 5:46 AM, John Davis wrote: > > > >all of the extensions there are available on at least one OpenGL ES > implementation on mobile devices (iPhone). > > > > Chris, > > > > Why does the above matter if WebGL is never going to be available on > iPhone/iPad/AppleTV? Why don't we focus on what IS available? > > Are you just making a fatalistic complaint that you're unhappy with the > fact that iOS devices don't publicly support WebGL today? Or did you get the > impression from me or someone else that iOS will never support WebGL? If you > interpreted something I said in that way, then I apologize. No one at Apple > can comment on if or when WebGL will be available on iOS. If you've gotten > that information from a blog somewhere then you should ignore it (as is a > general rule about bloggers and Apple rumors). > > ----- > ~Chris > cmarrin...@ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Apr 5 23:06:00 2011 From: cal...@ (Mark Callow) Date: Wed, 06 Apr 2011 15:06:00 +0900 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: <4D9C02C8.3050707@hicorp.co.jp> Those stat's are deeply suspicious. It is widely reported that in Japan the majority of people access the internet from their mobile devices. A large number of these devices do not have identifiable operation systems. Another pointer is that when I visited http://whatsmyuseragent.com, only 4 of the most recent 15 visitors came from desktop devices. Regards -Mark On 06/04/2011 11:56, John Davis wrote: > I'm frustrated we are hamstringing the spec due to limitations on the > mobile side. The majority of web browsers out there are not being > used on mobile devices. Call me nuts, but this just doesn't make sense. > > Look at the Web clients table. > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > Percentage-wise mobile web clients don't amount to squat. > > On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin > wrote: > > > On Apr 2, 2011, at 5:46 AM, John Davis wrote: > > > >all of the extensions there are available on at least one > OpenGL ES implementation on mobile devices (iPhone). > > > > Chris, > > > > Why does the above matter if WebGL is never going to be > available on iPhone/iPad/AppleTV? Why don't we focus on what IS > available? > > Are you just making a fatalistic complaint that you're unhappy > with the fact that iOS devices don't publicly support WebGL today? > Or did you get the impression from me or someone else that iOS > will never support WebGL? If you interpreted something I said in > that way, then I apologize. No one at Apple can comment on if or > when WebGL will be available on iOS. If you've gotten that > information from a blog somewhere then you should ignore it (as is > a general rule about bloggers and Apple rumors). > > ----- > ~Chris > cmarrin...@ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From ase...@ Wed Apr 6 00:46:06 2011 From: ase...@ (Alvaro Segura) Date: Wed, 06 Apr 2011 09:46:06 +0200 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: <4D9C1A3E.2050808@vicomtech.org> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logovicomtech-ik4_150.png Type: image/png Size: 10808 bytes Desc: Visual Interaction Communication Technologies - IK4 Research Alliance URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: barraSinFondo_150.png Type: image/png Size: 2828 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ojo.png Type: image/png Size: 4363 bytes Desc: Visual Interaction Communication Technologies - IK4 Research Alliance URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GraphicsMediaNet_150.png Type: image/png Size: 8191 bytes Desc: International Network for the Cooperation in Applied Research in Computer Graphics, Multimoda-Multimedia Technologies and Visual Interactive Digital Media Technologies URL: From jda...@ Wed Apr 6 04:05:01 2011 From: jda...@ (John Davis) Date: Wed, 6 Apr 2011 06:05:01 -0500 Subject: [Public WebGL] Volume Textures In-Reply-To: <4D9C02C8.3050707@hicorp.co.jp> References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> <4D9C02C8.3050707@hicorp.co.jp> Message-ID: That's still a 1:4 ratio, the tail is wagging the dog. On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow wrote: > Those stat's are deeply suspicious. > > It is widely reported that in Japan the majority of people access the > internet from their mobile devices. A large number of these devices do not > have identifiable operation systems. > > Another pointer is that when I visited http://whatsmyuseragent.com, only 4 > of the most recent 15 visitors came from desktop devices. > > Regards > > -Mark > > > > > > On 06/04/2011 11:56, John Davis wrote: > > I'm frustrated we are hamstringing the spec due to limitations on the > mobile side. The majority of web browsers out there are not being used on > mobile devices. Call me nuts, but this just doesn't make sense. > > Look at the Web clients table. > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > Percentage-wise mobile web clients don't amount to squat. > > On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin wrote: > >> >> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >> >> > >all of the extensions there are available on at least one OpenGL ES >> implementation on mobile devices (iPhone). >> > >> > Chris, >> > >> > Why does the above matter if WebGL is never going to be available on >> iPhone/iPad/AppleTV? Why don't we focus on what IS available? >> >> Are you just making a fatalistic complaint that you're unhappy with the >> fact that iOS devices don't publicly support WebGL today? Or did you get the >> impression from me or someone else that iOS will never support WebGL? If you >> interpreted something I said in that way, then I apologize. No one at Apple >> can comment on if or when WebGL will be available on iOS. If you've gotten >> that information from a blog somewhere then you should ignore it (as is a >> general rule about bloggers and Apple rumors). >> >> ----- >> ~Chris >> cmarrin...@ >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Wed Apr 6 04:49:09 2011 From: vla...@ (Vladimir Vukicevic) Date: Wed, 6 Apr 2011 11:49:09 +0000 (GMT) Subject: [Public WebGL] Volume Textures In-Reply-To: <4D9C02C8.3050707@hicorp.co.jp> Message-ID: <4062493.7726.1302090549202.JavaMail.root@zimbra.off.net> Yeah, the numbers are pretty hard to quantify, especially if you try to toss in something like "modern web browser" in there. The *trend* is that people are accessing the "full modern web" more and more from phones, but nowhere near as much as from desktops right this moment. So WebGL can either follow the trend and have it become the absolute standard way of doing 3D on the web on both desktop and mobile, or it can sacrifice some mobile compat now, with the expectation that mobile will "catch up" hardware capability wise soon... but that opens the door to having some other technology come in and grow with mobile from day one. However, that's an argument for baseline capabilities. I'd personally like to see a broader set of extensions, including 3D textures. Their usage should also provide useful information for mobile hardware manufacturers' future silicon plans. - Vlad ----- Original Message ----- > Those stat's are deeply suspicious. > > > It is widely reported that in Japan the majority of people access the > internet from their mobile devices. A large number of these devices do > not have identifiable operation systems. > > > Another pointer is that when I visited http://whatsmyuseragent.com , > only 4 of the most recent 15 visitors came from desktop devices. > > > Regards > > > > -Mark > > > > On 06/04/2011 11:56, John Davis wrote: > > I'm frustrated we are hamstringing the spec due to limitations on the > mobile side. The majority of web browsers out there are not being used > on mobile devices. Call me nuts, but this just doesn't make sense. > > > Look at the Web clients table. > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > > Percentage-wise mobile web clients don't amount to squat. > > > On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin < cmarrin...@ > > wrote: > > > > > On Apr 2, 2011, at 5:46 AM, John Davis wrote: > > > >all of the extensions there are available on at least one OpenGL ES > > >implementation on mobile devices (iPhone). > > > > Chris, > > > > Why does the above matter if WebGL is never going to be available on > > iPhone/iPad/AppleTV? Why don't we focus on what IS available? > > Are you just making a fatalistic complaint that you're unhappy with > the fact that iOS devices don't publicly support WebGL today? Or did > you get the impression from me or someone else that iOS will never > support WebGL? If you interpreted something I said in that way, then I > apologize. No one at Apple can comment on if or when WebGL will be > available on iOS. If you've gotten that information from a blog > somewhere then you should ignore it (as is a general rule about > bloggers and Apple rumors). > > ----- ~Chris > cmarrin...@ ----------------------------------------------------------- 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 ste...@ Wed Apr 6 05:14:51 2011 From: ste...@ (ste...@) Date: Wed, 6 Apr 2011 05:14:51 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: We can argue about the current numbers but the trend is clearly that phones and pads and netbooks are on the rise and more people will be using the next generation of handheld game consoles for surfing. All of those kinds of device are engineered down to a price and to a battery budget. Furthermore, WebGL is new - it's much easier to extend a specification in the future than it is to restrict it once a bunch of websites are depending upon it. It would be very easy to make a specification that so few users could use that developers would ignore it. We have to be careful if we want this to command enough market share to attract web site developers to use it. -- Steve > I'm frustrated we are hamstringing the spec due to limitations on the > mobile > side. The majority of web browsers out there are not being used on mobile > devices. Call me nuts, but this just doesn't make sense. > > Look at the Web clients table. > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > > Percentage-wise mobile web clients don't amount to squat. > > On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin wrote: > >> >> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >> >> > >all of the extensions there are available on at least one OpenGL ES >> implementation on mobile devices (iPhone). >> > >> > Chris, >> > >> > Why does the above matter if WebGL is never going to be available on >> iPhone/iPad/AppleTV? Why don't we focus on what IS available? >> >> Are you just making a fatalistic complaint that you're unhappy with the >> fact that iOS devices don't publicly support WebGL today? Or did you get >> the >> impression from me or someone else that iOS will never support WebGL? If >> you >> interpreted something I said in that way, then I apologize. No one at >> Apple >> can comment on if or when WebGL will be available on iOS. If you've >> gotten >> that information from a blog somewhere then you should ignore it (as is >> a >> general rule about bloggers and Apple rumors). >> >> ----- >> ~Chris >> cmarrin...@ >> >> >> >> >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Wed Apr 6 08:13:54 2011 From: cma...@ (Chris Marrin) Date: Wed, 06 Apr 2011 08:13:54 -0700 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: On Apr 5, 2011, at 7:56 PM, John Davis wrote: > I'm frustrated we are hamstringing the spec due to limitations on the mobile side. The majority of web browsers out there are not being used on mobile devices. Call me nuts, but this just doesn't make sense. > > Look at the Web clients table. > http://en.wikipedia.org/wiki/Usage_share_of_operating_systems Patience. A full web browsing experience one mobile devices has been around for less than 4 years. In that time mobile devices have increased in performance by a factor of at least 5 and graphics has improved by a factor of around 20 or so. And yet mobile devices are just now getting capable enough to give a decent WebGL experience. Just imagine where we will be in another 4 years. Drivers need to get more robust and we still need another doubling or two to really make WebGL viable across the board. Don't look where we are today. Prepare for where we'll be in a couple of years. 2 years ago there was no way to do anything like WebGL in a browser. Now we have that capability in several major browser offering with more to surely follow in the future. I don't call that hamstrung, I call it progress and am excited about the next steps! ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Apr 6 09:43:33 2011 From: jda...@ (John Davis) Date: Wed, 6 Apr 2011 11:43:33 -0500 Subject: [Public WebGL] Re: Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: In four years I'll be eating geritol and wearing a diaper. Why exactly do we have extensions? What prevents extensions from later being folded into the spec? On Wednesday, April 6, 2011, Chris Marrin wrote: > > On Apr 5, 2011, at 7:56 PM, John Davis wrote: > I'm frustrated we are hamstringing the spec due to limitations on the mobile side. ?The majority of web browsers out there are not being used on mobile devices. ?Call me nuts, but this just doesn't make sense. > > Look at the Web clients table.http://en.wikipedia.org/wiki/Usage_share_of_operating_systems > Patience. A full web browsing experience one mobile devices has been around for less than 4 years. In that time mobile devices have increased in performance by a factor of at least 5 and graphics has improved by a factor of around 20 or so. And yet mobile devices are just now getting capable enough to give a decent WebGL experience. Just imagine where we will be in another 4 years. > Drivers need to get more robust and we still need another doubling or two to really make WebGL viable across the board. Don't look where we are today. Prepare for where we'll be in a couple of years. > 2 years ago there was no way to do anything like WebGL in a browser. Now we have that capability in several major browser offering with more to surely follow in the future. I don't call that hamstrung, I call it progress and am excited about the next steps! > > -----~Chriscmarrin...@ > > > > > > ----------------------------------------------------------- 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 cma...@ Wed Apr 6 10:06:13 2011 From: cma...@ (Chris Marrin) Date: Wed, 06 Apr 2011 10:06:13 -0700 Subject: [Public WebGL] Re: Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> Message-ID: <7437A671-D968-400C-BFB1-7073E888C573@apple.com> On Apr 6, 2011, at 9:43 AM, John Davis wrote: > In four years I'll be eating geritol and wearing a diaper. Why > exactly do we have extensions? What prevents extensions from later > being folded into the spec? Nothing, and there's nothing to prevent a browser vendor from doing any extension they choose. That's what the extension mechanism is for. The WebGL Extension Registry on the other hand is a place to keep extensions ratified by the WebGL Working Group and are expected to be widely implemented with compatible functionality. But getting back to the 3D texture extension - I think recent events have proven that there are alternatives to a 3D texture extension and they work on all platforms. By not having a standard 3D texture extension authors have come up with creative solutions rather than falling back on an extension that can only be implemented on a subset of systems. 3D textures will make this functionality more performant and capable, and when it is widely available on WebGL hardware I will be all for adding it. But I don't think that time has come yet. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Wed Apr 6 18:58:31 2011 From: cal...@ (Mark Callow) Date: Thu, 07 Apr 2011 10:58:31 +0900 Subject: [Public WebGL] Volume Textures In-Reply-To: References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> <4D9C02C8.3050707@hicorp.co.jp> Message-ID: <4D9D1A47.3060903@hicorp.co.jp> I think you have that backwards. It's a 4:1 ratio mobile to desktop. Regards -Mark On 06/04/2011 20:05, John Davis wrote: > That's still a 1:4 ratio, the tail is wagging the dog. > > On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow > wrote: > > Those stat's are deeply suspicious. > > It is widely reported that in Japan the majority of people access > the internet from their mobile devices. A large number of these > devices do not have identifiable operation systems. > > Another pointer is that when I visited > http://whatsmyuseragent.com, only 4 of the most recent 15 visitors > came from desktop devices. > > Regards > > -Mark > > > > > > On 06/04/2011 11:56, John Davis wrote: >> I'm frustrated we are hamstringing the spec due to limitations on >> the mobile side. The majority of web browsers out there are not >> being used on mobile devices. Call me nuts, but this just >> doesn't make sense. >> >> Look at the Web clients table. >> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >> >> Percentage-wise mobile web clients don't amount to squat. >> >> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin > > wrote: >> >> >> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >> >> > >all of the extensions there are available on at least one >> OpenGL ES implementation on mobile devices (iPhone). >> > >> > Chris, >> > >> > Why does the above matter if WebGL is never going to be >> available on iPhone/iPad/AppleTV? Why don't we focus on what >> IS available? >> >> Are you just making a fatalistic complaint that you're >> unhappy with the fact that iOS devices don't publicly support >> WebGL today? Or did you get the impression from me or someone >> else that iOS will never support WebGL? If you interpreted >> something I said in that way, then I apologize. No one at >> Apple can comment on if or when WebGL will be available on >> iOS. If you've gotten that information from a blog somewhere >> then you should ignore it (as is a general rule about >> bloggers and Apple rumors). >> >> ----- >> ~Chris >> cmarrin...@ >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From jda...@ Wed Apr 6 19:18:51 2011 From: jda...@ (John Davis) Date: Wed, 6 Apr 2011 21:18:51 -0500 Subject: [Public WebGL] Volume Textures In-Reply-To: <4D9D1A47.3060903@hicorp.co.jp> References: <5C2E1744-A417-444B-89A4-EB79A3851DEC@apple.com> <094766D9-E1A3-4E05-981D-FF654AB937EF@apple.com> <4D9C02C8.3050707@hicorp.co.jp> <4D9D1A47.3060903@hicorp.co.jp> Message-ID: My bad, you're right. Again I site the stats from multiple sources at http://en.wikipedia.org/wiki/Usage_share_of_operating_systems Doesn't matter though, I guess we won't see volume textures until Chris says we can have them. Unless of course Gregg would be willing to have Transgaming add it to Angle w/o it being in the official extension registry. On Wed, Apr 6, 2011 at 8:58 PM, Mark Callow wrote: > I think you have that backwards. It's a 4:1 ratio mobile to desktop. > > Regards > > -Mark > > > > > > On 06/04/2011 20:05, John Davis wrote: > > That's still a 1:4 ratio, the tail is wagging the dog. > > On Wed, Apr 6, 2011 at 1:06 AM, Mark Callow wrote: > >> Those stat's are deeply suspicious. >> >> It is widely reported that in Japan the majority of people access the >> internet from their mobile devices. A large number of these devices do not >> have identifiable operation systems. >> >> Another pointer is that when I visited http://whatsmyuseragent.com, only >> 4 of the most recent 15 visitors came from desktop devices. >> >> Regards >> >> -Mark >> >> >> >> >> >> On 06/04/2011 11:56, John Davis wrote: >> >> I'm frustrated we are hamstringing the spec due to limitations on the >> mobile side. The majority of web browsers out there are not being used on >> mobile devices. Call me nuts, but this just doesn't make sense. >> >> Look at the Web clients table. >> http://en.wikipedia.org/wiki/Usage_share_of_operating_systems >> >> Percentage-wise mobile web clients don't amount to squat. >> >> On Tue, Apr 5, 2011 at 11:09 AM, Chris Marrin wrote: >> >>> >>> On Apr 2, 2011, at 5:46 AM, John Davis wrote: >>> >>> > >all of the extensions there are available on at least one OpenGL ES >>> implementation on mobile devices (iPhone). >>> > >>> > Chris, >>> > >>> > Why does the above matter if WebGL is never going to be available on >>> iPhone/iPad/AppleTV? Why don't we focus on what IS available? >>> >>> Are you just making a fatalistic complaint that you're unhappy with the >>> fact that iOS devices don't publicly support WebGL today? Or did you get the >>> impression from me or someone else that iOS will never support WebGL? If you >>> interpreted something I said in that way, then I apologize. No one at Apple >>> can comment on if or when WebGL will be available on iOS. If you've gotten >>> that information from a blog somewhere then you should ignore it (as is a >>> general rule about bloggers and Apple rumors). >>> >>> ----- >>> ~Chris >>> cmarrin...@ >>> >>> >>> >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mic...@ Thu Apr 7 06:57:28 2011 From: Mic...@ (Behan, Michael) Date: Thu, 7 Apr 2011 09:57:28 -0400 Subject: [Public WebGL] WebGL compare&contrast with Adobe Molehill APIs? Message-ID: <8C64D7E6B45E094F9377065955DE0D9B1F1253A2F3@SM-FLOR-VXMB06B.wdw.disney.com> Howdy folks! I am pinging you all to find out if anyone knows of an existing compare & contrast of WebGL and the Molehill APIs by Adobe? Thanks a lot Michael Behan | web developer iii [cid:image001.jpg...@] mobile: 407-928-0109; aim/yahoo: michaelwdpro Michael.Behan...@ This message is confidential and contains information that is proprietary to The Walt Disney Company or its affiliates. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 19877 bytes Desc: image001.jpg URL: From ste...@ Thu Apr 7 09:20:40 2011 From: ste...@ (ste...@) Date: Thu, 7 Apr 2011 09:20:40 -0700 Subject: [Public WebGL] WebGL compare&contrast with Adobe Molehill APIs? In-Reply-To: <8C64D7E6B45E094F9377065955DE0D9B1F1253A2F3@SM-FLOR-VXMB06B.wdw.disney.com> References: <8C64D7E6B45E094F9377065955DE0D9B1F1253A2F3@SM-FLOR-VXMB06B.wdw.disney.com> Message-ID: There doesn't seem to be much information out there. What I know is this: * Molehill is Adobe's effort to add proper 3D graphics to Flash. * The actual ActionScript API is very similar to WebGL. That's inevitable because it's built on top of the same infrastructure...OpenGL and Direct3D. * The most significant (and deeply horrible) difference is that they decided to invent their own machine-code level language for writing shaders rather than using GLSL/Cg/HLSL!! I can't imagine why they did that...but that's what I'm seeing. With any luck it will "just die already"...but who knows? -- Steve > Howdy folks! > > I am pinging you all to find out if anyone knows of an existing compare & > contrast of WebGL and the Molehill APIs by Adobe? > > Thanks a lot > > Michael Behan | web developer iii > [cid:image001.jpg...@] > mobile: 407-928-0109; aim/yahoo: michaelwdpro > Michael.Behan...@ > > This message is confidential and contains information that is proprietary > to The Walt Disney Company or its affiliates. > > > ----------------------------------------------------------- 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 rko...@ Thu Apr 7 09:59:35 2011 From: rko...@ (Kornmann, Ralf) Date: Thu, 7 Apr 2011 17:59:35 +0100 Subject: AW: [Public WebGL] WebGL compare&contrast with Adobe Molehill APIs? In-Reply-To: References: <8C64D7E6B45E094F9377065955DE0D9B1F1253A2F3@SM-FLOR-VXMB06B.wdw.disney.com>, Message-ID: <9B3BEF16CBC82A45900B3F159DF91596015031D49ADE@EU-MAIL-1-1.rws.ad.ea.com> As I am not sure how off topic this is on this list I will make it short: - The documentation for molehill is public as part of the incubator program. What I have seen so far it has a similar feature set then WebGL. One plus is the support of compressed textures. - I believe the motivation doing an own low level shader language (seems byte code for me) was providing a higher compatibility over all devices. Higher level languages are well known for causing some trouble here as there is a higher possibility of differences in the parsers. - Even if the final version will worse than WebGL I think we can be sure that there will be a huge installation base (similar to Flash 10 today). Flash is although still a defacto standard for interactive media in the web. Personally I prefer doing stuff without additional plugins but I need to defend such a decision all the time. Therefore I believe it would be much easier for Adobe to attract their developer base to use the molehill extension then to find people who will go for WebGL. Yes I know there is no flash on iOS but there is no WebGL either (not even a public roadmap as far as I know). PS: Silverlight will get a 3D extension, too. ________________________________________ Von: owner-public_webgl...@ [owner-public_webgl...@] im Auftrag von steve...@ [steve...@] Gesendet: Donnerstag, 7. April 2011 18:20 An: Behan, Michael Cc: 'public_webgl...@' Betreff: Re: [Public WebGL] WebGL compare&contrast with Adobe Molehill APIs? There doesn't seem to be much information out there. What I know is this: * Molehill is Adobe's effort to add proper 3D graphics to Flash. * The actual ActionScript API is very similar to WebGL. That's inevitable because it's built on top of the same infrastructure...OpenGL and Direct3D. * The most significant (and deeply horrible) difference is that they decided to invent their own machine-code level language for writing shaders rather than using GLSL/Cg/HLSL!! I can't imagine why they did that...but that's what I'm seeing. With any luck it will "just die already"...but who knows? -- Steve > Howdy folks! > > I am pinging you all to find out if anyone knows of an existing compare & > contrast of WebGL and the Molehill APIs by Adobe? > > Thanks a lot > > Michael Behan | web developer iii > [cid:image001.jpg...@] > mobile: 407-928-0109; aim/yahoo: michaelwdpro > Michael.Behan...@ > > This message is confidential and contains information that is proprietary > to The Walt Disney Company or its affiliates. > > > ----------------------------------------------------------- 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 sho...@ Thu Apr 7 14:33:14 2011 From: sho...@ (Shy Shalom) Date: Fri, 8 Apr 2011 00:33:14 +0300 Subject: [Public WebGL] WebGL on TechCrunch Message-ID: My WebGL game was recently featured in TechCrunch http://techcrunch.com/2011/04/06/who-needs-flash-new-webgl-and-html5-browser-game-sets-trons-light-cycles-in-3d/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29 I wouldn't be posting this here though if not for the rather interesting discussion that follows about the future of WebGL, Flash and 3D on the Web. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic...@ Thu Apr 7 15:32:11 2011 From: nic...@ (Nicolas Kassis) Date: Thu, 7 Apr 2011 18:32:11 -0400 Subject: [Public WebGL] WebGL on TechCrunch In-Reply-To: References: Message-ID: On Thu, Apr 7, 2011 at 5:33 PM, Shy Shalom wrote: > My WebGL game was recently featured in TechCrunch > > http://techcrunch.com/2011/04/06/who-needs-flash-new-webgl-and-html5-browser-game-sets-trons-light-cycles-in-3d/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29 > > I wouldn't be posting this here though if not for the rather interesting > discussion that follows about the future of WebGL, Flash and 3D on the Web. > Congratulation on the publicity. I have to say I've spent a lot of time playing your game. The warped shape is pretty challenging ;p Thanks -- ----------------- Nicolas Kassis ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Thu Apr 7 19:46:35 2011 From: ste...@ (stephen white) Date: Fri, 8 Apr 2011 12:16:35 +0930 Subject: [Public WebGL] WebGL compare&contrast with Adobe Molehill APIs? In-Reply-To: References: <8C64D7E6B45E094F9377065955DE0D9B1F1253A2F3@SM-FLOR-VXMB06B.wdw.disney.com> Message-ID: <5A5404F2-2063-44C3-87EE-EC0CF90F3E0E@adam.com.au> On 08/04/2011, at 1:50 AM, steve...@ wrote: > * The most significant (and deeply horrible) difference is that they > decided to invent their own machine-code level language for writing This was to work around the DirectX vs OpenGL problem that WebGL is tackling with ANGLE. It's worth noting that Apple also went to machine code for Motion: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter25.html > With any luck it will "just die already"...but who knows? No chance of that. I believe that Molehill will take 3D in IE, while WebGL will take 3D on mobile. I would also comment that Molehill is getting significantly better results, probably due to compiling with type information whereas it's harder to extract performance from JS. I'm resigned to having to write my graphics code twice in this brave new world. Hopefully Silverlight will be the one that dies. -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From vje...@ Fri Apr 8 03:52:35 2011 From: vje...@ (Christopher Chedeau - Vjeux) Date: Fri, 8 Apr 2011 12:52:35 +0200 Subject: [Public WebGL] DataView suggestions Message-ID: Hello, I have been working on a lib that provides DataView API for all the browsers (it uses the best feature available from String, Typed Array or DataView) called jDataView: https://github.com/vjeux/jsDataView/ While working on this library, I found that the current API was not really practical to use. Adding those few points would make the handling of binary data more enjoyable. 1) Addition of littleEndian to the constructor A binary file is either in littleEndian or bigEndian form. It is therefore really annoying to have to define the endianness everytime you read a value. This is even more annoying since the default value is bigEndian whereas most files nowadays are in littleEndian. To solve this, we can add a parameter littleEndian to the DataView constructor. When you read/write and the littleEndian value is undefined, this is the value from the constructor that is being used. I would also set bigEndian by default. 2) File cursor Most of the time you read a file sequentially. With the current API, you have to keep a cursor of where you are at and this is extremely annoying. You would like to write var a = view.getInt8(); var b = view.getFloat32(); Instead you have to write var cursor = 0; var a = view.getInt8(cursor); cursor += 1; var b = view.getFloat32(cursor); cursor += 4; DataView could have an internal cursor initialized to 0 at creation. Every time you make a read/write, it would be set to the end of what has been read/written. byteOffset will be set to the cursor position. if undefined. In order to manipulate the cursor, we would have two functions: seek(byteOffset) and tell() 3) getChar and getString Often, binary files also contain characters and strings. With the current API, this is extremely annoying to read those types of values. I suggest to add 4 new functions: getChar(byteOffset) getString(length, byteOffset) setChar(byteOffset, char) setString(byteOffset, string, optional length) One issue I see is encoding. I believe that strings in binary files are often in ASCII while Javascript strings are UTF-8. I hope that these suggestions will help to make the DataView API more user friendly. It is important to have a good support for binary files if we want to make browser Javascript future-proof! :) -- Christopher CHEDEAU - Vjeux EPITA - LRDE - Ing2 2012 Curse.com Web Developer http://blog.vjeux.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Sat Apr 9 10:38:37 2011 From: gle...@ (Glenn Maynard) Date: Sat, 9 Apr 2011 13:38:37 -0400 Subject: [Public WebGL] getContext error handling Message-ID: The error handling for canvas.getContext("webgl") is inconsistent with other web APIs. Synchronous APIs, like FileReaderSync and IDBDatabaseSync, report errors by throwing exceptions with error information. Asynchronous APIs, like FileReader and IDBDatabase, report errors by firing an event. getContext is a synchronous API, but WebGL is reporting errors using the event mechanism used by asynchronous APIs. It should be throwing an exception instead. A related issue: the description of webglcontextcreationerror is vague. It says "Later, at the normal event delivery time". Events can be dispatched either in the event loop (async exceptions) or immediately (sync exceptions); there's no such thing as the "normal event delivery time". It sounds like this was written under the assumption that all events are asynchronous. HTML's terminology for this is concise and precise: "fire a simple event" to fire an event immediately, and "queue a task to fire a simple event" to fire an event later from the event loop. If it's too late to replace webglcontextcreationerror with an exception, note that this event should be fired synchronously, not asynchronously, so it's possible to retrieve error information as a result of a getContext call immediately. For example: var error = ""; var retrieveError = function(e) { error = e.statusMessage || "unknown error"; }; canvas.addEventListener("webglcontextcreationerror", retrieveError, false); var ctx = canvas.getContext("experimental-webgl"); canvas.removeEventListener("webglcontextcreationerror", retrieveError, false); if(!ctx) alert("WebGL error: " + error); Note that this event is already synchronous in Chrome, so the above code already works there. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ced...@ Sat Apr 9 16:09:34 2011 From: ced...@ (Cedric Vivier) Date: Sat, 9 Apr 2011 16:09:34 -0700 Subject: [Public WebGL] getContext error handling In-Reply-To: References: Message-ID: Hey Glenn, We discussed this in the thread "Firefox 4 and blacklist reporting". Indeed the current paragraph on webglcontextcreationerror is just plain confusing and not describing what's happening in reality from a JavaScript developer perspective. I proposed to replace the paragraph with : " This event is dispatched from the HTMLCanvasElement by getContext() when an error occurs during that call. The event allows to collect details about the failure that will result in getContext() returning null. " Makes it much clearer imo, consistent with how it should be/is usually implemented, and compatible with the snippet of code you posted that gives details about the error (I posted another similar snippet in the thread aforementioned). If there's no objection, I'll replace the paragraph with proposal above in the spec. Regards, On Sat, Apr 9, 2011 at 10:38, Glenn Maynard wrote: > The error handling for canvas.getContext("webgl") is inconsistent with other > web APIs.? Synchronous APIs, like FileReaderSync and IDBDatabaseSync, report > errors by throwing exceptions with error information.? Asynchronous APIs, > like FileReader and IDBDatabase, report errors by firing an event. > getContext is a synchronous API, but WebGL is reporting errors using the > event mechanism used by asynchronous APIs.? It should be throwing an > exception instead. > > A related issue: the description of webglcontextcreationerror is vague.? It > says "Later, at the normal event delivery time".? Events can be dispatched > either in the event loop (async exceptions) or immediately (sync > exceptions); there's no such thing as the "normal event delivery time".? It > sounds like this was written under the assumption that all events are > asynchronous.? HTML's terminology for this is concise and precise: "fire a > simple event" to fire an event immediately, and "queue a task to fire a > simple event" to fire an event later from the event loop. > > If it's too late to replace webglcontextcreationerror with an exception, > note that this event should be fired synchronously, not asynchronously, so > it's possible to retrieve error information as a result of a getContext call > immediately.? For example: > > ??? var error = ""; > ??? var retrieveError = function(e) {? error = e.statusMessage || "unknown > error"; }; > ??? canvas.addEventListener("webglcontextcreationerror", retrieveError, > false); > ??? var ctx = canvas.getContext("experimental-webgl"); > ??? canvas.removeEventListener("webglcontextcreationerror", retrieveError, > false); > ??? if(!ctx) > ??? ??? alert("WebGL error: " + error); > > Note that this event is already synchronous in Chrome, so the above code > already works there. > > -- > Glenn Maynard > > ----------------------------------------------------------- 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 gle...@ Sat Apr 9 18:25:11 2011 From: gle...@ (Glenn Maynard) Date: Sat, 9 Apr 2011 21:25:11 -0400 Subject: [Public WebGL] getContext error handling In-Reply-To: References: Message-ID: On Sat, Apr 9, 2011 at 7:09 PM, Cedric Vivier wrote: > We discussed this in the thread "Firefox 4 and blacklist reporting". > Indeed the current paragraph on webglcontextcreationerror is just > plain confusing and not describing what's happening in reality from a > JavaScript developer perspective. > > I proposed to replace the paragraph with : > " > This event is dispatched from the HTMLCanvasElement by getContext() > when an error occurs during that call. > The event allows to collect details about the failure that will result > in getContext() returning null. > " > I think it would be clearer if described as part of "2.1 The canvas Element". There are a couple other things I notice in that section. - It says "when called for the first time", which raises the question: what happens if the first call fails and you call it again? It might succeed a second time, for example if hardware resources have since become available; the spec is unclear about this case. (For example, if the first call fails, the WebGLContextAttributes passed to a subsequent call should probably *not* be ignored.) - It doesn't say that null is returned on error. That's way down in webglcontextcreationerror, which is an odd place to specify getContext behavior. - The "first call/subsequent calls" logic should be unnecessary now: that behavior is specified by the Canvas element[1]. Also, it's not specified whether webglcontextcreationerror bubbles or is cancelable. For what it's worth, this is how I'd describe it: > 2.1 The canvas Element > > When the getContext method of a canvas [CANVAS]element is to return a new object[2] for the *contextId* webgl, the user agent must run the following steps: > > 1. Create a new WebGLRenderingContext object and associated drawing buffer. > 2. If an error is encountered creating these objects, fire a simple event named "webglcontextcreationerror" at the canvas element, clear the primary context of the canvas, return null and terminate these steps. > 3. Return the WebGLRenderingContext. This aligns with the wording used by the getContext ([3]) and 2d canvas[4]. It omits all mention of "first" and "subsequent calls", since canvas.getContext already describes that case. HTML defines "fire a simple event"[5], which also specifies that the event does not bubble and is not cancelable. The "clear the primary context" part in step 2 shouldn't be necessary; the getContext algorithm in the HTML should specify this. I'll mail whatwg asking about this, since getContext seems to assume that "Return a new object for contextId" can never fail. [1] http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext [2] http://dev.w3.org/html5/spec/the-canvas-element.html#getcontext-return [3] http://dev.w3.org/html5/spec/the-canvas-element.html#primary-context [4] http://dev.w3.org/html5/2dcontext/#conformance-requirements [5] http://dev.w3.org/html5/pf-summary/browsers.html#fire-a-simple-event -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Sat Apr 9 18:42:51 2011 From: jda...@ (John Davis) Date: Sat, 9 Apr 2011 20:42:51 -0500 Subject: [Public WebGL] Re: [angleproject] Re: Solving slow compilation of long loops with texture sampling In-Reply-To: <8EEAA56B-6473-44D4-AC5E-204A95776C76@transgaming.com> References: <4D930F5A.70600@vicomtech.org> <1ee1e094-4709-4c0c-8ffe-a4f787d8e734@32g2000vbe.googlegroups.com> <8EEAA56B-6473-44D4-AC5E-204A95776C76@transgaming.com> Message-ID: Did we ever find a solution for texture lookups in loops causing slow compile times? On Thu, Mar 31, 2011 at 9:39 AM, Daniel Koch wrote: > > On 2011-03-30, at 6:21 PM, Alvaro Segura wrote: > > You are right. That's why we propose to find a way to apply a smart > selective change. > > Let me state the problem in a different way: > > We are not talking about saving several seconds as in the flight.html > demo. In fact, we faced this problem more severely. Our application, > with moderate iteration settings takes more than 1 minute trying to > compile (with a few "your script is taking too long" alerts) and > finally fails. I don't have the numbers here, I think we have to hit > "stop script" after minutes. > > > What happens if you reduce the optimization level? > > Currently Chrome builds of ANGLE use D3DCOMPILE_OPTIMIZATION_LEVEL0, but > stand-alone builds will default to > D3DCOMPILE_OPTIMIZATION_LEVEL3. > If you are doing your own ANGLE build try modifying this at: > > http://code.google.com/p/angleproject/source/browse/trunk/src/libGLESv2/Program.cpp#19 > > Our fix makes compilation possible, and in only a couple seconds, the > same as native GLSL. Rendering itself is acceptably fast after that > for such a shader. > > So, yes, a rule has to be chosen to apply the tex2Dlod() trick only > when necessary that does not break the rest of cases. Some > suggestions: > > - texture reads inside loops > - texture reads inside loops longer than N iterations (N=10?) > - texture reads inside loops when the texture has a MIN_FILTER=LINEAR > or NEAREST, ... > > That last idea might be the safest. Is it possible in Angle to know > the texture filtering mode? (texParameteri TEXTURE_MIN_FILTER) If the > mode for the relevant texture is LINEAR or NEAREST (not _MIPMAP_) then > using tex2Dlod is just fine, right? > > > The libGLESv2 part of ANGLE knows the filtering mode, but the shader > compiler currently has no knowledge of it. > Adding something like this option would introduce a state dependency > between the shaders and textures/texture state. > This would required checking these dependencies every draw call or when a > texture state changed and potentially recompiling the shader (resulting in > even more delays!). Introducing state dependencies into the shaders is > definitely something we hope to avoid. > > Thanks for your attention. > > Best regards, > > Alvaro > > > > On 30 mar, 22:43, Daniel Koch wrote: > > On 2011-03-30, at 7:09 AM, Alvaro Segura wrote: > > > > > Hi All, > > > This post complements our previous post "[angleproject] Solving slow > compilation (and eventual fail) in complex shaders (with patch)" with a > related but different problem. Previously we discussed a solution for slow > compilation of long loops by preventing their unrolling. It has been said > that Chrome 12 will compile shaders without unrolling to improve this. We > have tested Chrome 12 and certainly improves fractal.io as much as our > solution with "[loop] [fastopt] for (...)". > > > Now, there are other cases, such as that reported by John Davis ( > http://www.pcprogramming.com/flight.html), and others, where loops > need to do texture sampling (i.e. texture2D(tex, uv); ). > > > The problem here seems to be the following or a similar issue: texture2D() > translates to tex2D() in HLSL. tex2D is said to be a "gradient instruction" > because it uses mipmapping (even if we defined MIN_FILTER LINEAR!). HLSL > does not allow gradient instructions in true loops (at least in loops with > "break" which I can't find is that demo (?)), so upon seeing that call, DX > forces an unrolling, even if Chrome 12 is trying to avoid that. The result > is a very long compile time and a possible error if the loop is too deep and > can't be unrolled. > > > In HLSL mipmapping can be avoided by using tex2Dlod(tex, uv, 0, 0) [the 0s > being the levels chosen]. Great. Is there a similar function in GLSL? yes: > texture2DLod(). Can the shader developer just change it? No: GLSL only > allows texture2DLod() in vertex shaders, not fragment shaders. > > > A solution implies Angle emitting a HLSL "tex2Dlod(...,0,0)" instruction > from a source GLSL "texture2D(...)". We tested this, again in a custom-built > Angle library. And it worked great for our application which does heavy > texture sampling inside long loops. > > > Can that translation be done always as in our naive fix? Not really. There > are plenty of applications that need correct mipmapped sampling for good > minification of textures. The translation then needs to be done selectively, > only where necessary. The rule can be to check whether the texture2D call is > inside a loop or when inside a loop of more than N iterations. [the first > seems easier to do]: > > > texture2D(a,b); out of loop => tex2D(a,b); > > texture2D(a,b); inside loop => tex2Dlod(a, b, 0, 0); > > > That doesn't really seem like it would be a safe universal change though... > > > > > We propose this change or equivalent fixes as we definitely need sampling > in loops, following the necessary testing so it does not break anything. > Pure OpenGL works with no problems, BTW. > > > For reference, we are using Angle SVN trunk (rev 598), compiled under > VS2008 and then, replacing resulting DLL in FF4. I have upgraded MS SDK > Platform and DX SDK to the latest one, having a Win7 64bits PC with a nVidia > GTX485. BTW, what is different in Chrome 12? doesn't it use regular > SVN-trunk Angle? > > > Chrome 12 does use regular SVN-trunk ANGLE (as far as I know), however it > uses a different build system (GYP) that has some different defines. > Seehttp://code.google.com/p/angleproject/source/browse/trunk/src/build_a...forthe relevant settings. > > > Hope this helps, > > Daniel > > > --- > > Daniel Koch -+- dan......@ > > Senior Graphics Architect -+- TransGaming Inc. -+-www.transgaming.com > > > --- > Daniel Koch -+- daniel...@ > Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ced...@ Sat Apr 9 19:17:25 2011 From: ced...@ (Cedric Vivier) Date: Sat, 9 Apr 2011 19:17:25 -0700 Subject: [Public WebGL] getContext error handling In-Reply-To: References: Message-ID: On Sat, Apr 9, 2011 at 18:25, Glenn Maynard wrote: > For what it's worth, this is how I'd describe it: > >> 2.1 The canvas Element >> >> When the getContext method of a canvas [CANVAS] element is to return a new >> object[2] for the contextId webgl, the user agent must run the following >> steps: >> >> 1. Create a new WebGLRenderingContext object and associated drawing >> buffer. >> 2. If an error is encountered creating these objects, fire a simple event >> named "webglcontextcreationerror" at the canvas element, clear the primary >> context of the canvas, return null and terminate these steps. >> 3. Return the WebGLRenderingContext. > > This aligns with the wording used by the getContext ([3]) and 2d canvas[4]. > It omits all mention of "first" and "subsequent calls", since > canvas.getContext already describes that case.? HTML defines "fire a simple > event"[5], which also specifies that the event does not bubble and is not > cancelable. Nice, this makes even more sense to describe it here indeed. We should take this opportunity to define all WebGL events as simple events as well. > The "clear the primary context" part in step 2 shouldn't be necessary; the > getContext algorithm in the HTML should specify this. I think it is indeed unnecessary and already specified at [1]. WebGL's getContext behavior described above would be the step 6 of canvas's getContext [1], therefore according to step 3 of [1] it is not possible to get to WebGL's getContext when there is already a primary context. > I'll email whatwg asking about this, since getContext seems to assume that "Return a new > object for contextId" can never fail. IMHO there is no such assumption and returning null is valid since step 6 specifically refers to the requested context's specification : "Return a new object for contextId, as defined by the specification given for contextId's entry in the WHATWG Wiki CanvasContexts page." However this might make sense to require for null rather than an exception with any context when an error occurred at creation. [1] : http://www.w3.org/TR/html5/the-canvas-element.html#dom-canvas-getcontext Regards, ----------------------------------------------------------- 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 gle...@ Sat Apr 9 19:33:40 2011 From: gle...@ (Glenn Maynard) Date: Sat, 9 Apr 2011 22:33:40 -0400 Subject: [Public WebGL] getContext error handling In-Reply-To: References: Message-ID: On Sat, Apr 9, 2011 at 10:17 PM, Cedric Vivier wrote: > Nice, this makes even more sense to describe it here indeed. > We should take this opportunity to define all WebGL events as simple > events as well. > That's how the newer specs handle these events: they're described as steps in the algorithms they're generated by, instead of described on their own. IMO, this makes things much clearer. > The "clear the primary context" part in step 2 shouldn't be necessary; > the > > getContext algorithm in the HTML should specify this. > > I think it is indeed unnecessary and already specified at [1]. > WebGL's getContext behavior described above would be the step 6 of > canvas's getContext [1], therefore according to step 3 of [1] it is > not possible to get to WebGL's getContext when there is already a > primary context. > The problem is when null is returned--it should be possible to try again. Currently per spec, if getContext returns null once, step 5 will always return null. FYI, I still think getContext should throw an error if an error happens. Using a message like this is unusual. There's no provision in the HTML getContext spec for this, though. I'll go ask on whatwg. However this might make sense to require for null rather than an > exception with any context when an error occurred at creation. > Sorry, I don't understand. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ced...@ Sat Apr 9 20:26:24 2011 From: ced...@ (Cedric Vivier) Date: Sat, 9 Apr 2011 20:26:24 -0700 Subject: [Public WebGL] getContext error handling In-Reply-To: References: Message-ID: On Sat, Apr 9, 2011 at 19:33, Glenn Maynard wrote: > FYI, I still think getContext should throw an error if an error happens. > Using a message like this is unusual.? There's no provision in the HTML > getContext spec for this, though.? I'll go ask on whatwg. > IIRC another reason we used an event is to allow the application to be notified when context restoration failed (see webglcontextlost event). Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Mon Apr 11 03:49:57 2011 From: jda...@ (John Davis) Date: Mon, 11 Apr 2011 05:49:57 -0500 Subject: [Public WebGL] Long shader compiles Message-ID: For those of us using noise and fractal techniques, it's very easy to create a shader compile which will exceed the timeout in the browser. I think we might need support for async shader compiles. This would enable us to keep the UI responsive with a simple splash screen shader while other shaders are being built in the background. The main thing is to keep the screen from locking up when a long shader compile is needed. http://fractal.io/ is an excellent example. While my shaders don't take quite as long, I'm hitting the 10-15s duration with shader compiles. Given that we don't appear to have a simple workaround on the compile side (ie turning off loop unrolling, etc), I think our only option is adding async compiles. JD -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Apr 11 04:26:09 2011 From: jda...@ (John Davis) Date: Mon, 11 Apr 2011 06:26:09 -0500 Subject: [Public WebGL] Re: Long shader compiles In-Reply-To: References: Message-ID: Can shader compiles be run on a web worker? And prevent the browser timeout messagebox? On Mon, Apr 11, 2011 at 5:49 AM, John Davis wrote: > For those of us using noise and fractal techniques, it's very easy to > create a shader compile which will exceed the timeout in the browser. I > think we might need support for async shader compiles. This would enable us > to keep the UI responsive with a simple splash screen shader while other > shaders are being built in the background. The main thing is to keep the > screen from locking up when a long shader compile is needed. > > http://fractal.io/ is an excellent example. While my shaders don't take > quite as long, I'm hitting the 10-15s duration with shader compiles. > > Given that we don't appear to have a simple workaround on the compile side > (ie turning off loop unrolling, etc), I think our only option is adding > async compiles. > > JD > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asm...@ Mon Apr 11 04:45:22 2011 From: asm...@ (Asmi Shah) Date: Mon, 11 Apr 2011 13:45:22 +0200 Subject: [Public WebGL] volume rendering of biological microscopic Image dataset Message-ID: Hey All, I have a requirement of rendering 3D volume on web which should also be interactive. Say, I have 120 2D microscopic images of a specimen, with different points in z-planes.. Now I want to have a 3d Visualization of this image dataset on web. Is it somehow already possible with WebGL? working on real data and not some model? Any help is highly appreciated. Thanks a lot in advance. Looking forward to your answers. -- Regards, Asmi Shah -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr....@ Mon Apr 11 05:25:05 2011 From: mr....@ (Daniel Aquino) Date: Mon, 11 Apr 2011 08:25:05 -0400 Subject: [Public WebGL] volume rendering of biological microscopic Image dataset In-Reply-To: References: Message-ID: Have you looked at any of the webgl demo's ? On Mon, Apr 11, 2011 at 7:45 AM, Asmi Shah wrote: > Hey All, > > I have a requirement of rendering 3D volume on web which should also be > interactive. Say, I have 120 2D microscopic images of a specimen, with > different points in z-planes.. Now I want to have a 3d Visualization of this > image dataset on web. Is it somehow already possible with WebGL? working on > real data and not some model? > > Any help is highly appreciated. Thanks a lot in advance. Looking forward to > your answers. > > -- > Regards, > Asmi Shah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jco...@ Mon Apr 11 05:34:58 2011 From: jco...@ (John Congote) Date: Mon, 11 Apr 2011 14:34:58 +0200 Subject: [Public WebGL] volume rendering of biological microscopic Image dataset In-Reply-To: References: Message-ID: Hello Asmi May be this example help you. http://demos.vicomtech.org/volren/ If you need more information you can contact me. Bye. 2011/4/11 Asmi Shah : > Hey All, > I have a requirement of rendering 3D volume on web which should also be > interactive. Say, I have 120 ?2D microscopic images of a specimen, with > different points in z-planes.. Now I?want?to have a 3d?Visualization?of this > image dataset on web. Is it somehow already possible with WebGL? working on > real data and not some model? > Any help is highly appreciated. Thanks a lot in advance. Looking forward to > your answers. > -- > Regards, > Asmi Shah > -- M.Sc. John Edgar Congote Calle Sistemas de transporte inteligentes e Ingenier?a / Intelligent Transport Systems and Engineering Vicomtech-IK4 - Visual Interaction Communication Technologies Mikeletegi Pasealekua, 57 - Parque Tecnol?gico 20009 Donostia - San Sebasti?n - Spain Tel: +[34] 943 30 92 30 Fax: +[34] 943 30 93 93 e-mail: jcongote...@ www.vicomtech.org *** member of IK4 Research Alliance **** www.ik4.es *** member of GraphicsMedia.net **** www.graphicsmedia.net ----------------------------------------------------- Vicomtech-IK4 is an ISO 9001:2000 certified institute ----------------------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. La informaci?n incluida en el presente correo es confidencial sometida a secreto profesional, especialmente en lo que respecta a los datos de car?cter personal, cuya divulgaci?n est? prohibida, en virtud de la legislaci?n vigente. Si usted no es el destinatario leg?timo y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo. En todo caso abstengase de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje as? como los ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. Cualquier opini?n contenida en este correo es exclusiva de su autor y no representa necesariamente la opini?n de ASOCIACI?N CENTRO DE TECNOLOG?AS DE INTERACCI?N VISUAL Y COMUNICACIONES VICOMTECH (en adelante Vicomtech-IK4) El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. Con motivo de la entrada en vigor de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Informaci?n y de Comercio Electr?nico, le informamos que pueden revocar en cualquier momento, de forma sencilla y gratuita, el consentimiento para la recepci?n de mensajes de vicomtech.org en info.lopd...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tu...@ Mon Apr 11 05:43:44 2011 From: tu...@ (Thatcher Ulrich) Date: Mon, 11 Apr 2011 14:43:44 +0200 Subject: [Public WebGL] volume rendering of biological microscopic Image dataset In-Reply-To: References: Message-ID: This link was just published 10 days ago on this list by John Congote; see archives for the original message. http://demos.vicomtech.org/volren/ -T On Mon, Apr 11, 2011 at 2:25 PM, Daniel Aquino wrote: > Have you looked at any of the webgl demo's ? > > > On Mon, Apr 11, 2011 at 7:45 AM, Asmi Shah wrote: >> >> Hey All, >> I have a requirement of rendering 3D volume on web which should also be >> interactive. Say, I have 120 ?2D microscopic images of a specimen, with >> different points in z-planes.. Now I?want?to have a 3d?Visualization?of this >> image dataset on web. Is it somehow already possible with WebGL? working on >> real data and not some model? >> Any help is highly appreciated. Thanks a lot in advance. Looking forward >> to your answers. >> -- >> Regards, >> Asmi Shah > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Apr 11 13:20:16 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 11 Apr 2011 13:20:16 -0700 Subject: [Public WebGL] Re: Long shader compiles In-Reply-To: References: Message-ID: On what platform or platforms, and with what browser and browser version, are you seeing the long shader compile times? At the current time there is a known issue with long compile times, caused by the D3DX shader compiler, on Windows in Chrome when using ANGLE. You ought to be able to confirm whether this is the problem by seeing whether the command line option --use-gl=desktop causes the problem to go away. One fix is in the pipeline and should be present in Chrome 12. Personally I would rather try to fix these pathologically long shader compile times than introduce a WebGL extension for asynchronous shader compilation. -Ken On Mon, Apr 11, 2011 at 4:26 AM, John Davis wrote: > Can shader compiles be run on a web worker? ?And prevent the browser timeout > messagebox? > > On Mon, Apr 11, 2011 at 5:49 AM, John Davis > wrote: >> >> For those of us using noise and fractal techniques, it's very easy to >> create a shader compile which will exceed the timeout in the browser. ?I >> think we might need support for async shader compiles. ?This would enable us >> to keep the UI responsive with a simple splash screen shader while other >> shaders are being built in the background. ?The main thing is to keep the >> screen from locking up when a long shader compile is needed. >> http://fractal.io/?is an excellent example. ?While my shaders don't take >> quite as long, I'm hitting the 10-15s duration with shader compiles. >> Given that we don't appear to have a simple workaround on the compile side >> (ie turning off loop unrolling, etc), I think our only option is adding >> async compiles. >> >> JD > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Mon Apr 11 17:58:06 2011 From: jda...@ (John Davis) Date: Mon, 11 Apr 2011 19:58:06 -0500 Subject: [Public WebGL] Re: Long shader compiles In-Reply-To: References: Message-ID: Win7, Chrome 10.0.648.204, Angle What was the fix? With complex shaders, I'm not sure there is any getting away from this one. A friend of mine told me that at Lucas Arts it would take ~12hrs to build the optimized shaders for xbox. As long as the DirectX optimizer is on, I'm afraid we'll have this issue. On Mon, Apr 11, 2011 at 3:20 PM, Kenneth Russell wrote: > On what platform or platforms, and with what browser and browser > version, are you seeing the long shader compile times? > > At the current time there is a known issue with long compile times, > caused by the D3DX shader compiler, on Windows in Chrome when using > ANGLE. You ought to be able to confirm whether this is the problem by > seeing whether the command line option --use-gl=desktop causes the > problem to go away. One fix is in the pipeline and should be present > in Chrome 12. > > Personally I would rather try to fix these pathologically long shader > compile times than introduce a WebGL extension for asynchronous shader > compilation. > > -Ken > > On Mon, Apr 11, 2011 at 4:26 AM, John Davis > wrote: > > Can shader compiles be run on a web worker? And prevent the browser > timeout > > messagebox? > > > > On Mon, Apr 11, 2011 at 5:49 AM, John Davis > > wrote: > >> > >> For those of us using noise and fractal techniques, it's very easy to > >> create a shader compile which will exceed the timeout in the browser. I > >> think we might need support for async shader compiles. This would > enable us > >> to keep the UI responsive with a simple splash screen shader while other > >> shaders are being built in the background. The main thing is to keep > the > >> screen from locking up when a long shader compile is needed. > >> http://fractal.io/ is an excellent example. While my shaders don't > take > >> quite as long, I'm hitting the 10-15s duration with shader compiles. > >> Given that we don't appear to have a simple workaround on the compile > side > >> (ie turning off loop unrolling, etc), I think our only option is adding > >> async compiles. > >> > >> JD > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Mon Apr 11 18:40:43 2011 From: ste...@ (Steve Baker) Date: Mon, 11 Apr 2011 20:40:43 -0500 Subject: [Public WebGL] Re: Long shader compiles In-Reply-To: References: Message-ID: <4DA3AD9B.8080109@sjbaker.org> On 04/11/2011 07:58 PM, John Davis wrote: > Win7, Chrome 10.0.648.204, Angle > > What was the fix? With complex shaders, I'm not sure there is any > getting away from this one. A friend of mine told me that at Lucas > Arts it would take ~12hrs to build the optimized shaders for xbox. As > long as the DirectX optimizer is on, I'm afraid we'll have this issue. On a large-scale game title, there will be many hundreds of shaders - each one compiled half a dozen different ways for depth pass, beauty pass, shadow pass, etc. When we were doing cross-platform work on an "open city" game using the UnrealEngine, we built for Xbox, PC and PS-3 platforms at once - it could take 20 minutes to an hour do the lot. 12 hours seems like an awful lot...but it's not utterly impossible. However, it's unlikely that a game written in JavaScript and downloaded over the web is going to come close to that degree of complexity. There is a fundamental problem though - the only way to cope with games of that complexity is to store shaders in a pre-compiled form - but AFAIK, that's not supported in OpenGL-ES or even desktop OpenGL. So no matter whether the time is 12 hours or 12 minutes (or even 1 minute), you just hit a technological limit. You just can't build things that complicated. However, for relatively small games that don't take a week to download over HTTP and stand a chance of running on things like netbooks and pads - you just have to lower your sights and shoot for something a little less grandiose. Heck, the game market is heading in the $1.99 end of the scale anyway - you're not going to be able to fund a multi-million dollar development that way. The kind of game that produces enough shaders to require more than a few seconds to compile is the kind of game that consumes the efforts of 100 artists and another 100 programmers and designers for several years and sells for $60 in WalMart. That's not the kind of thing you use WebGL for. We're talking "Angry Birds" and "Farmville" - not "Halo" and "GTA IV". A handful of shaders in a couple of versions. We should try to understand why looped texture lookups are unreasonably slow - but I don't think that's a major concern. Just unwrap the loop yourself for chrissakes. -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Apr 11 19:18:35 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 11 Apr 2011 19:18:35 -0700 Subject: [Public WebGL] DataView suggestions In-Reply-To: References: Message-ID: Hi Christopher, Thanks for your feedback. Earlier versions of the DataView class were stateful, and contained a cursor for stream-like input. Discussion on the WebGL mailing list informed the current design. The basic idea is that a cursor can be easily implemented in a wrapper library in pure JavaScript. It isn't necessary for the DataView class to contain all of the functionality. The simpler the DataView class, the more likely it is that the entry points will be well optimized by the browser's JavaScript engines, which is important to get good file reading and writing performance. More responses inline. On Fri, Apr 8, 2011 at 3:52 AM, Christopher Chedeau - Vjeux wrote: > Hello, > I have been working on a lib that provides DataView API for all the browsers > (it uses the best feature available from String, Typed Array or DataView) > called jDataView:?https://github.com/vjeux/jsDataView/ > While working on this library, I found that the current API was not really > practical to use. Adding those few points would make the handling of binary > data more enjoyable. > > 1) Addition of littleEndian to the constructor > A binary file is either in littleEndian or bigEndian form. It is therefore > really annoying to have to define the endianness everytime you read a value. > This is even more annoying since the default value is bigEndian whereas most > files nowadays are in littleEndian. > To solve this, we can add a parameter littleEndian to the DataView > constructor. When you read/write and the littleEndian value is undefined, > this is the value from the constructor that is being used. I would also set > bigEndian by default. I think that this sort of functionality belongs in a wrapper library. There's no reason to artificially limit a particular DataView instance to reading only big- or little-endian data. One could imagine a file format that contained both big- and little-endian values, though it would be convoluted. > 2) File cursor > Most of the time you read a file sequentially. With the current API, you > have to keep a cursor of where you are at and this is extremely annoying. > You would like to write > var a = view.getInt8(); > var b = view.getFloat32(); > Instead you have to write > var cursor = 0; > var a = view.getInt8(cursor); cursor += 1; > var b = view.getFloat32(cursor); cursor += 4; > DataView could have an internal cursor initialized to 0 at creation. Every > time you make a read/write, it would be set to the end of what has been > read/written. byteOffset will be set to the cursor position. if undefined. > In order to manipulate the cursor, we would have two functions: > seek(byteOffset) and tell() Per above, this was already considered and rejected. It can easily be implemented in a wrapper library. > 3) getChar and getString > Often, binary files also contain characters and strings. With the current > API, this is extremely annoying to read those types of values. > I suggest to add 4 new functions: > getChar(byteOffset) > getString(length, byteOffset) > setChar(byteOffset, char) > setString(byteOffset, string, optional length) > One issue I see is encoding. I believe that strings in binary files are > often in ASCII while Javascript strings are UTF-8. Better interoperability between the Typed Array API and JavaScript strings is definitely needed, and there have been discussions on this mailing list about how to achieve it. Unfortunately, so far there hasn't been a champion of this functionality to specify it. I am no expert in this area, but I have a feeling that the API needed for this functionality will be moderately sized. It seems clear that it will be necessary to support multiple character encodings. For these reasons, I think the best path forward would be to add a separate specification defining JavaScript string encoding and decoding into typed arrays and/or the DataView class. If you'd be willing to contribute to this effort that would be great. -Ken > I hope that these suggestions will help to make the DataView API more user > friendly. It is important to have a good support for binary files if we want > to make browser Javascript future-proof! :) > > -- > Christopher CHEDEAU - Vjeux > EPITA - LRDE - Ing2 2012 > Curse.com Web Developer > > http://blog.vjeux.com/ > ----------------------------------------------------------- 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 gle...@ Mon Apr 11 19:26:40 2011 From: gle...@ (Glenn Maynard) Date: Mon, 11 Apr 2011 22:26:40 -0400 Subject: [Public WebGL] Re: Long shader compiles In-Reply-To: <4DA3AD9B.8080109@sjbaker.org> References: <4DA3AD9B.8080109@sjbaker.org> Message-ID: (I thought I recognized your name. Apparently we had a short email exchange about something or other almost exactly a decade ago...) On Mon, Apr 11, 2011 at 9:40 PM, Steve Baker wrote: > However, for relatively small games that don't take a week to download > over HTTP and stand a chance of running on things like netbooks and pads > - you just have to lower your sights and shoot for something a little > less grandiose. With upcoming client-side storage APIs, it's going to be perfectly reasonable to have web-based games which have gigabytes of data, like many Steam games. I don't thnik "you're doing too much with WebGL, tone it down a little" is a good mindset. I hope WebGL limitations will be viewed with the goal of eventually addressing them as it becomes clearer what people want to use WebGL for, not accepting them as the ultimate limits of WebGL. For example, it would make a lot of sense to allow caching compiled shaders, as some PC games do; it's annoying but bearable if compilation takes a couple minutes, as long as you only have to do it once. If compile time is a limitation for developers, it would be worth exposing a shader cache extension in the future. If an async shader API is needed, that seems like the place to do it. (Not to suggest that it's time do that now, of course.) > We should try to understand why looped texture lookups are unreasonably > slow - but I don't think that's a major concern. ?Just unwrap the loop > yourself for chrissakes. It's good that there's a workaround, but I don't think "work around poor compiler performance by doing the compiler's job for it" is a good thing to encourage. -- Glenn Maynard ----------------------------------------------------------- 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 gle...@ Mon Apr 11 21:58:26 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 00:58:26 -0400 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement Message-ID: It currently doesn't appear possible to load a WebGLBuffer from an image, to use an image as vertex data. I can't do this manually, by writing the image to a 2d Canvas and passing its ImageData to bufferData, due to same-origin restrictions. WebGLBuffer's bufferData and bufferSubData APIs should support similar entry points as WebGLTexture.texImage2D, accepting HTMLImageElement, HTMLCanvasElement and HTMLVideoElement, for the same reasons: performance and dealing with same-origin restrictions. Of course, this would affect the origin-clean flag, just as with WebGLTexture. It would also be consistent to allow reading WebGLTextures into WebGLBuffer--another operation you can do natively--though its usefulness is limited by the present lack of floating-point texture support. -- Glenn Maynard ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Mon Apr 11 22:46:26 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 11 Apr 2011 22:46:26 -0700 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: References: Message-ID: You can download binary data through XHR though var req = new XMLHttpRequest(); req.open("GET", url, true); req.responseType = "arraybuffer"; req.onload = function() { var theArrayBuffer = req.response; var buf = gl.createBuffer(); gl.bindBuffer(gl.ARRAY_BUFFER, buf); gl.bufferData(gl.ARRAY_BUFFER, theArrayBuffer, gl.STATIC_DRAW); } req.send(); On Mon, Apr 11, 2011 at 9:58 PM, Glenn Maynard wrote: > > It currently doesn't appear possible to load a WebGLBuffer from an > image, to use an image as vertex data. I can't do this manually, by > writing the image to a 2d Canvas and passing its ImageData to > bufferData, due to same-origin restrictions. > > WebGLBuffer's bufferData and bufferSubData APIs should support similar > entry points as WebGLTexture.texImage2D, accepting HTMLImageElement, > HTMLCanvasElement and HTMLVideoElement, for the same reasons: > performance and dealing with same-origin restrictions. Of course, > this would affect the origin-clean flag, just as with WebGLTexture. > > It would also be consistent to allow reading WebGLTextures into > WebGLBuffer--another operation you can do natively--though its > usefulness is limited by the present lack of floating-point texture > support. > > -- > Glenn Maynard > ----------------------------------------------------------- > 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 gle...@ Mon Apr 11 23:17:01 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 02:17:01 -0400 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 1:46 AM, Gregg Tavares (wrk) wrote: > You can download binary data through XHR though > ?? ?var req = new XMLHttpRequest(); > ?? ?req.open("GET", url, true); > ?? ?req.responseType = "arraybuffer"; > ?? ?req.onload = function() { > ?? ? ?var theArrayBuffer = req.response; > ?? ? ?var buf = gl.createBuffer(); > ?? ? ?gl.bindBuffer(gl.ARRAY_BUFFER, buf); > ?? ? ?gl.bufferData(gl.ARRAY_BUFFER, theArrayBuffer, gl.STATIC_DRAW); > ?? ?} > ?? ?req.send(); That's useful for things like mesh data, but I don't think it helps with loading images. (You'll get back your compressed PNG, and depending on what you're doing, same-origin restrictions will also get in the way.) -- Glenn Maynard ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From emo...@ Tue Apr 12 00:52:10 2011 From: emo...@ (Erik Moller) Date: Tue, 12 Apr 2011 09:52:10 +0200 Subject: [Public WebGL] Re: Long shader compiles In-Reply-To: <4DA3AD9B.8080109@sjbaker.org> References: <4DA3AD9B.8080109@sjbaker.org> Message-ID: <4DA404AA.7010301@opera.com> On 4/12/11 3:40 AM, Steve Baker wrote: > On 04/11/2011 07:58 PM, John Davis wrote: >> Win7, Chrome 10.0.648.204, Angle >> >> What was the fix? With complex shaders, I'm not sure there is any >> getting away from this one. A friend of mine told me that at Lucas >> Arts it would take ~12hrs to build the optimized shaders for xbox. As >> long as the DirectX optimizer is on, I'm afraid we'll have this issue. > On a large-scale game title, there will be many hundreds of shaders - > each one compiled half a dozen different ways for depth pass, beauty > pass, shadow pass, etc. When we were doing cross-platform work on an > "open city" game using the UnrealEngine, we built for Xbox, PC and PS-3 > platforms at once - it could take 20 minutes to an hour do the lot. 12 > hours seems like an awful lot...but it's not utterly impossible. > > However, it's unlikely that a game written in JavaScript and downloaded > over the web is going to come close to that degree of complexity. > > There is a fundamental problem though - the only way to cope with games > of that complexity is to store shaders in a pre-compiled form - but > AFAIK, that's not supported in OpenGL-ES or even desktop OpenGL. So no > matter whether the time is 12 hours or 12 minutes (or even 1 minute), > you just hit a technological limit. You just can't build things that > complicated. > > However, for relatively small games that don't take a week to download > over HTTP and stand a chance of running on things like netbooks and pads > - you just have to lower your sights and shoot for something a little > less grandiose. Heck, the game market is heading in the $1.99 end of > the scale anyway - you're not going to be able to fund a multi-million > dollar development that way. The kind of game that produces enough > shaders to require more than a few seconds to compile is the kind of > game that consumes the efforts of 100 artists and another 100 > programmers and designers for several years and sells for $60 in > WalMart. That's not the kind of thing you use WebGL for. We're talking > "Angry Birds" and "Farmville" - not "Halo" and "GTA IV". A handful of > shaders in a couple of versions. I sure hope the bar for the WebGL use-case will be a bit higher than pushing clip space quads for 2d-games :) JIT is really starting to kick some ass and just the other day a colleague showed me some performance comparisons of a javascript implementation vs the same in C++ and the difference was less than a factor 10. What's a factor 10 slower than what we're running today? A P4? I'm expecting us to be blown away by what we'll see done in WebGL on "that P4" when the big game companies really get stuck into it. > We should try to understand why looped texture lookups are unreasonably > slow - but I don't think that's a major concern. Just unwrap the loop > yourself for chrissakes. > > -- Steve > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- -- Erik M?ller Core Developer Opera Software twitter.com/erikjmoller ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From vla...@ Tue Apr 12 01:45:40 2011 From: vla...@ (Vladimir Vukicevic) Date: Tue, 12 Apr 2011 08:45:40 +0000 (GMT) Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: Message-ID: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> It's a bit roundabout, but you can: - Load the image as an image - Draw it into an offscreen 2D of the same size - Use getImageData - Use the returned ImageData's data buffer with buffer[Sub]Data Requires an extra step with the canvas drawing (and associated extra memory usage), but should be possible. - Vlad ----- Original Message ----- > It currently doesn't appear possible to load a WebGLBuffer from an > image, to use an image as vertex data. I can't do this manually, by > writing the image to a 2d Canvas and passing its ImageData to > bufferData, due to same-origin restrictions. > > WebGLBuffer's bufferData and bufferSubData APIs should support similar > entry points as WebGLTexture.texImage2D, accepting HTMLImageElement, > HTMLCanvasElement and HTMLVideoElement, for the same reasons: > performance and dealing with same-origin restrictions. Of course, > this would affect the origin-clean flag, just as with WebGLTexture. > > It would also be consistent to allow reading WebGLTextures into > WebGLBuffer--another operation you can do natively--though its > usefulness is limited by the present lack of floating-point texture > support. > > -- Glenn Maynard > ----------------------------------------------------------- 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 ase...@ Tue Apr 12 02:05:50 2011 From: ase...@ (Alvaro Segura) Date: Tue, 12 Apr 2011 11:05:50 +0200 Subject: [Public WebGL] Progressive loading In-Reply-To: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> Message-ID: <4DA415EE.80601@vicomtech.org> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logovicomtech-ik4_150.png Type: image/png Size: 10808 bytes Desc: Visual Interaction Communication Technologies - IK4 Research Alliance URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: barraSinFondo_150.png Type: image/png Size: 2828 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ojo.png Type: image/png Size: 4363 bytes Desc: Visual Interaction Communication Technologies - IK4 Research Alliance URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: GraphicsMediaNet_150.png Type: image/png Size: 8191 bytes Desc: International Network for the Cooperation in Applied Research in Computer Graphics, Multimoda-Multimedia Technologies and Visual Interactive Digital Media Technologies URL: From sho...@ Tue Apr 12 04:41:55 2011 From: sho...@ (Shy Shalom) Date: Tue, 12 Apr 2011 14:41:55 +0300 Subject: [Public WebGL] Web Workers and ArrayBuffers? Message-ID: I'm trying to write a Worker thread that does some processing and creates a mesh on the fly. It works fine up until returning the created result to the main GUI thread. it seems that the communication between the worker and the main thread does JSON serialization, so if I'm sending a Float32Array from the worker, what I get in the main thread is a regular JavaScript array. A trivial solution is to just rebuild the Float32Array again from the array I receive but that seems wasteful. Is there a good workaround for this? Maybe a way to tell the JSON deserialization that something should be a Float32Array ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vje...@ Tue Apr 12 05:56:08 2011 From: vje...@ (Christopher Chedeau - Vjeux) Date: Tue, 12 Apr 2011 14:56:08 +0200 Subject: [Public WebGL] DataView suggestions In-Reply-To: References: Message-ID: Thanks for the answer. I did not know the target goals of the API design. You should probably write in the specifications that you intend the API to be as small as possible. Hence, that a Javascript wrapper on-top of it is required to have the best user experience using it. As for the string conversion, I can't promise anything. I am no expert at all on this subject. -- Christopher CHEDEAU - Vjeux EPITA - LRDE - Ing2 2012 Curse.com Web Developer http://blog.vjeux.com/ On Tue, Apr 12, 2011 at 4:18 AM, Kenneth Russell wrote: > Hi Christopher, > > Thanks for your feedback. > > Earlier versions of the DataView class were stateful, and contained a > cursor for stream-like input. Discussion on the WebGL mailing list > informed the current design. The basic idea is that a cursor can be > easily implemented in a wrapper library in pure JavaScript. It isn't > necessary for the DataView class to contain all of the functionality. > The simpler the DataView class, the more likely it is that the entry > points will be well optimized by the browser's JavaScript engines, > which is important to get good file reading and writing performance. > > More responses inline. > > On Fri, Apr 8, 2011 at 3:52 AM, Christopher Chedeau - Vjeux > wrote: > > Hello, > > I have been working on a lib that provides DataView API for all the > browsers > > (it uses the best feature available from String, Typed Array or DataView) > > called jDataView: https://github.com/vjeux/jsDataView/ > > While working on this library, I found that the current API was not > really > > practical to use. Adding those few points would make the handling of > binary > > data more enjoyable. > > > > 1) Addition of littleEndian to the constructor > > A binary file is either in littleEndian or bigEndian form. It is > therefore > > really annoying to have to define the endianness everytime you read a > value. > > This is even more annoying since the default value is bigEndian whereas > most > > files nowadays are in littleEndian. > > To solve this, we can add a parameter littleEndian to the DataView > > constructor. When you read/write and the littleEndian value is undefined, > > this is the value from the constructor that is being used. I would also > set > > bigEndian by default. > > I think that this sort of functionality belongs in a wrapper library. > There's no reason to artificially limit a particular DataView instance > to reading only big- or little-endian data. One could imagine a file > format that contained both big- and little-endian values, though it > would be convoluted. > > > 2) File cursor > > Most of the time you read a file sequentially. With the current API, you > > have to keep a cursor of where you are at and this is extremely annoying. > > You would like to write > > var a = view.getInt8(); > > var b = view.getFloat32(); > > Instead you have to write > > var cursor = 0; > > var a = view.getInt8(cursor); cursor += 1; > > var b = view.getFloat32(cursor); cursor += 4; > > DataView could have an internal cursor initialized to 0 at creation. > Every > > time you make a read/write, it would be set to the end of what has been > > read/written. byteOffset will be set to the cursor position. if > undefined. > > In order to manipulate the cursor, we would have two functions: > > seek(byteOffset) and tell() > > Per above, this was already considered and rejected. It can easily be > implemented in a wrapper library. > > > 3) getChar and getString > > Often, binary files also contain characters and strings. With the current > > API, this is extremely annoying to read those types of values. > > I suggest to add 4 new functions: > > getChar(byteOffset) > > getString(length, byteOffset) > > setChar(byteOffset, char) > > setString(byteOffset, string, optional length) > > One issue I see is encoding. I believe that strings in binary files are > > often in ASCII while Javascript strings are UTF-8. > > Better interoperability between the Typed Array API and JavaScript > strings is definitely needed, and there have been discussions on this > mailing list about how to achieve it. Unfortunately, so far there > hasn't been a champion of this functionality to specify it. > > I am no expert in this area, but I have a feeling that the API needed > for this functionality will be moderately sized. It seems clear that > it will be necessary to support multiple character encodings. For > these reasons, I think the best path forward would be to add a > separate specification defining JavaScript string encoding and > decoding into typed arrays and/or the DataView class. If you'd be > willing to contribute to this effort that would be great. > > -Ken > > > I hope that these suggestions will help to make the DataView API more > user > > friendly. It is important to have a good support for binary files if we > want > > to make browser Javascript future-proof! :) > > > > -- > > Christopher CHEDEAU - Vjeux > > EPITA - LRDE - Ing2 2012 > > Curse.com Web Developer > > > > http://blog.vjeux.com/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Tue Apr 12 06:24:36 2011 From: ste...@ (ste...@) Date: Tue, 12 Apr 2011 06:24:36 -0700 Subject: [Public WebGL] Progressive loading In-Reply-To: <4DA415EE.80601@vicomtech.org> References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> <4DA415EE.80601@vicomtech.org> Message-ID: <20b47a25ae6f2d0057137624220fc074.squirrel@webmail.sjbaker.org> Alvaro Segura said: > Some WebGL applications suffer > from delays in inlitialization due to several reasons: texture > downloads, shader compiling, mesh data downloads.
> Applications with many and/or very large textures have to way > for them to be fully downloaded before they can be loaded into > WebGL. Usually their onload event is used. Before that textures > are "black". It would be beneficial to support progressive > texture loading so that the user does not see a frozen scene but > sees some progress going on. It would be neat to have progressive loading of textures so you could start the game playing with blurry maps and have them gradually sharpen up...but for most 3D apps, we need MIPmapped textures - and progressively loading the main image and producing progressively loaded MIPmaps on the fly...well, it's not impossible, but with some file formats it would be really complicated! What you really need to do this well is a file format where the MIP levels are stored explicitly from the 1x1 up to the NxN - and to have each texel stored as the difference between its' value and the corresponding texel in the MIP level beneath it so you don't need so many bits to store these difference value and the file size doesn't just get 33% larger. That way the loader would only have to load each MIP level in turn. However, couldn't you do nearly as well by generating the top couple of MIP levels yourself into separate files - then just write code to load lower MIP level files first. You'd load a little bit more data - but if you stored just the top level map and a map (say) two MIP levels down, the extra files would be only 1/16th the amount of data and would load something close to 16 times faster...then when you have them all loaded, start the game running and replace them as the high resolution maps load. This would only increase the amount of data to transfer by ~8% and produce more or less the effect you're aiming for here. -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Tue Apr 12 09:00:05 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 12:00:05 -0400 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> Message-ID: On Tue, Apr 12, 2011 at 4:45 AM, Vladimir Vukicevic wrote: > It's a bit roundabout, but you can: > > - Load the image as an image > - Draw it into an offscreen 2D of the same size > - Use getImageData > - Use the returned ImageData's data buffer with buffer[Sub]Data > > Requires an extra step with the canvas drawing (and associated extra memory usage), but should be possible. > ----- Original Message ----- >> It currently doesn't appear possible to load a WebGLBuffer from an >> image, to use an image as vertex data. I can't do this manually, by >> writing the image to a 2d Canvas and passing its ImageData to >> bufferData, due to same-origin restrictions. That's what I described here: it doesn't work, since getImageData isn't allowed for cross-origin images. A direct API can deal properly with the cross-origin issues, in the same way texImage2D does. -- Glenn Maynard ----------------------------------------------------------- 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 rko...@ Tue Apr 12 09:16:22 2011 From: rko...@ (Kornmann, Ralf) Date: Tue, 12 Apr 2011 17:16:22 +0100 Subject: AW: [Public WebGL] Progressive loading In-Reply-To: <20b47a25ae6f2d0057137624220fc074.squirrel@webmail.sjbaker.org> References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> <4DA415EE.80601@vicomtech.org>,<20b47a25ae6f2d0057137624220fc074.squirrel@webmail.sjbaker.org> Message-ID: <9B3BEF16CBC82A45900B3F159DF91596015031D49AE1@EU-MAIL-1-1.rws.ad.ea.com> Well, if we already at this point I like to see support for compressed textures. I know that different systems supports different formats but we already need to handle this with HTML5 audio. Therefore I don?t see a big problem storing textures in different formats on the server (with an uncompressed as final fallback) and load the right one based on what the browser/hardware supports. I believe this is especial useful for Smartphone?s where bandwidth and memory is much more limited then on desktop systems. -Ralf ________________________________________ Von: owner-public_webgl...@ [owner-public_webgl...@] im Auftrag von steve...@ [steve...@] Gesendet: Dienstag, 12. April 2011 15:24 An: Alvaro Segura Cc: public webgl Betreff: Re: [Public WebGL] Progressive loading Alvaro Segura said: > Some WebGL applications suffer > from delays in inlitialization due to several reasons: texture > downloads, shader compiling, mesh data downloads.
> Applications with many and/or very large textures have to way > for them to be fully downloaded before they can be loaded into > WebGL. Usually their onload event is used. Before that textures > are "black". It would be beneficial to support progressive > texture loading so that the user does not see a frozen scene but > sees some progress going on. It would be neat to have progressive loading of textures so you could start the game playing with blurry maps and have them gradually sharpen up...but for most 3D apps, we need MIPmapped textures - and progressively loading the main image and producing progressively loaded MIPmaps on the fly...well, it's not impossible, but with some file formats it would be really complicated! What you really need to do this well is a file format where the MIP levels are stored explicitly from the 1x1 up to the NxN - and to have each texel stored as the difference between its' value and the corresponding texel in the MIP level beneath it so you don't need so many bits to store these difference value and the file size doesn't just get 33% larger. That way the loader would only have to load each MIP level in turn. However, couldn't you do nearly as well by generating the top couple of MIP levels yourself into separate files - then just write code to load lower MIP level files first. You'd load a little bit more data - but if you stored just the top level map and a map (say) two MIP levels down, the extra files would be only 1/16th the amount of data and would load something close to 16 times faster...then when you have them all loaded, start the game running and replace them as the high resolution maps load. This would only increase the amount of data to transfer by ~8% and produce more or less the effect you're aiming for here. -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- 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 gle...@ Tue Apr 12 09:25:03 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 12:25:03 -0400 Subject: [Public WebGL] Progressive loading In-Reply-To: <4DA415EE.80601@vicomtech.org> References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> <4DA415EE.80601@vicomtech.org> Message-ID: On Tue, Apr 12, 2011 at 5:05 AM, Alvaro Segura wrote: > Some WebGL applications suffer from delays in inlitialization due to > several reasons: texture downloads, shader compiling, mesh data downloads. > > Applications with many and/or very large textures have to way for them to > be fully downloaded before they can be loaded into WebGL. Usually their > onload event is used. Before that textures are "black". It would be > beneficial to support progressive texture loading so that the user does not > see a frozen scene but sees some progress going on. > I've hit this problem using WebGL to manipulate image resources. I'm replacing a simple on a page with a with the same image manipulated; for example, to apply gamma adjustments. It works fairly well, but as you described, progressive loading doesn't work. Now, there's a basic issue: you need to update the WebGL canvas as the image becomes available. If you render the entire context, that means it's drawing the entire canvas constantly as new data comes in. When a few new rows of image data arrive, you have to redraw the entire scene, since you don't know what's changed. If you just have one image this isn't a big deal--it's no different than animating a scene--but if it's just one (or several) images in a larger page it's problematic, since it'd make page loading much more expensive. For most images, where data arrives row by row, top-to-bottom, this could be solved by exposing to scripts the region of the image which is available. That wouldn't work for interlaced PNGs and progressive JPEGs[1], which incrementally improve the entire image (though it would still be useful if it simply didn't work on these formats, which really aren't used all that often anymore). It would be tricky for other formats, like bottom-up BMPs, which would probably also not be worth supporting. This would also require Progress Events support in HTMLImageElement to inform of loading progress. Note that the same issue exists with 2d canvas. In that case, the part of the spec that defines this is the image "fully decodable" state; see [2] and [3]. WebGL doesn't actually reference the term "fully decodable". I think it should, in the same way 2d canvas does. [1] It's fantastic that "interlaced" PNG and "progressive" JPEG mean the same thing, yet are opposites in video contexts. [2] http://dev.w3.org/html5/spec/embedded-content-1.html#img-good [3] http://dev.w3.org/html5/2dcontext/#images > If one tries to do texImage2D before the "onload" event has triggered, > there is no data to load (a null image is passed), even if part of the image > has already been received. Why not provide the partial image here? (leaving > black pixels where no data has arrived). Images in the HTML page (regular > ) do display progressively. > > This would be especially useful with progressive JPEG or progressive PNG > that provide a full low-quality version of the image with just a little > fraction of the complete image data. > > > For shader compile times we have been discussing issues and solutions in > other threads. It's true that compiling currently freezes the browser. I > don't know if it could be done in a WebWorker. > Not directly, since you can't share a WebGL context--or anything at all--between a worker and the main thread. For that matter, you can't even create a WebGL context at all in worker threads--that would be nice to fix, for lots of reasons, but it's very difficult to expose DOM objects to workers, so I doubt we'll see this any time soon... FWIW: If WebGL was accessible from worker threads, and if an extension was added to serialize and deserialize compiled scripts to allow shader caching, then that would also allow doing shader compiles in a thread. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Apr 12 10:07:08 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 12 Apr 2011 10:07:08 -0700 Subject: [Public WebGL] Web Workers and ArrayBuffers? In-Reply-To: References: Message-ID: What browser and version are you using? We are about to start revising the Typed Array specification to define the behavior of passing ArrayBuffers and typed array views between the main thread and worker threads. The new behavior will be zero-copy, and if you ping-pong the ArrayBuffers back and forth, you'll be able to implement really efficient producer-consumer queues. These changes will be discussed on this list as they show up, and hopefully you'll see this behavior start to appear in nightly builds of browsers within a couple of months. -Ken On Tue, Apr 12, 2011 at 4:41 AM, Shy Shalom wrote: > I'm trying to write a Worker thread that does some processing and creates a > mesh on the fly. > It works fine up until returning the created result to the main GUI thread. > it seems that the communication between the worker and the main thread does > JSON serialization, > so if I'm sending a Float32Array from the worker, what I get in the main > thread is a regular JavaScript array. > > A trivial solution is to just rebuild the Float32Array again from the array > I receive but that seems wasteful. > Is there a good workaround for this? Maybe a way to tell the JSON > deserialization that something should be a Float32Array ? > ----------------------------------------------------------- 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 oli...@ Tue Apr 12 10:15:37 2011 From: oli...@ (Oliver Hunt) Date: Tue, 12 Apr 2011 10:15:37 -0700 Subject: [Public WebGL] Web Workers and ArrayBuffers? In-Reply-To: References: Message-ID: <222DD5DC-3BC8-4DA1-ACE6-98D4A5D604A4@apple.com> I am still concerned about the semantics of the zero copy idea - where is this postMessage behaviour defined? --Oliver On Apr 12, 2011, at 10:07 AM, Kenneth Russell wrote: > > What browser and version are you using? > > We are about to start revising the Typed Array specification to define > the behavior of passing ArrayBuffers and typed array views between the > main thread and worker threads. The new behavior will be zero-copy, > and if you ping-pong the ArrayBuffers back and forth, you'll be able > to implement really efficient producer-consumer queues. > > These changes will be discussed on this list as they show up, and > hopefully you'll see this behavior start to appear in nightly builds > of browsers within a couple of months. > > -Ken > > On Tue, Apr 12, 2011 at 4:41 AM, Shy Shalom wrote: >> I'm trying to write a Worker thread that does some processing and creates a >> mesh on the fly. >> It works fine up until returning the created result to the main GUI thread. >> it seems that the communication between the worker and the main thread does >> JSON serialization, >> so if I'm sending a Float32Array from the worker, what I get in the main >> thread is a regular JavaScript array. >> >> A trivial solution is to just rebuild the Float32Array again from the array >> I receive but that seems wasteful. >> Is there a good workaround for this? Maybe a way to tell the JSON >> deserialization that something should be a Float32Array ? >> > ----------------------------------------------------------- > 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 sho...@ Tue Apr 12 10:17:54 2011 From: sho...@ (Shy Shalom) Date: Tue, 12 Apr 2011 20:17:54 +0300 Subject: [Public WebGL] Web Workers and ArrayBuffers? In-Reply-To: References: Message-ID: Using Chrome 10.0.648.204 This actually already works well on Firefox. the typed array are preserved in the received object. So I only need to add a check for Chrome. There's this bug report about it - http://code.google.com/p/chromium/issues/detail?id=73313 Why is there a need for a revision to the typed array spec? (not that it really bothers me) Another note - Firefox also seems to be stricter about which objects it agrees to post . If the posted object contain functions, an exception is thrown. The same postMessage goes through without error in Chrome. Not sure if that's a bug or a feature. On 12 April 2011 20:07, Kenneth Russell wrote: > What browser and version are you using? > > We are about to start revising the Typed Array specification to define > the behavior of passing ArrayBuffers and typed array views between the > main thread and worker threads. The new behavior will be zero-copy, > and if you ping-pong the ArrayBuffers back and forth, you'll be able > to implement really efficient producer-consumer queues. > > These changes will be discussed on this list as they show up, and > hopefully you'll see this behavior start to appear in nightly builds > of browsers within a couple of months. > > -Ken > > On Tue, Apr 12, 2011 at 4:41 AM, Shy Shalom wrote: > > I'm trying to write a Worker thread that does some processing and creates > a > > mesh on the fly. > > It works fine up until returning the created result to the main GUI > thread. > > it seems that the communication between the worker and the main thread > does > > JSON serialization, > > so if I'm sending a Float32Array from the worker, what I get in the main > > thread is a regular JavaScript array. > > > > A trivial solution is to just rebuild the Float32Array again from the > array > > I receive but that seems wasteful. > > Is there a good workaround for this? Maybe a way to tell the JSON > > deserialization that something should be a Float32Array ? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Tue Apr 12 10:23:57 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 13:23:57 -0400 Subject: [Public WebGL] Web Workers and ArrayBuffers? In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 1:07 PM, Kenneth Russell wrote: > We are about to start revising the Typed Array specification to define > the behavior of passing ArrayBuffers and typed array views between the > main thread and worker threads. The new behavior will be zero-copy, > and if you ping-pong the ArrayBuffers back and forth, you'll be able > to implement really efficient producer-consumer queues. Note that there's been discussion recently on a couple mailing lists on the subject of zero-copy PostMessage, though it stalled out: "WebWorkers and images" on whatwg: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029737.html "Using ArrayBuffer as payload for binary data to/from Web Workers" on webapps: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0807.html I don't think this belongs in the Typed Array spec, but as part of the Web Messaging and Web Worker specs, to allow zero-copy messaging with a consistent API for any supported types. CanvasPixelArray for 2d canvas is another obvious candidate (though I *really* wish CanvasPixelArray and ArrayBuffer weren't totally separate APIs in the first place). I'm not sure how this could be done in Typed Arrays without support from the Web Messaging spec in the first place... -- Glenn Maynard ----------------------------------------------------------- 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 Apr 12 10:48:59 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 12 Apr 2011 10:48:59 -0700 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> Message-ID: On Tue, Apr 12, 2011 at 9:00 AM, Glenn Maynard wrote: > > On Tue, Apr 12, 2011 at 4:45 AM, Vladimir Vukicevic wrote: >> It's a bit roundabout, but you can: >> >> - Load the image as an image >> - Draw it into an offscreen 2D of the same size >> - Use getImageData >> - Use the returned ImageData's data buffer with buffer[Sub]Data >> >> Requires an extra step with the canvas drawing (and associated extra memory usage), but should be possible. > >> ----- Original Message ----- >>> It currently doesn't appear possible to load a WebGLBuffer from an >>> image, to use an image as vertex data. I can't do this manually, by >>> writing the image to a 2d Canvas and passing its ImageData to >>> bufferData, due to same-origin restrictions. > > That's what I described here: it doesn't work, since getImageData > isn't allowed for cross-origin images. ?A direct API can deal properly > with the cross-origin issues, in the same way texImage2D does. Uploading an image to be used as vertex data is a hack. You'll only be guaranteed lossless data transfer with PNGs. I don't think we would want to add these entry points in the general case as they would promote poor application development practices. Why do you not want to download binary data? A couple of corrections to your original email. I don't believe there is a way to transfer a texture into a buffer object natively with OpenGL ES 2.0 APIs, as glGetTexImage is not available. Second, some WebGL implementations today do support floating point textures via the OES_texture_float extension; see http://www.khronos.org/registry/webgl/extensions/ . -Ken > -- > Glenn Maynard > ----------------------------------------------------------- > 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...@ Tue Apr 12 10:58:40 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 12 Apr 2011 10:58:40 -0700 Subject: [Public WebGL] Web Workers and ArrayBuffers? In-Reply-To: <222DD5DC-3BC8-4DA1-ACE6-98D4A5D604A4@apple.com> References: <222DD5DC-3BC8-4DA1-ACE6-98D4A5D604A4@apple.com> Message-ID: On Tue, Apr 12, 2011 at 10:15 AM, Oliver Hunt wrote: > I am still concerned about the semantics of the zero copy idea - where is this postMessage behaviour defined? It hasn't been written down formally yet; the initial idea was hammered out during a couple of meetings between Mozilla and Google. The basic idea is that if an ArrayBuffer is sent via structured clone, the instance on the current thread is "closed", meaning that it, and all views on to it, immediately become zero-length. If a typed array view is sent via structured clone, then it, its backing ArrayBuffer, and any other views on to the ArrayBuffer are closed. Sending an object graph which references multiple views, all referencing the same ArrayBuffer, must work; the ArrayBuffer is reconstituted on the other side, along with all of the referenced views. Expect a strawman draft in the typed array spec's editor's draft within a couple of weeks. -Ken > --Oliver > > On Apr 12, 2011, at 10:07 AM, Kenneth Russell wrote: > >> >> What browser and version are you using? >> >> We are about to start revising the Typed Array specification to define >> the behavior of passing ArrayBuffers and typed array views between the >> main thread and worker threads. The new behavior will be zero-copy, >> and if you ping-pong the ArrayBuffers back and forth, you'll be able >> to implement really efficient producer-consumer queues. >> >> These changes will be discussed on this list as they show up, and >> hopefully you'll see this behavior start to appear in nightly builds >> of browsers within a couple of months. >> >> -Ken >> >> On Tue, Apr 12, 2011 at 4:41 AM, Shy Shalom wrote: >>> I'm trying to write a Worker thread that does some processing and creates a >>> mesh on the fly. >>> It works fine up until returning the created result to the main GUI thread. >>> it seems that the communication between the worker and the main thread does >>> JSON serialization, >>> so if I'm sending a Float32Array from the worker, what I get in the main >>> thread is a regular JavaScript array. >>> >>> A trivial solution is to just rebuild the Float32Array again from the array >>> I receive but that seems wasteful. >>> Is there a good workaround for this? Maybe a way to tell the JSON >>> deserialization that something should be a Float32Array ? >>> >> ----------------------------------------------------------- >> 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...@ Tue Apr 12 11:05:23 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 12 Apr 2011 11:05:23 -0700 Subject: [Public WebGL] Web Workers and ArrayBuffers? In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 10:23 AM, Glenn Maynard wrote: > On Tue, Apr 12, 2011 at 1:07 PM, Kenneth Russell wrote: >> We are about to start revising the Typed Array specification to define >> the behavior of passing ArrayBuffers and typed array views between the >> main thread and worker threads. The new behavior will be zero-copy, >> and if you ping-pong the ArrayBuffers back and forth, you'll be able >> to implement really efficient producer-consumer queues. > > Note that there's been discussion recently on a couple mailing lists > on the subject of zero-copy PostMessage, though it stalled out: > > "WebWorkers and images" on whatwg: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/029737.html > > "Using ArrayBuffer as payload for binary data to/from Web Workers" on webapps: > http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0807.html > > I don't think this belongs in the Typed Array spec, but as part of the > Web Messaging and Web Worker specs, to allow zero-copy messaging with > a consistent API for any supported types. ?CanvasPixelArray for 2d > canvas is another obvious candidate (though I *really* wish > CanvasPixelArray and ArrayBuffer weren't totally separate APIs in the > first place). > > I'm not sure how this could be done in Typed Arrays without support > from the Web Messaging spec in the first place... We've been hoping to keep things simple, and just specify how ArrayBuffers and typed array views interact with the structured clone algorithm. I think it would be appropriate to include this text in the typed array spec, because it would keep the behavioral definition of these types self-contained. Looking at the Web Messaging spec, I don't think any changes would be needed in order to add this support to typed arrays. -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 gle...@ Tue Apr 12 12:34:33 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 15:34:33 -0400 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> Message-ID: On Tue, Apr 12, 2011 at 1:48 PM, Kenneth Russell wrote: > Uploading an image to be used as vertex data is a hack. You'll only be > guaranteed lossless data transfer with PNGs. I don't think we would > want to add these entry points in the general case as they would > promote poor application development practices. Why do you not want to > download binary data? In this case, I want to load a user-provided image to generate a histogram. The user-supplied image may be a remote URL, which I can load and manipulate but not access directly due to same-origin restrictions. The first pass of that (per channel) would be to use the pixel data to generate points. It could use vertex shader texture sampling, but there's no guarantee that any vertex texture units exist (and most current implementations don't implement them at all), so using a vertex buffer here eliminates the dependency on optional requirements. (It's also simpler to implement, and probably faster.) (I'm not interested in weird hacks like, say, loading mesh data from a PNG. That's not very useful--PNG won't be good at compressing it, and you'd need to compound the hack badly to get anything other than 8-bit integers out of it.) > Second, some > WebGL implementations today do support floating point textures via the > OES_texture_float extension; see > http://www.khronos.org/registry/webgl/extensions/ . I hadn't seen that page. I suggest adding it to http://www.khronos.org/webgl/; after some searching I only see it linked from the wiki. -- Glenn Maynard ----------------------------------------------------------- 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 gle...@ Tue Apr 12 18:06:42 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 21:06:42 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context Message-ID: A problem with webglcontextrestored: "The system only restores the context if a handler for the webglcontextrestored event is installed on the HTMLCanvasElement associated with the context." Registering DOM event listeners doesn't have side-effects. Calling object.addEventListener("string", function(e) { }, false); should never have any perceivable side-effect. I don't know of any API on the platform where this isn't the case. I recommend: "The system only restores the context if the default behavior for the webglcontextlost event is prevented." (Note: webglcontextlost here, not webglcontextrestored.) In other words, the default behavior of webglcontextlost is to prevent restoration of the context. This is much more consistent with how DOM events work. (I'll suggest a more precise spec wording later after some other discussions move forward, if there's interest in making this change.) To enable context restoration, canvas.addEventListener("webglcontextlost", function(e) { e.preventDefault(); }, false); A related issue (maybe some WebKit list is a closer fit for this, but it seems appropriate here): WEBKIT_lose_context exposes one function: loseContext. It causes the context to be lost, and then restored a moment later. This allows testing context loss, but it's incomplete: it's not possible to cause the context stay lost. This is needed to test script behavior during an extended or permanent context loss; for example, when manipulating UI controls while the context is still lost. I'd suggest adding a "force" parameter to loseContext; if true, an internal flag is set, persistently preventing the context from being restored. Second, add a restoreContext() method, which unset the flag, allowing the context to be restored at next appropriate time in the event loop. If the "force" flag wasn't already set, restoreContext() triggers INVALID_OPERATION. I think this it's important to make it as easy as possible to test context loss, or else nobody is going to handle it correctly. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Tue Apr 12 18:22:45 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 21:22:45 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 9:15 PM, Alexey Marinichev wrote: > Regarding the restoreContext method, what would happen if the browser is > unable to restore the context? restoreContext doesn't synchronously restore the context. It just removes the block put in place by loseContext, allowing the browser to restore the context in the future along the normal async context-recovery path. If the context can't be restored, it just stays lost. (If that happens when you're using these methods to test code, it could be confusing; it may want to log a warning to the console if that happens.) Maybe a better name for the method is something like "allowRestoreContext". -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Apr 12 18:22:50 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Tue, 12 Apr 2011 18:22:50 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 6:06 PM, Glenn Maynard wrote: > A problem with webglcontextrestored: "The system only restores the context > if a handler for the webglcontextrestored event is installed on the > HTMLCanvasElement associated with the context." > > Registering DOM event listeners doesn't have side-effects. Calling > object.addEventListener("string", function(e) { }, false); should never have > any perceivable side-effect. I don't know of any API on the platform where > this isn't the case. > > I recommend: "The system only restores the context if the default behavior > for the webglcontextlost event is prevented." (Note: webglcontextlost here, > not webglcontextrestored.) > > In other words, the default behavior of webglcontextlost is to prevent > restoration of the context. This is much more consistent with how DOM > events work. (I'll suggest a more precise spec wording later after some > other discussions move forward, if there's interest in making this change.) > To enable context restoration, > > canvas.addEventListener("webglcontextlost", function(e) { > e.preventDefault(); }, false); > > The problem is the application *HAS TO TAKE ACTION* if the context is lost and restored. So, if an webgl auto-restores the context and the app doesn't handle it the results are random and unpredictable. All resources are lost and you have to re-create them. If the app is creating resources on the fly some will get re-created some not. It was deemed that unpredictability is bad. Adding a listener to "webglcontextlost" is a signal to WebGL that "this app is going to handle lost/restored context". Any app that doesn't handle it should fail immediately on context lost which is why it's not auto-restored. The opposite way makes no sense. Apps that don't deal with lost-restored contexts are not going to start correctly marking themselves as unable to handle the situation. Rather, only apps that go to the effort to handle lost-restored contexts will tell WebGL they know how to handle it. > > > A related issue (maybe some WebKit list is a closer fit for this, but it > seems appropriate here): > > WEBKIT_lose_context exposes one function: loseContext. It causes the > context to be lost, and then restored a moment later. This allows testing > context loss, but it's incomplete: it's not possible to cause the context > stay lost. This is needed to test script behavior during an extended or > permanent context loss; for example, when manipulating UI controls while the > context is still lost. > > I'd suggest adding a "force" parameter to loseContext; if true, an internal > flag is set, persistently preventing the context from being restored. > Second, add a restoreContext() method, which unset the flag, allowing the > context to be restored at next appropriate time in the event loop. If the > "force" flag wasn't already set, restoreContext() triggers > INVALID_OPERATION. > > I think this it's important to make it as easy as possible to test context > loss, or else nobody is going to handle it correctly. > > -- > Glenn Maynard > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Tue Apr 12 18:27:12 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 21:27:12 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 9:22 PM, Gregg Tavares (wrk) wrote: > The problem is the application *HAS TO TAKE ACTION* if the context is lost > and restored. So, if an webgl auto-restores the context and the app doesn't > handle it the results are random and unpredictable. All resources are lost > and you have to re-create them. If the app is creating resources on the fly > some will get re-created some not. It was deemed that unpredictability is > bad. Adding a listener to "webglcontextlost" is a signal to WebGL that "this > app is going to handle lost/restored context". Any app that doesn't handle > it should fail immediately on context lost which is why it's not > auto-restored. > I understand that, but this is the wrong way of indicating that you intend to handle a recovered context. It violates the basic design of DOM Events. The method I proposed *also* *explicitly* indicates that it intends to handle context restoration, but in a manner compatible with the design of DOM Events. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jam...@ Tue Apr 12 18:31:00 2011 From: jam...@ (James Robinson) Date: Tue, 12 Apr 2011 18:31:00 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 6:22 PM, Gregg Tavares (wrk) wrote: > > > The problem is the application *HAS TO TAKE ACTION* if the context is lost > and restored. So, if an webgl auto-restores the context and the app doesn't > handle it the results are random and unpredictable. All resources are lost > and you have to re-create them. If the app is creating resources on the fly > some will get re-created some not. It was deemed that unpredictability is > bad. Adding a listener to "webglcontextlost" is a signal to WebGL that "this > app is going to handle lost/restored context". Any app that doesn't handle > it should fail immediately on context lost which is why it's not > auto-restored. > > The opposite way makes no sense. Apps that don't deal with lost-restored > contexts are not going to start correctly marking themselves as unable to > handle the situation. Rather, only apps that go to the effort to handle > lost-restored contexts will tell WebGL they know how to handle it. > > > The default behavior with this proposal is that a lost context is permanent (since on a context loss without a webgllostcontext event handler the default action will occur and the context will be marked as permanently lost). The application has to opt-in to auto-restoring the context by registering a contextlost event handler that calls event.preventDefault(). - James -------------- next part -------------- An HTML attachment was scrubbed... URL: From enn...@ Tue Apr 12 19:08:34 2011 From: enn...@ (Adrienne Walker) Date: Tue, 12 Apr 2011 19:08:34 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: El d?a 12 de abril de 2011 18:06, Glenn Maynard escribi?: > WEBKIT_lose_context exposes one function: loseContext.? It causes the > context to be lost, and then restored a moment later.? This allows testing > context loss, but it's incomplete: it's not possible to cause the context > stay lost.? This is needed to test script behavior during an extended or > permanent context loss; for example, when manipulating UI controls while the > context is still lost. I don't think it's incomplete. You can write two tests: one where you register the webglcontextlost event handler to test restoration behavior and one where you don't to test behavior under a permanently lost context. That's what we do in WebKit. -Adrienne ----------------------------------------------------------- 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 gle...@ Tue Apr 12 19:27:55 2011 From: gle...@ (Glenn Maynard) Date: Tue, 12 Apr 2011 22:27:55 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 10:08 PM, Adrienne Walker wrote: > I don't think it's incomplete. You can write two tests: one where you > register the webglcontextlost event handler to test restoration > behavior and one where you don't to test behavior under a permanently > lost context. That's what we do in WebKit. > This doesn't allow me to test losing the context, manipulating the UI in some way while the context is lost, then restoring the context later. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed Apr 13 03:04:49 2011 From: jda...@ (John Davis) Date: Wed, 13 Apr 2011 05:04:49 -0500 Subject: [Public WebGL] point sprites Message-ID: Are there any demos or documentation showing the use of gl_pointsize and gl_pointcoord? JD -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dan...@ Wed Apr 13 04:39:16 2011 From: Dan...@ (Ginsburg, Daniel) Date: Wed, 13 Apr 2011 07:39:16 -0400 Subject: [Public WebGL] point sprites In-Reply-To: Message-ID: Hi John, You could have a look at the ParticleSystem example from the OpenGL ES 2.0 Programming Guide: http://www.opengles-book.com/webgl.html . It uses gl_PointSize to control the size of the particles and gl_PointCoord for applying the texture. Hope this helps. -- Dan On 4/13/11 6:04 AM, "John Davis" wrote: Are there any demos or documentation showing the use of gl_pointsize and gl_pointcoord? JD ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Wed Apr 13 13:45:17 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 13 Apr 2011 13:45:17 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 6:27 PM, Glenn Maynard wrote: > On Tue, Apr 12, 2011 at 9:22 PM, Gregg Tavares (wrk) > wrote: >> >> The problem is the application HAS TO TAKE ACTION if the context is lost >> and restored. So, if an webgl auto-restores the context and the app doesn't >> handle it the results are random and unpredictable. All resources are lost >> and you have to re-create them. If the app is creating resources on the fly >> some will get re-created some not. It was deemed that unpredictability is >> bad. Adding a listener to "webglcontextlost" is a signal to WebGL that "this >> app is going to handle lost/restored context". Any app that doesn't handle >> it should fail immediately on context lost which is why it's not >> auto-restored. > > I understand that, but this is the wrong way of indicating that you intend > to handle a recovered context.? It violates the basic design of DOM Events. > The method I proposed *also* *explicitly* indicates that it intends to > handle context restoration, but in a manner compatible with the design of > DOM Events. Thanks for pointing out this issue and for the suggested fix. It seems like a reasonable change, and in fact one that would be forward compatible; if web pages are updated now, they will continue to work up to and through the point where browsers implement the new context lost and recovery semantics. Could some of the other browser vendors in particular comment on this proposed change? -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 cvi...@ Wed Apr 13 13:50:48 2011 From: cvi...@ (Cedric Vivier) Date: Thu, 14 Apr 2011 04:50:48 +0800 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Thu, Apr 14, 2011 at 04:45, Kenneth Russell wrote: > Thanks for pointing out this issue and for the suggested fix. It seems > like a reasonable change, and in fact one that would be forward > compatible; if web pages are updated now, they will continue to work > up to and through the point where browsers implement the new context > lost and recovery semantics. > > Could some of the other browser vendors in particular comment on this > proposed change? I really like this. On top of the more consistent semantics, it will also surely make implementations easier/cleaner. Regards, ----------------------------------------------------------- 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 Apr 13 15:39:45 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 13 Apr 2011 15:39:45 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Tue, Apr 12, 2011 at 7:27 PM, Glenn Maynard wrote: > On Tue, Apr 12, 2011 at 10:08 PM, Adrienne Walker wrote: >> >> I don't think it's incomplete. ?You can write two tests: one where you >> register the webglcontextlost event handler to test restoration >> behavior and one where you don't to test behavior under a permanently >> lost context. ?That's what we do in WebKit. > > This doesn't allow me to test losing the context, manipulating the UI in > some way while the context is lost, then restoring the context later. I tend to agree with this observation. While the extension was originally under development there were several offline discussions around whether an explicit restoreContext() was needed. At the time there was agreement that it wasn't, since as Adrienne points out one can simply write multiple tests. However, if you're trying to stress test an existing application, I think having control over when context restoration is attempted would make it easier, and allow testing more application states. I think we should revise the extension specification and add an explicit restoreContext() call. Adrienne, what do you think? -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 enn...@ Wed Apr 13 15:57:40 2011 From: enn...@ (Adrienne Walker) Date: Wed, 13 Apr 2011 15:57:40 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: El d?a 13 de abril de 2011 15:39, Kenneth Russell escribi?: > I think we should revise the extension specification and add an > explicit restoreContext() call. Adrienne, what do you think? Glenn makes a good point about the testing limitations of the current extension. I think it's a good idea to add a restoreContext call, especially in the context of the larger discussion here. If the spec is revised to let contexts always be restored regardless of event handler registration, then there would no longer be a way to test prolonged lost context scenarios. -Adrienne ----------------------------------------------------------- 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 gle...@ Wed Apr 13 16:52:46 2011 From: gle...@ (Glenn Maynard) Date: Wed, 13 Apr 2011 19:52:46 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Wed, Apr 13, 2011 at 6:57 PM, Adrienne Walker wrote: > Glenn makes a good point about the testing limitations of the current > extension. ?I think it's a good idea to add a restoreContext call, > especially in the context of the larger discussion here. ?If the spec > is revised to let contexts always be restored regardless of event > handler registration, then there would no longer be a way to test > prolonged lost context scenarios. Note that with the proposed webglcontextlost behavior, you can still trigger a prolonged lost context: don't preventDefault webglcontextlost. You can not, however, prolong the lost context and then restore it at a later time. You can't do that with the current behavior either, though, at least in my earlier tests with Chrome 10. If you weren't listening for webglcontextrestored when the context was lost, it's too late to add it later. -- Glenn Maynard ----------------------------------------------------------- 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 gle...@ Thu Apr 14 07:22:26 2011 From: gle...@ (Glenn Maynard) Date: Thu, 14 Apr 2011 10:22:26 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> Message-ID: I forgot that this was all still going to whatwg, instead of public-webgl. We may want to move there. On Thu, Apr 14, 2011 at 12:33 AM, Glenn Maynard wrote: > On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell > wrote:Return a new object for contextId > > > Adding support for asynchronous initialization of WebGL is a good > > idea, and should be proposed on public_webgl, but this discussion > > should focus solely on improving the specification of the existing > > synchronous initialization path, and its error conditions. > > I only brought it up here because they're related. If an async path > exists, it can affect the design of the sync path as well. > > > > Given that the proposed asynchronous initialization path above uses > > webglcontextcreationerror and provides a status message, I think that > > should continue to be the error reporting mechanism for the current > > initialization path. > > So, the main difference from how it is now would be that getContext would > return an object, even on fatal errors, since WebGL can't return null from > context creation. That seems to work, and it does minimize the number of > things that would need to change for async initialization. It doesn't > distinguish between "permanent" and "recoverable" errors as we discussed > earlier, but that might just be overcomplicating things. (If that's wanted > too, it could be supported by treating preventDefault on the error event the > same as on the lost event, saying "if it becomes possible to create a > context later, I'm prepared for it". > > User code for this is very simple: > > > var gl = canvas.getContext("webgl"); > if (!gl) { > // WebGL is not supported > } else if (gl.isContextLost()) { > // WebGL could not be initialized; the error message can be received > from > // webglcontextcreationerror (or webglcontextlost) > } > > On Wed, Apr 13, 2011 at 10:53 PM, Cedric Vivier > wrote: > > I don't think the added complexity/verbosity provides any advantage > > over my proposal above (for the applications that even desire to show > > additional failure information). > > Is there a scenario I overlooked? > > Another advantage of using webglcontextlost is that, if the context > restoration proposal in the other thread is accepted, you could > preventDefault during it, just as with any other time the event is > received. It would tell the browser "if it ever becomes possible to create > the context in the future, give it to me" (via webglcontextrestored). You > could do that with *creationerror as well, but it would be duplicate logic. > > -- > Glenn Maynard > > -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 14 18:16:52 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 14 Apr 2011 18:16:52 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Wed, Apr 13, 2011 at 1:50 PM, Cedric Vivier wrote: > On Thu, Apr 14, 2011 at 04:45, Kenneth Russell wrote: >> Thanks for pointing out this issue and for the suggested fix. It seems >> like a reasonable change, and in fact one that would be forward >> compatible; if web pages are updated now, they will continue to work >> up to and through the point where browsers implement the new context >> lost and recovery semantics. >> >> Could some of the other browser vendors in particular comment on this >> proposed change? > > I really like this. > On top of the more consistent semantics, it will also surely make > implementations easier/cleaner. This was discussed during today's WebGL conference call and all of the desktop browser vendors currently implementing WebGL agreed that this change should be made. I've updated Section 5.14.3 in the Editor's Draft of the WebGL spec and the associated example below it. Please review: http://www.khronos.org/registry/webgl/specs/latest/#5.14.3 Glenn, thanks again for raising this issue and your suggested fix. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Apr 14 18:40:24 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 14 Apr 2011 18:40:24 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Wed, Apr 13, 2011 at 3:57 PM, Adrienne Walker wrote: > El d?a 13 de abril de 2011 15:39, Kenneth Russell escribi?: > >> I think we should revise the extension specification and add an >> explicit restoreContext() call. Adrienne, what do you think? > > Glenn makes a good point about the testing limitations of the current > extension. ?I think it's a good idea to add a restoreContext call, > especially in the context of the larger discussion here. ?If the spec > is revised to let contexts always be restored regardless of event > handler registration, then there would no longer be a way to test > prolonged lost context scenarios. OK, I've updated the WEBKIT_lose_context extension specification to add restoreContext(). I had to use slightly convoluted wording so that the spec language works against both the WebGL 1.0 spec as well as the current editor's draft, in which we've just changed the behavior of when webglcontextrestored is sent. I also moved the extension back to draft status. Please review these changes and send feedback to the list. http://www.khronos.org/registry/webgl/extensions/WEBKIT_lose_context/ -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 cvi...@ Thu Apr 14 18:50:46 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 15 Apr 2011 09:50:46 +0800 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 09:16, Kenneth Russell wrote: > This was discussed during today's WebGL conference call and all of the > desktop browser vendors currently implementing WebGL agreed that this > change should be made. I've updated Section 5.14.3 in the Editor's > Draft of the WebGL spec and the associated example below it. Please > review: > > http://www.khronos.org/registry/webgl/specs/latest/#5.14.3 Looks good to me, two nitpicks : - we should append to the end of webglcontextlost definition : "This event does not bubble and is cancellable." - in webglcontextrestored definition : "This event occurs when the WebGL implementation determines that a previously lost context can be restored." I think this should be replaced with : "This simple event occurs when the WebGL implementation has restored a lost context." Indeed the context has already been restored and ready for re-initialization of objects (textures, shaders, ...) when this event is handled by the application. Also we should specify that it is a simple event (does not bubble, not cancellable). Regards, ----------------------------------------------------------- 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 Apr 14 18:56:43 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 14 Apr 2011 18:56:43 -0700 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> Message-ID: On Tue, Apr 12, 2011 at 12:34 PM, Glenn Maynard wrote: > On Tue, Apr 12, 2011 at 1:48 PM, Kenneth Russell wrote: >> Uploading an image to be used as vertex data is a hack. You'll only be >> guaranteed lossless data transfer with PNGs. I don't think we would >> want to add these entry points in the general case as they would >> promote poor application development practices. Why do you not want to >> download binary data? > > In this case, I want to load a user-provided image to generate a > histogram. ?The user-supplied image may be a remote URL, which I can > load and manipulate but not access directly due to same-origin > restrictions. > > The first pass of that (per channel) would be to use the pixel data to > generate points. ?It could use vertex shader texture sampling, but > there's no guarantee that any vertex texture units exist (and most > current implementations don't implement them at all), so using a > vertex buffer here eliminates the dependency on optional requirements. > ?(It's also simpler to implement, and probably faster.) > > (I'm not interested in weird hacks like, say, loading mesh data from a > PNG. ?That's not very useful--PNG won't be good at compressing it, and > you'd need to compound the hack badly to get anything other than 8-bit > integers out of it.) Thanks, I understand your use case now. However, I am still concerned that adding APIs to upload images, canvases and video elements into (vertex) buffers will encourage gross misuse. I think it should be possible for you to achieve your use case by accumulating summary statistics in a fragment shader while repeatedly downsampling the image. I've spoken with colleagues that have computed mean and standard deviation of an image's brightness in a fragment shader using this technique. Could you give this approach some thought? -Ken >> Second, some >> WebGL implementations today do support floating point textures via the >> OES_texture_float extension; see >> http://www.khronos.org/registry/webgl/extensions/ . > > I hadn't seen that page. ?I suggest adding it to > http://www.khronos.org/webgl/; after some searching I only see it > linked from the wiki. It's linked from the specification as well. There's some confusion on the Khronos site between the landing page for some APIs (like WebGL) and the associated registry. The latter is located at http://www.khronos.org/registry/webgl/ . I would rather not add lots of links to the landing page until this gets resolved. ----------------------------------------------------------- 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 enn...@ Thu Apr 14 19:47:30 2011 From: enn...@ (Adrienne Walker) Date: Thu, 14 Apr 2011 19:47:30 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: El d?a 14 de abril de 2011 18:16, Kenneth Russell escribi?: > This was discussed during today's WebGL conference call and all of the > desktop browser vendors currently implementing WebGL agreed that this > change should be made. I've updated Section 5.14.3 in the Editor's > Draft of the WebGL spec and the associated example below it. Please > review: > > http://www.khronos.org/registry/webgl/specs/latest/#5.14.3 Thanks for this. :) My only nitpick is that the preventDefault function seems underspecified. Does an application have to call preventDefault after every context lost event or is that setting preserved? Also, I could just be bikeshedding, but calling it something more like "allowContextRestoration()" might be more readable. Maybe I just don't want to have to read the spec to guess what default preventDefault is referring to. -Adrienne ----------------------------------------------------------- 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 gle...@ Thu Apr 14 20:05:18 2011 From: gle...@ (Glenn Maynard) Date: Thu, 14 Apr 2011 23:05:18 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Thu, Apr 14, 2011 at 9:16 PM, Kenneth Russell wrote: > This was discussed during today's WebGL conference call and all of the > desktop browser vendors currently implementing WebGL agreed that this > change should be made. I've updated Section 5.14.3 in the Editor's > Draft of the WebGL spec and the associated example below it. Please > review: > > http://www.khronos.org/registry/webgl/specs/latest/#5.14.3 > Great. I don't see any issues at the moment, except what Cedric mentioned. On Thu, Apr 14, 2011 at 10:47 PM, Adrienne Walker wrote: > Also, I could just be bikeshedding, but calling it something more like > "allowContextRestoration()" might be more readable. Maybe I just > don't want to have to read the spec to guess what default > preventDefault is referring to. > preventDefault and the concept of an event's default behavior are part of the DOM Events API. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Thu Apr 14 20:10:25 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 15 Apr 2011 11:10:25 +0800 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 10:47, Adrienne Walker wrote: > My only nitpick is that the preventDefault function seems > underspecified. ?Does an application have to call preventDefault after > every context lost event or is that setting preserved? preventDefault is specified in DOM 2 events spec [ http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-cancelation ]. No setting is preserved, if you happen not to use preventDefault the default action for webglcontextlost (losing the context forever) prevails. Regards, ----------------------------------------------------------- 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 ste...@ Thu Apr 14 20:22:29 2011 From: ste...@ (Steve Baker) Date: Thu, 14 Apr 2011 22:22:29 -0500 Subject: [Public WebGL] Loading WebGLBuffer from an HTMLImageElement In-Reply-To: References: <27541974.13727.1302597940588.JavaMail.root@zimbra.off.net> Message-ID: <4DA7B9F5.9080402@sjbaker.org> On 04/14/2011 08:56 PM, Kenneth Russell wrote: > On Tue, Apr 12, 2011 at 12:34 PM, Glenn Maynard wrote: > >> On Tue, Apr 12, 2011 at 1:48 PM, Kenneth Russell wrote: >> >>> Uploading an image to be used as vertex data is a hack. You'll only be >>> guaranteed lossless data transfer with PNGs. I don't think we would >>> want to add these entry points in the general case as they would >>> promote poor application development practices. Why do you not want to >>> download binary data? >>> >> In this case, I want to load a user-provided image to generate a >> histogram. The user-supplied image may be a remote URL, which I can >> load and manipulate but not access directly due to same-origin >> restrictions. >> >> The first pass of that (per channel) would be to use the pixel data to >> generate points. It could use vertex shader texture sampling, but >> there's no guarantee that any vertex texture units exist (and most >> current implementations don't implement them at all), so using a >> vertex buffer here eliminates the dependency on optional requirements. >> (It's also simpler to implement, and probably faster.) >> >> (I'm not interested in weird hacks like, say, loading mesh data from a >> PNG. That's not very useful--PNG won't be good at compressing it, and >> you'd need to compound the hack badly to get anything other than 8-bit >> integers out of it.) >> > Thanks, I understand your use case now. However, I am still concerned > that adding APIs to upload images, canvases and video elements into > (vertex) buffers will encourage gross misuse. > > I think it should be possible for you to achieve your use case by > accumulating summary statistics in a fragment shader while repeatedly > downsampling the image. I've spoken with colleagues that have computed > mean and standard deviation of an image's brightness in a fragment > shader using this technique. Could you give this approach some > thought? > > -Ken > That technique is used almost universally in high dynamic range (HDR) lighting applications - which includes most games. It works very well. I've personally used it to construct histograms of image brightness (we were making a simulation of an advanced thermal imaging camera for the US Air Force). The difficulty in WebGL is that we only have access to a single "render target" - which means we can only write out four numbers from the fragment shader in each pass (R,G,B,A). So if you want a four band histogram, it's easy. If you needed (say) 16 bands, then you'd have to do the calculation four times - gathering 4 bands of the histogram each time. Also, the precision of your results will be limited if you're running on a cellphone or something with only 16 bit pixels - you really need to use the floating point texture extension. However, rendering images that are progressively smaller than the input image (maybe 4x4=16 times smaller with each reduction stage) means that you can do a LOT of passes and still get superb frame-rates. If your input image is 1024x1024 - then you render quads at 256x256, 64x64, 16x16, 4x4 and finally 1x1 - so you get your results after drawing just 5 quadrilaterals per four histogram samples. If you 'atlas' the results at the lower resolutions, you can batch the quads together - and it's AMAZINGLY fast, even if you want a 256 band histogram. -- Stee ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Thu Apr 14 21:21:33 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 14 Apr 2011 21:21:33 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: My nitpick is that I thought Glenn or Cedric pointed out early some far more standard spec language For example in the video element spec. Every event that is sent async is listed in the form of when a lost context is detected queue-a-task to fire a simple event named webglcontextlost at the canvas element . With each of those links live. Similarly the exact algorithm is spelled out. It seems like that kind of wording should be used. In particular there needs to be a distinction between webglcontextcreationerror that it dispatched synchronously and the other events which are queued. Also, it needs to be made clear (probably though a detailed algorithm) that regardless of whether or not the real OpenGL context is restored, from the point of view of WebGL and JavaScript the new context must not be usable until webglcontextrestored is delivered. Another words the algorithm is something like this When a lost context is detected 1. the WebGLRendering context is marked as "lost". A WebGLRenderingContext marked as "lost" behaves as follows. - The context's isContextLost method returns true. - All methods returning void return immediately. - All methods returning nullable values or any return null. - checkFramebufferStatus returns FRAMEBUFFER_UNSUPPORTED. - getAttribLocation returns -1. - getError returns CONTEXT_LOST_WEBGL the first time it is called while the context is lost. Afterward it will return NO_ERROR until the context has been restored. - getVertexAttribOffset returns 0. - All is queries return false. 2. a queue-a-task to fire a simple event named webglcontextlost at the canvas element . When the context has been restored 1. queue-a-task to fire a simple event named webglcontextrestored at the canvas element . Just before the event is dispatched, unmark the WebGLRenderingContext as "lost". I'm sure that's clear as mud and that someone else can say this more clearly. What's important is that the WebGLRenderingContext stay marked lost until the event is dispatched, not when the context is restored. Otherwise the behavior is un I also feel it's not clear from the spec that all the resources previously created must be invalid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Thu Apr 14 21:42:53 2011 From: gle...@ (Glenn Maynard) Date: Fri, 15 Apr 2011 00:42:53 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 12:21 AM, Gregg Tavares (wrk) wrote: > My nitpick is that I thought Glenn or Cedric pointed out early some far > more standard spec language > > For example in the video element spec. Every event that is sent async is > listed in the form of > > when a lost context is detected queue-a-task > to fire a simple event > named webglcontextlost at > the canvas element . > > With each of those links live. > I'm planning on writing up alternative spec text for the context creation, loss and recovery paths using this "algorithmic" style of specification (as opposed to the "descriptive" spec style), and offering it for comparison. I may ask for people's initial thoughts on async context initialization first (in its own thread) before doing that, too. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Fri Apr 15 09:05:02 2011 From: gle...@ (Glenn Maynard) Date: Fri, 15 Apr 2011 12:05:02 -0400 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 12:58 AM, Cedric Vivier wrote: > Nice, maybe it would make sense to focus on loss/recovery events for now? > There is consensus on the changes related to these events and it will > be easier to follow discussion and progress. > > The context creation error path and potential asynchronous context > initialization needs a lot more discussion imho, and we'll be able to > easily use the text from the lost/restored events after we are in a > good state with those. > I may just write a first pass defining a reasonable behavior for all of these without waiting for everything to settle, to see how everything might fit together. It'll let us get a sense of how things look when describing them this way. If it doesn't happen to match how things ultimately resolve, it's not a big deal (it'll need refinement no matter what). It might also point out problems for the other discussions to consider. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Apr 15 10:52:24 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 15 Apr 2011 10:52:24 -0700 Subject: [Public WebGL] webglcontextrestored, WEBKIT_lose_context In-Reply-To: References: Message-ID: On Fri, Apr 15, 2011 at 9:05 AM, Glenn Maynard wrote: > On Fri, Apr 15, 2011 at 12:58 AM, Cedric Vivier wrote: >> >> Nice, maybe it would make sense to focus on loss/recovery events for now? >> There is consensus on the changes related to these events and it will >> be easier to follow discussion and progress. >> >> The context creation error path and potential asynchronous context >> initialization needs a lot more discussion imho, and we'll be able to >> easily use the text from the lost/restored events after we are in a >> good state with those. > > I may just write a first pass defining a reasonable behavior for all of > these without waiting for everything to settle, to see how everything might > fit together.? It'll let us get a sense of how things look when describing > them this way.? If it doesn't happen to match how things ultimately resolve, > it's not a big deal (it'll need refinement no matter what).? It might also > point out problems for the other discussions to consider. Glenn, Gregg has a good point; I had forgotten your earlier phrasing of the context loss and recovery behavior. We should fix the specification of these events first. Let's defer updating the context creation error reporting. Asynchronous context creation is a larger discussion and should follow the others. Would you be able to check out the current spec -- see http://khronos.org/webgl/wiki/Demo_Repository for instructions -- and provide diffs making the context loss and recovery event definitions more precise? -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 mar...@ Mon Apr 18 03:43:28 2011 From: mar...@ (Marco Di Benedetto) Date: Mon, 18 Apr 2011 12:43:28 +0200 Subject: [Public WebGL] ANGLE WebGLFramebuffer bug? In-Reply-To: References: Message-ID: <4DAC15D0.1070205@isti.cnr.it> Hi, I think I found a problem concerning framebuffer objects with ANGLE (if you use native OpenGL, it works fine). Basically, if at the end of your draw call you bind a WebGLFramebuffer that is not the main framebuffer ("null"), the page composer (it seems) try to render it on the canvas. Here follows a minimal example: It should display a red canvas. Instead, a blank one appears. Best, Marco. ----------------------------------------------------------- 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 mar...@ Mon Apr 18 09:01:53 2011 From: mar...@ (Marco Di Benedetto) Date: Mon, 18 Apr 2011 18:01:53 +0200 Subject: [Public WebGL] ANGLE WebGLFramebuffer bug? Message-ID: <4DAC6071.8070909@isti.cnr.it> Hi, I think I found a problem concerning framebuffer objects with ANGLE (if you use native OpenGL, it works fine). Basically, if at the end of your draw call you bind a WebGLFramebuffer that is not the main framebuffer ("null"), the page composer (it seems) try to render it on the canvas. Here follows a minimal example: It should display a red canvas. Instead, a blank one appears. Best, Marco. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Mon Apr 18 09:29:03 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 18 Apr 2011 09:29:03 -0700 Subject: [Public WebGL] ANGLE WebGLFramebuffer bug? In-Reply-To: <4DAC15D0.1070205@isti.cnr.it> References: <4DAC15D0.1070205@isti.cnr.it> Message-ID: This is a bug in Chrome, not in ANGLE. Happens in Chrome on OSX but not in FF. On Mon, Apr 18, 2011 at 3:43 AM, Marco Di Benedetto < marco.dibenedetto...@> wrote: > > Hi, > > I think I found a problem concerning framebuffer objects with ANGLE (if you > use native OpenGL, it works fine). > Basically, if at the end of your draw call you bind a WebGLFramebuffer that > is not the main framebuffer ("null"), the page composer (it seems) try to > render it on the canvas. > Here follows a minimal example: > > > > > > > > > > > > It should display a red canvas. Instead, a blank one appears. > > Best, > Marco. > > ----------------------------------------------------------- > 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 zhe...@ Mon Apr 18 10:09:20 2011 From: zhe...@ (Mo, Zhenyao) Date: Mon, 18 Apr 2011 10:09:20 -0700 Subject: [Public WebGL] ANGLE WebGLFramebuffer bug? In-Reply-To: <4DAC15D0.1070205@isti.cnr.it> References: <4DAC15D0.1070205@isti.cnr.it> Message-ID: Thank you for reporting this and providing a nice test case. We are working on it. On Mon, Apr 18, 2011 at 3:43 AM, Marco Di Benedetto wrote: > > Hi, > > I think I found a problem concerning framebuffer objects with ANGLE (if you > use native OpenGL, it works fine). > Basically, if at the end of your draw call you bind a WebGLFramebuffer that > is not the main framebuffer ("null"), the page composer (it seems) try to > render it on the canvas. > Here follows a minimal example: > > > > > > > > > > > > It should display a red canvas. Instead, a blank one appears. > > Best, > Marco. > > ----------------------------------------------------------- > 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 gle...@ Mon Apr 18 12:06:33 2011 From: gle...@ (Glenn Maynard) Date: Mon, 18 Apr 2011 15:06:33 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> Message-ID: Following up from whatwg: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031192.html. To recap, step 6 of getContext ("Return a new object for contextId"), which is where WebGL takes over, was never intended to return null. null isn't a "new object", it's no object. I'd recommend, in line with Cedric's suggestion: - getContext always returns a WebGLRenderingContext, whether the drawing surface can be created or not. - If the drawing surface couldn't be created (where it currently returns null), synchronously dispatch webglcontextlost before getContext returns. - webglcontextcreationerror is dropped; statusMessage is included with webglcontextlost instead. This addresses the getContext API issue. Also, all context creation errors are reported in one place (webglcontextlost), whether it's an initial failure during getContext or a failure later on. These failures are symmetric--they can both happen for the same reasons. The webglcontextlost event stays consistent: preventDefault would allow restoring the context later on if possible, regardless of whether the event was fired by getContext or later on. This will help stop people from implementing ugly retry-getContext timers or "try again!" buttons; if you want to support recovery from initial context failure, just preventDefault the event as you would any other time. (As a bonus, an async initialization API becomes straightforward.) Sample initialization code: var error = null; canvas.addEventListener("webglcontextlost", function(event) { error = event.statusMessage; }, false); var gl = canvas.getContext("webgl"); assert(("WebGLRenderingContext" in window) == (gl != null)); // this is now guaranteed if(gl == null) throw "WebGL is not supported by your browser"; // either initWebGL has already been called or error is set if(gl.isContextLost()) // or if if(error != null) throw "Error initializing WebGL: " + error; // continue initialization On Thu, Apr 14, 2011 at 10:22 AM, Glenn Maynard wrote: > I forgot that this was all still going to whatwg, instead of public-webgl. > We may want to move there. > > > > On Thu, Apr 14, 2011 at 12:33 AM, Glenn Maynard wrote: > >> On Wed, Apr 13, 2011 at 9:01 PM, Kenneth Russell >> wrote:Return a new object for contextId >> >> > Adding support for asynchronous initialization of WebGL is a good >> > idea, and should be proposed on public_webgl, but this discussion >> > should focus solely on improving the specification of the existing >> > synchronous initialization path, and its error conditions. >> >> I only brought it up here because they're related. If an async path >> exists, it can affect the design of the sync path as well. >> >> >> > Given that the proposed asynchronous initialization path above uses >> > webglcontextcreationerror and provides a status message, I think that >> > should continue to be the error reporting mechanism for the current >> > initialization path. >> >> So, the main difference from how it is now would be that getContext would >> return an object, even on fatal errors, since WebGL can't return null from >> context creation. That seems to work, and it does minimize the number of >> things that would need to change for async initialization. It doesn't >> distinguish between "permanent" and "recoverable" errors as we discussed >> earlier, but that might just be overcomplicating things. (If that's wanted >> too, it could be supported by treating preventDefault on the error event the >> same as on the lost event, saying "if it becomes possible to create a >> context later, I'm prepared for it". >> >> User code for this is very simple: >> >> >> var gl = canvas.getContext("webgl"); >> if (!gl) { >> // WebGL is not supported >> } else if (gl.isContextLost()) { >> // WebGL could not be initialized; the error message can be received >> from >> // webglcontextcreationerror (or webglcontextlost) >> } >> >> On Wed, Apr 13, 2011 at 10:53 PM, Cedric Vivier >> wrote: >> > I don't think the added complexity/verbosity provides any advantage >> > over my proposal above (for the applications that even desire to show >> > additional failure information). >> > Is there a scenario I overlooked? >> >> Another advantage of using webglcontextlost is that, if the context >> restoration proposal in the other thread is accepted, you could >> preventDefault during it, just as with any other time the event is >> received. It would tell the browser "if it ever becomes possible to create >> the context in the future, give it to me" (via webglcontextrestored). You >> could do that with *creationerror as well, but it would be duplicate logic. >> >> -- >> Glenn Maynard >> >> > > > -- > Glenn Maynard > > -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Tue Apr 19 04:25:29 2011 From: jda...@ (John Davis) Date: Tue, 19 Apr 2011 06:25:29 -0500 Subject: [Public WebGL] WebCL Message-ID: When will the mailing list go public? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Apr 19 05:17:36 2011 From: bja...@ (Benoit Jacob) Date: Tue, 19 Apr 2011 05:17:36 -0700 (PDT) Subject: [Public WebGL] WebCL In-Reply-To: Message-ID: <1377301503.70891.1303215456873.JavaMail.root@cm-mail03.mozilla.org> I, too, am eagerly waiting for the creation of a public WebCL list. I know at least 3 people working on WebCL-ish stuff who do not have access to the private list. Benoit ----- Original Message ----- When will the mailing list go public? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Apr 19 18:56:02 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Tue, 19 Apr 2011 18:56:02 -0700 Subject: [Public WebGL] preserveDrawingBuffer = false Message-ID: I'd like to suggest that the preserveDrawingBuffer = false spec be revisited. The spec was written so that the drawing buffer is cleared if a compositing operation is done. This was done so that apps would not rely on the contents of the drawing buffer being preserved. Unfortunately it has the opposite effect. Apps are now written to expect the drawing buffer to be cleared. But, the spec does not actually require the drawing buffer to be cleared unless the buffer is composited. So, we have the same situation. Apps expect the drawing buffer to be cleared but depending on the browser, timing, etc there is no guarantee that the buffer was actually composited. If it wasn't the contents is still there. You write some code, it seems to work and only later do you find out that on some slow machine or some specific browser on a specific platform you're getting inconsistent behavior and tracking that down can be really hard (I just got through tracking it down for one app) Would it be possible to change the spec to effectively say If preserveDrawingBuffer is false, then when JavaScript enters a callback if the user does not clear the drawingbuffer before the first draw call the implementation will clear it? This doesn't seem like it would change any of the performance issues nor the effective semantics of the spec but it would make the behavior 100% consistent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Apr 19 19:20:39 2011 From: cal...@ (Mark Callow) Date: Wed, 20 Apr 2011 11:20:39 +0900 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> Message-ID: <4DAE42F7.1000202@hicorp.co.jp> On 19/04/2011 04:06, Glenn Maynard wrote: > Following up from whatwg: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031192.html. > To recap, step 6 of getContext ("Return a new object for contextId"), > which is where WebGL takes over, was never intended to return null. > null isn't a "new object", it's no object. What happens if the context type passed to getContext is not recognized by the browser, e.g., when WebGL is not supported by the browser? > > I'd recommend, in line with Cedric's suggestion: > > - getContext always returns a WebGLRenderingContext, whether the > drawing surface can be created or not. > - If the drawing surface couldn't be created (where it currently > returns null), synchronously dispatch webglcontextlost before > getContext returns. > - webglcontextcreationerror is dropped; statusMessage is included > with webglcontextlost instead. If we go this route, a status message in webglcontextlost is insufficient. Applications that wish to handle webglcontextlost will not want to be parsing strings, especially localized strings, to determine if the browser is refusing to create a context, so there is no possibility of restoration, or if it is a normal context lost event. Some kind of error code will be needed. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From cvi...@ Tue Apr 19 19:35:52 2011 From: cvi...@ (Cedric Vivier) Date: Wed, 20 Apr 2011 10:35:52 +0800 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: <4DAE42F7.1000202@hicorp.co.jp> References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: On Wed, Apr 20, 2011 at 10:20, Mark Callow wrote: > On 19/04/2011 04:06, Glenn Maynard wrote: >> Following up from whatwg: >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031192.html. >> To recap, step 6 of getContext ("Return a new object for contextId"), >> which is where WebGL takes over, was never intended to return null. >> null isn't a "new object", it's no object. > What happens if the context type passed to getContext is not recognized > by the browser, e.g., when WebGL is not supported by the browser? Null is returned, as specified in the Canvas spec. > If we go this route, a status message in webglcontextlost is > insufficient. Applications that wish to handle webglcontextlost will not > want to be parsing strings, especially localized strings, to determine > if the browser is refusing to create a context, so there is no > possibility of restoration, or if it is a normal context lost event. > Some kind of error code will be needed. Yes, I believe adding an isRestorable boolean to the webglcontextlost event would help to differentiate between a permanent or transient error. statusMessage should be used for display only and should never have to be parsed. To make sure it does not get abused *and* to let browsers give better diagnostic to users, we might even want to get rid of it, if the browser actually has useful failure information to provide, it could expose it in a more useful/consistent way to the user directly. Regards, ----------------------------------------------------------- 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...@ Thu Apr 21 03:25:06 2011 From: cal...@ (Mark Callow) Date: Thu, 21 Apr 2011 19:25:06 +0900 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) Message-ID: <4DB00602.5000002@hicorp.co.jp> Hi, Because I keep needing to do it, I have become irritated by the lack of a function in the typed array specification do copy the partial contents of a JS source array, something like: void /set/(/type/[] array, optional unsigned long offset, unsigned long srcOffset, unsigned long count) The obvious answer is a wrapper but I suspected that a loop of, e.g, i16array[i] = src[i] in JS would be slower than something internal to the typed array implementation. I wrote a short test for this. The result on FF4 is as I expected: Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 bytes/second). Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 bytes/second). Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 bytes/second). Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 bytes/second). To ensure the result is not influenced by smart optimizers the test is repeated with a longer array and a single iteration. The bytes copied is the same in each case. The "wrapper" runs at one quarter the speed of a native implementation so I think the above described set function is a badly needed addition to typed arrays. If the source is a typed array, one can always create another view or subarray so it is not so important to add a new function for this case, though there is the issue of the garbage that must then be collected. When I ran the same test on Chromium 12.0.717.0 (79525) I got a very surprising result: Int16Array.set(2000 byte array) x 100 times took 49ms (8163265.306122449 bytes/second). Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 bytes/second). Int16Array.set(200000 byte array) x 1 times took 38ms (10526315.789473685 bytes/second). Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666 bytes/second). It is surprising for 3 reasons: * the overall poor performance * the fact that the Int16Array.set takes longer than a JS loop setting individual elements * the fact that a single loop of 200,000 setting individual elements took 4 times longer than a double loop of 100 x 2000. The test is attached. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From ben...@ Thu Apr 21 11:57:48 2011 From: ben...@ (Ben Vanik) Date: Thu, 21 Apr 2011 11:57:48 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: <4DB00602.5000002@hicorp.co.jp> References: <4DB00602.5000002@hicorp.co.jp> Message-ID: I agree this method would be really helpful. If the offset/count values were in bytes, it would allow for some awesome uses of typed arrays. The primary use case that comes to mind is packed data transfer. I've been experimenting with loading geometry/textures/etc from data blobs, and being able to subset the data efficiently (without using views, as I want an actual copy for modification) would make things much nicer. The other side of this is using it to construct data blobs - saving off content from client->server that contains large typed array chunks would greatly benefit from the speed boost. And as a nodejs user, this would be a tremendously useful thing when using protocol buffers and other sorts of binary message formats where perf really matters or doing large file system manipulations. As for the microbenchmarks, I've noticed the same thing. I just whipped this one up yesterday for testing out some common patterns I need for image processing: http://jsperf.com/typed-arrays-vs-arrays The time for creating and initializing a JS array is two orders of magnitude longer than for typed arrays, but all other operations are 2x+ faster than typed arrays. I threw in CanvasPixelArray just to see if there were any special optimizations there - it's pretty much the same as Uint8Array (which makes sense). Here's a great blog post on perf comparison that just came out: http://blog.n01se.net/?p=248 -- Ben Vanik http://www.noxa.org 2011/4/21 Mark Callow > Hi, > > Because I keep needing to do it, I have become irritated by the lack of a > function in the typed array specification do copy the partial contents of a > JS source array, something like: > > void *set*(*type*[] array, optional unsigned long offset, unsigned > long srcOffset, unsigned long count) > > The obvious answer is a wrapper but I suspected that a loop of, e.g, > i16array[i] = src[i] in JS would be slower than something internal to the > typed array implementation. I wrote a short test for this. The result on FF4 > is as I expected: > > Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 > bytes/second). > > Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 bytes/second). > > Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 > bytes/second). > > Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 bytes/second). > > To ensure the result is not influenced by smart optimizers the test is > repeated with a longer array and a single iteration. The bytes copied is the > same in each case. > > The "wrapper" runs at one quarter the speed of a native implementation so I > think the above described set function is a badly needed addition to typed > arrays. > > If the source is a typed array, one can always create another view or > subarray so it is not so important to add a new function for this case, > though there is the issue of the garbage that must then be collected. > > When I ran the same test on Chromium 12.0.717.0 (79525) I got a very > surprising result: > > Int16Array.set(2000 byte array) x 100 times took 49ms (8163265.306122449 > bytes/second). > > Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 > bytes/second). > > Int16Array.set(200000 byte array) x 1 times took 38ms (10526315.789473685 > bytes/second). > > Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666 > bytes/second). > > It is surprising for 3 reasons: > > - the overall poor performance > - the fact that the Int16Array.set takes longer than a JS loop setting > individual elements > - the fact that a single loop of 200,000 setting individual elements > took 4 times longer than a double loop of 100 x 2000. > > The test is attached. > > Regards > > -Mark > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Thu Apr 21 14:20:55 2011 From: ben...@ (Ben Vanik) Date: Thu, 21 Apr 2011 14:20:55 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: A few different people have mailed me off-list about the little benchmark, so I thought I'd share some notes here: As pointed out by a commenter on the linked blog post, v8 only optimizes typed arrays if you only call a method that uses them with typed arrays and never with js arrays. This has implications for benchmarks, as most will reuse code in their tests (like the microbenchmark I linked did). Here's a test showing this behavior: http://jsperf.com/fast-typed-arrays On Chrome 12, the difference in this behavior makes typed arrays go from appearing 2x slower than native arrays to 2x faster. Hopefully this gets fixed in the future, but for now this is important to keep in mind when profiling. An updated version of the microbenchmark I linked earlier: http://jsperf.com/typed-arrays-vs-arrays/4 Now, Uint8Array is significantly faster than js native arrays (and interestingly, faster than CanvasPixelArray). Also, these seem to crash certain versions of Chrome on Linux and OSX. That's... scary. -- Ben Vanik http://www.noxa.org On Thu, Apr 21, 2011 at 11:57 AM, Ben Vanik wrote: > I agree this method would be really helpful. If the offset/count values > were in bytes, it would allow for some awesome uses of typed arrays. > > The primary use case that comes to mind is packed data transfer. I've been > experimenting with loading geometry/textures/etc from data blobs, and being > able to subset the data efficiently (without using views, as I want an > actual copy for modification) would make things much nicer. The other side > of this is using it to construct data blobs - saving off content from > client->server that contains large typed array chunks would greatly benefit > from the speed boost. > > And as a nodejs user, this would be a tremendously useful thing when using > protocol buffers and other sorts of binary message formats where perf really > matters or doing large file system manipulations. > > As for the microbenchmarks, I've noticed the same thing. I just whipped > this one up yesterday for testing out some common patterns I need for image > processing: > http://jsperf.com/typed-arrays-vs-arrays > The time for creating and initializing a JS array is two orders of > magnitude longer than for typed arrays, but all other operations are 2x+ > faster than typed arrays. > I threw in CanvasPixelArray just to see if there were any > special optimizations there - it's pretty much the same as Uint8Array (which > makes sense). > Here's a great blog post on perf comparison that just came out: > http://blog.n01se.net/?p=248 > > -- > Ben Vanik > http://www.noxa.org > > > > 2011/4/21 Mark Callow > >> Hi, >> >> Because I keep needing to do it, I have become irritated by the lack of a >> function in the typed array specification do copy the partial contents of a >> JS source array, something like: >> >> void *set*(*type*[] array, optional unsigned long offset, unsigned >> long srcOffset, unsigned long count) >> >> The obvious answer is a wrapper but I suspected that a loop of, e.g, >> i16array[i] = src[i] in JS would be slower than something internal to the >> typed array implementation. I wrote a short test for this. The result on FF4 >> is as I expected: >> >> Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 >> bytes/second). >> >> Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 >> bytes/second). >> >> Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 >> bytes/second). >> >> Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 >> bytes/second). >> >> To ensure the result is not influenced by smart optimizers the test is >> repeated with a longer array and a single iteration. The bytes copied is the >> same in each case. >> >> The "wrapper" runs at one quarter the speed of a native implementation so >> I think the above described set function is a badly needed addition to typed >> arrays. >> >> If the source is a typed array, one can always create another view or >> subarray so it is not so important to add a new function for this case, >> though there is the issue of the garbage that must then be collected. >> >> When I ran the same test on Chromium 12.0.717.0 (79525) I got a very >> surprising result: >> >> Int16Array.set(2000 byte array) x 100 times took 49ms (8163265.306122449 >> bytes/second). >> >> Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 >> bytes/second). >> >> Int16Array.set(200000 byte array) x 1 times took 38ms (10526315.789473685 >> bytes/second). >> >> Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666 >> bytes/second). >> >> It is surprising for 3 reasons: >> >> - the overall poor performance >> - the fact that the Int16Array.set takes longer than a JS loop setting >> individual elements >> - the fact that a single loop of 200,000 setting individual elements >> took 4 times longer than a double loop of 100 x 2000. >> >> The test is attached. >> >> Regards >> >> -Mark >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 21 15:25:43 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 21 Apr 2011 15:25:43 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: Mark: the poor performance of the set(Array, offset) variant in Chromium is surprising, and I would encourage you to file a bug about it. However, in an optimizing JavaScript VM, writing the associated JavaScript code to do these sorts of operations will be faster than adding another built-in, because in the former case the JIT has a chance to generate specialized code, and in the latter case you're calling in to and out of the VM's runtime system (typically written in C++) which can't perform the same sorts of optimizations. I am not personally convinced that we should add this new entry point. Especially in low-level APIs like typed arrays, every new one has a high maintenance cost. Also, there are API changes lined up which will address known performance bottlenecks on the web platform that I think should take priority. Ben: since it sounds like you are doing network I/O, should you be using DataView instead of the typed array view types? -Ken On Thu, Apr 21, 2011 at 11:57 AM, Ben Vanik wrote: > I agree this method would be really helpful. If the offset/count values were > in bytes, it would allow for some awesome uses of typed arrays. > The primary use case that comes to mind is packed data transfer. I've been > experimenting with loading geometry/textures/etc from data blobs, and being > able to subset the data efficiently (without using views, as I want an > actual copy for modification) would make things much nicer. The other side > of this is using it to construct data blobs - saving off content from > client->server that contains large typed array chunks would greatly benefit > from the speed boost. > And as a nodejs user, this would be a tremendously useful thing when using > protocol buffers and other sorts of binary message formats where perf really > matters or doing large file system manipulations. > As for the microbenchmarks, I've noticed the same thing. I just whipped this > one up yesterday for testing out some common patterns I need for image > processing: > http://jsperf.com/typed-arrays-vs-arrays > The time for creating and initializing a JS array is two orders of magnitude > longer than for typed arrays, but all other operations are 2x+ faster than > typed arrays. > I threw in CanvasPixelArray just to see if there were any > special?optimizations?there - it's pretty much the same as Uint8Array (which > makes sense). > Here's a great blog post on perf comparison that just came > out:?http://blog.n01se.net/?p=248 > -- > Ben Vanik > http://www.noxa.org > > > 2011/4/21 Mark Callow >> >> Hi, >> >> Because I keep needing to do it, I have become irritated by the lack of a >> function in the typed array specification do copy the partial contents of a >> JS source array, something like: >> >> ???? void set(type[] array, optional unsigned long offset, unsigned long >> srcOffset, unsigned long count) >> >> The obvious answer is a wrapper but I suspected that a loop of, e.g, >> i16array[i] = src[i] in JS would be slower than something internal to the >> typed array implementation. I wrote a short test for this. The result on FF4 >> is as I expected: >> >> Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 >> bytes/second). >> >> Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 >> bytes/second). >> >> Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 >> bytes/second). >> >> Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 >> bytes/second). >> >> To ensure the result is not influenced by smart optimizers the test is >> repeated with a longer array and a single iteration. The bytes copied is the >> same in each case. >> >> The "wrapper" runs at one quarter the speed of a native implementation so >> I think the above described set function is a badly needed addition to typed >> arrays. >> >> If the source is a typed array, one can always create another view or >> subarray so it is not so important to add a new function for this case, >> though there is the issue of the garbage that must then be collected. >> >> When I ran the same test on Chromium 12.0.717.0 (79525) I got a very >> surprising result: >> >> Int16Array.set(2000 byte array) x 100 times took 49ms (8163265.306122449 >> bytes/second). >> >> Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 >> bytes/second). >> >> Int16Array.set(200000 byte array) x 1 times took 38ms (10526315.789473685 >> bytes/second). >> >> Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666 >> bytes/second). >> >> It is surprising for 3 reasons: >> >> the overall poor performance >> the fact that the Int16Array.set takes longer than a JS loop setting >> individual elements >> the fact that a single loop of 200,000 setting individual elements took 4 >> times longer than a double loop of 100 x 2000. >> >> The test is attached. >> >> Regards >> >> -Mark >> >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Apr 21 15:56:17 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 21 Apr 2011 15:56:17 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: On Tue, Apr 19, 2011 at 7:35 PM, Cedric Vivier wrote: > > On Wed, Apr 20, 2011 at 10:20, Mark Callow wrote: >> On 19/04/2011 04:06, Glenn Maynard wrote: >>> Following up from whatwg: >>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031192.html. >>> To recap, step 6 of getContext ("Return a new object for contextId"), >>> which is where WebGL takes over, was never intended to return null. >>> null isn't a "new object", it's no object. >> What happens if the context type passed to getContext is not recognized >> by the browser, e.g., when WebGL is not supported by the browser? > > Null is returned, as specified in the Canvas spec. > >> If we go this route, a status message in webglcontextlost is >> insufficient. Applications that wish to handle webglcontextlost will not >> want to be parsing strings, especially localized strings, to determine >> if the browser is refusing to create a context, so there is no >> possibility of restoration, or if it is a normal context lost event. >> Some kind of error code will be needed. > > Yes, I believe adding an isRestorable boolean to the webglcontextlost > event would help to differentiate between a permanent or transient > error. > > statusMessage should be used for display only and should never have to > be parsed. > To make sure it does not get abused *and* to let browsers give better > diagnostic to users, we might even want to get rid of it, if the > browser actually has useful failure information to provide, it could > expose it in a more useful/consistent way to the user directly. I wonder whether it would be an improvement if Canvas's getContext() algorithm admitted the possibility of an exception being thrown during context creation. As it stands, every new context type which has the possibility of failing to initialize has to define its own, callback-based, error reporting mechanism. Maybe this isn't that big a deal, because these context types might have to deal with "lost" contexts like WebGL does. This comment aside, the semantic change to return a non-null context when an error condition occurs sounds acceptable to me. I'm not completely happy with it, because I think that it will make error detection harder for the developer. I think we should gather more feedback, in particular from other browser vendors on the working group, before committing to make this change. Note that existing WebGL content is going to have to be updated to deal with this change, in order to continue to properly detect the situation when the graphics card is blacklisted. If we proceed with this change, I agree that we need an indication that the failure was not recoverable, so that the application can display appropriate UI to the end user. Adding a boolean to the webglcontextlost event seems somewhat like a hack, because it essentially changes the meaning of the event to exactly that of webglcontextcreationerror. Does anyone have an alternative idea? Subclassing the event type? Continuing to use a different kind of event listener? If there's no better suggestion then it sounds okay. Additionally, if we proceed with this change, I do not support the removal of the statusMessage. As an implementor of WebGL, I require the ability to provide some information to application developers (which might end up being sent back in in bug reports) when for some reason WebGL could not initialize. -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 ben...@ Thu Apr 21 15:58:38 2011 From: ben...@ (Ben Vanik) Date: Thu, 21 Apr 2011 15:58:38 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: Yep - DataView is useful for reading out headers and other things, but if you have content inside your messages it's not suitable. Say I had a large command buffer in wire format - a bunch of commands (small, binary serialized messages) and interspersed in there is some data (large blobs). Reading the commands is easy - new up a DataView on the source buffer and start reading them out. The trouble is the blobs - I don't want to put a view onto the source buffer for the blob as then if I keep the blob around the entire source buffer will stay in memory. If not careful, one could end up keeping around thousands of potentially large buffers if they used subarray. As apps get larger and are passing around typed arrays to various pieces of code this is likely to happen. Instead I have to allocate a new array and manually copy the values. So maybe I guess what I really want is a slice, which is different than what Mark mentioned (which is essentially a memcpy). A proper slice would be ideal, as then you could slice the blob and create a whole bunch of new views on it, having the backing store now separate from the source. I absolutely love that typed arrays has the concept of views, as gc is a big perf problem in high performance js right now and being able to prevent extra garbage in most cases is great. That said, however, sometimes you just really need a copy. A slice operation is something that would make sense from a performance perspective, as a single call to the runtime to new and copy the data should always be faster than a new and then an copy. Plus, if js code can be faster than the system memcpy, the system memcpy must really suck ;) All that said, when working with large blobs things like memcpy are really handy - having a nice generalized way to do that (in Mark's suggestion, an overload of set) would be a useful primitive. Of course, it's pretty easy to build function memcpy() {}, and if there really is no perf benefit then meh. Only one way to find out! -- Ben Vanik http://www.noxa.org On Thu, Apr 21, 2011 at 3:25 PM, Kenneth Russell wrote: > Mark: the poor performance of the set(Array, offset) variant in > Chromium is surprising, and I would encourage you to file a bug about > it. However, in an optimizing JavaScript VM, writing the associated > JavaScript code to do these sorts of operations will be faster than > adding another built-in, because in the former case the JIT has a > chance to generate specialized code, and in the latter case you're > calling in to and out of the VM's runtime system (typically written in > C++) which can't perform the same sorts of optimizations. > > I am not personally convinced that we should add this new entry point. > Especially in low-level APIs like typed arrays, every new one has a > high maintenance cost. Also, there are API changes lined up which will > address known performance bottlenecks on the web platform that I think > should take priority. > > Ben: since it sounds like you are doing network I/O, should you be > using DataView instead of the typed array view types? > > -Ken > > On Thu, Apr 21, 2011 at 11:57 AM, Ben Vanik wrote: > > I agree this method would be really helpful. If the offset/count values > were > > in bytes, it would allow for some awesome uses of typed arrays. > > The primary use case that comes to mind is packed data transfer. I've > been > > experimenting with loading geometry/textures/etc from data blobs, and > being > > able to subset the data efficiently (without using views, as I want an > > actual copy for modification) would make things much nicer. The other > side > > of this is using it to construct data blobs - saving off content from > > client->server that contains large typed array chunks would greatly > benefit > > from the speed boost. > > And as a nodejs user, this would be a tremendously useful thing when > using > > protocol buffers and other sorts of binary message formats where perf > really > > matters or doing large file system manipulations. > > As for the microbenchmarks, I've noticed the same thing. I just whipped > this > > one up yesterday for testing out some common patterns I need for image > > processing: > > http://jsperf.com/typed-arrays-vs-arrays > > The time for creating and initializing a JS array is two orders of > magnitude > > longer than for typed arrays, but all other operations are 2x+ faster > than > > typed arrays. > > I threw in CanvasPixelArray just to see if there were any > > special optimizations there - it's pretty much the same as Uint8Array > (which > > makes sense). > > Here's a great blog post on perf comparison that just came > > out: http://blog.n01se.net/?p=248 > > -- > > Ben Vanik > > http://www.noxa.org > > > > > > 2011/4/21 Mark Callow > >> > >> Hi, > >> > >> Because I keep needing to do it, I have become irritated by the lack of > a > >> function in the typed array specification do copy the partial contents > of a > >> JS source array, something like: > >> > >> void set(type[] array, optional unsigned long offset, unsigned long > >> srcOffset, unsigned long count) > >> > >> The obvious answer is a wrapper but I suspected that a loop of, e.g, > >> i16array[i] = src[i] in JS would be slower than something internal to > the > >> typed array implementation. I wrote a short test for this. The result on > FF4 > >> is as I expected: > >> > >> Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 > >> bytes/second). > >> > >> Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 > >> bytes/second). > >> > >> Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 > >> bytes/second). > >> > >> Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 > >> bytes/second). > >> > >> To ensure the result is not influenced by smart optimizers the test is > >> repeated with a longer array and a single iteration. The bytes copied is > the > >> same in each case. > >> > >> The "wrapper" runs at one quarter the speed of a native implementation > so > >> I think the above described set function is a badly needed addition to > typed > >> arrays. > >> > >> If the source is a typed array, one can always create another view or > >> subarray so it is not so important to add a new function for this case, > >> though there is the issue of the garbage that must then be collected. > >> > >> When I ran the same test on Chromium 12.0.717.0 (79525) I got a very > >> surprising result: > >> > >> Int16Array.set(2000 byte array) x 100 times took 49ms (8163265.306122449 > >> bytes/second). > >> > >> Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 > >> bytes/second). > >> > >> Int16Array.set(200000 byte array) x 1 times took 38ms > (10526315.789473685 > >> bytes/second). > >> > >> Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666 > >> bytes/second). > >> > >> It is surprising for 3 reasons: > >> > >> the overall poor performance > >> the fact that the Int16Array.set takes longer than a JS loop setting > >> individual elements > >> the fact that a single loop of 200,000 setting individual elements took > 4 > >> times longer than a double loop of 100 x 2000. > >> > >> The test is attached. > >> > >> Regards > >> > >> -Mark > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 21 16:12:33 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 21 Apr 2011 16:12:33 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: On Thu, Apr 21, 2011 at 3:58 PM, Ben Vanik wrote: > Yep - DataView is useful for reading out headers and other things, but if > you have content inside your messages it's not suitable. > Say I had a large command buffer in wire format - a bunch of commands > (small, binary serialized messages) and interspersed in there is some data > (large blobs). Reading the commands is easy - new up a DataView on the > source buffer and start reading them out. The trouble is the blobs - I don't > want to put a view onto the source buffer for the blob as then if I keep the > blob around the entire source buffer will stay in memory. Presumably the blobs are some sort of binary data that are being uploaded directly to the graphics card? In this case, it is essential that the endianness of the data sent over the network match that of the host. You can certainly optimize this in your application and server, but the DataView was designed for this use case, not the typed array views. > If not careful, > one could end up keeping around thousands of potentially large buffers if > they used subarray. As apps get larger and are passing around typed arrays > to various?pieces?of code this is likely to happen.?Instead I have to > allocate a new array and manually copy the values. > So maybe I guess what I really want is a slice, which is different than what > Mark mentioned (which is essentially a memcpy).?A proper slice would be > ideal, as then you could slice the blob and create a whole bunch of new > views on it, having the backing store now separate from the source. I > absolutely love that typed arrays has the concept of views, as gc is a big > perf problem in high performance js right now and being able to prevent > extra garbage in most cases is great. That said, however, sometimes you just > really need a copy. > A slice operation is something that would make sense from a performance > perspective, as a single call to the runtime to new and copy the data should > always be faster than a new and then an copy. Plus, if js code can be faster > than the system memcpy, the system memcpy must really suck ;) > All that said, when working with large blobs things like memcpy are really > handy - having a nice generalized way to do that (in Mark's suggestion, an > overload of set) would be a useful primitive. Of course, it's pretty easy to > build function memcpy() {}, and if there really is no perf benefit then meh. > Only one way to find out! As part of the planned Typed Array API changes to support efficient communication with web workers, the plan is to add convenience methods to copy ArrayBuffers and possibly sub-portions of them. I think we should invest our time in moving those changes forward. -Ken > -- > Ben Vanik > http://www.noxa.org > > > On Thu, Apr 21, 2011 at 3:25 PM, Kenneth Russell wrote: >> >> Mark: the poor performance of the set(Array, offset) variant in >> Chromium is surprising, and I would encourage you to file a bug about >> it. However, in an optimizing JavaScript VM, writing the associated >> JavaScript code to do these sorts of operations will be faster than >> adding another built-in, because in the former case the JIT has a >> chance to generate specialized code, and in the latter case you're >> calling in to and out of the VM's runtime system (typically written in >> C++) which can't perform the same sorts of optimizations. >> >> I am not personally convinced that we should add this new entry point. >> Especially in low-level APIs like typed arrays, every new one has a >> high maintenance cost. Also, there are API changes lined up which will >> address known performance bottlenecks on the web platform that I think >> should take priority. >> >> Ben: since it sounds like you are doing network I/O, should you be >> using DataView instead of the typed array view types? >> >> -Ken >> >> On Thu, Apr 21, 2011 at 11:57 AM, Ben Vanik wrote: >> > I agree this method would be really helpful. If the offset/count values >> > were >> > in bytes, it would allow for some awesome uses of typed arrays. >> > The primary use case that comes to mind is packed data transfer. I've >> > been >> > experimenting with loading geometry/textures/etc from data blobs, and >> > being >> > able to subset the data efficiently (without using views, as I want an >> > actual copy for modification) would make things much nicer. The other >> > side >> > of this is using it to construct data blobs - saving off content from >> > client->server that contains large typed array chunks would greatly >> > benefit >> > from the speed boost. >> > And as a nodejs user, this would be a tremendously useful thing when >> > using >> > protocol buffers and other sorts of binary message formats where perf >> > really >> > matters or doing large file system manipulations. >> > As for the microbenchmarks, I've noticed the same thing. I just whipped >> > this >> > one up yesterday for testing out some common patterns I need for image >> > processing: >> > http://jsperf.com/typed-arrays-vs-arrays >> > The time for creating and initializing a JS array is two orders of >> > magnitude >> > longer than for typed arrays, but all other operations are 2x+ faster >> > than >> > typed arrays. >> > I threw in CanvasPixelArray just to see if there were any >> > special?optimizations?there - it's pretty much the same as Uint8Array >> > (which >> > makes sense). >> > Here's a great blog post on perf comparison that just came >> > out:?http://blog.n01se.net/?p=248 >> > -- >> > Ben Vanik >> > http://www.noxa.org >> > >> > >> > 2011/4/21 Mark Callow >> >> >> >> Hi, >> >> >> >> Because I keep needing to do it, I have become irritated by the lack of >> >> a >> >> function in the typed array specification do copy the partial contents >> >> of a >> >> JS source array, something like: >> >> >> >> ???? void set(type[] array, optional unsigned long offset, unsigned >> >> long >> >> srcOffset, unsigned long count) >> >> >> >> The obvious answer is a wrapper but I suspected that a loop of, e.g, >> >> i16array[i] = src[i] in JS would be slower than something internal to >> >> the >> >> typed array implementation. I wrote a short test for this. The result >> >> on FF4 >> >> is as I expected: >> >> >> >> Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 >> >> bytes/second). >> >> >> >> Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 >> >> bytes/second). >> >> >> >> Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 >> >> bytes/second). >> >> >> >> Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 >> >> bytes/second). >> >> >> >> To ensure the result is not influenced by smart optimizers the test is >> >> repeated with a longer array and a single iteration. The bytes copied >> >> is the >> >> same in each case. >> >> >> >> The "wrapper" runs at one quarter the speed of a native implementation >> >> so >> >> I think the above described set function is a badly needed addition to >> >> typed >> >> arrays. >> >> >> >> If the source is a typed array, one can always create another view or >> >> subarray so it is not so important to add a new function for this case, >> >> though there is the issue of the garbage that must then be collected. >> >> >> >> When I ran the same test on Chromium 12.0.717.0 (79525) I got a very >> >> surprising result: >> >> >> >> Int16Array.set(2000 byte array) x 100 times took 49ms >> >> (8163265.306122449 >> >> bytes/second). >> >> >> >> Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 >> >> bytes/second). >> >> >> >> Int16Array.set(200000 byte array) x 1 times took 38ms >> >> (10526315.789473685 >> >> bytes/second). >> >> >> >> Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666 >> >> bytes/second). >> >> >> >> It is surprising for 3 reasons: >> >> >> >> the overall poor performance >> >> the fact that the Int16Array.set takes longer than a JS loop setting >> >> individual elements >> >> the fact that a single loop of 200,000 setting individual elements took >> >> 4 >> >> times longer than a double loop of 100 x 2000. >> >> >> >> The test is attached. >> >> >> >> Regards >> >> >> >> -Mark >> >> >> >> >> > >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Thu Apr 21 16:13:59 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 21 Apr 2011 16:13:59 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: So I just want to throw this out there but what if we weren't limited by the current design and started from scratch? I'm not saying we should start from scratch, rather I think we should explore other solutions and see where they take us. For example, starting up WebGL can be very slow. Because the API is currently synchronous this pretty much freezes the browser or at least the page it's on until that startup is finished. While always returning a non-NULL webgl object and handling webglcontextlost and/or webglcontextcreationerror would solve that problem they seem like a really around about way to go at it. function handleContextLost(event) { event.preventDefault(true); // If I don't do this then I'll never get a usable context } function handleContextRestored(event) { initMyApp(); } canvas.addEventListenter("webglcontextlost", handleContextLost, ...); canvas.addEventListenter("webglcontextrestored", handleContextRestored, ...); gl = canvas.getContext("webgl"); return; // because I can't actually run until I get webglcontextrestored Maybe that makes sense. Maybe not? How about more XHR like? gl = canvas.getContext("webgl"); gl.oncontextrestored = handleContextRestored; gl.oncotnextlost = handleContextLost; gl.init(); return; I guess it's 6 of one, half dozen of another. It just seems in either case it's pretty convoluted on how you have to use it. I wish I could think of a non-convoluted way :-( -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Thu Apr 21 16:16:23 2011 From: ben...@ (Ben Vanik) Date: Thu, 21 Apr 2011 16:16:23 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: That sounds great. I can't wait to see those changes! The primary performance issues I've been dealing with involve long GCs causing dropped frames and long processing time on streaming data loads. Being able to shift processing to worker threads without creating more garbage would really allow for the quality bar to bump up a bit. Dropped frames = death! -- Ben Vanik http://www.noxa.org On Thu, Apr 21, 2011 at 4:12 PM, Kenneth Russell wrote: > On Thu, Apr 21, 2011 at 3:58 PM, Ben Vanik wrote: > > Yep - DataView is useful for reading out headers and other things, but if > > you have content inside your messages it's not suitable. > > Say I had a large command buffer in wire format - a bunch of commands > > (small, binary serialized messages) and interspersed in there is some > data > > (large blobs). Reading the commands is easy - new up a DataView on the > > source buffer and start reading them out. The trouble is the blobs - I > don't > > want to put a view onto the source buffer for the blob as then if I keep > the > > blob around the entire source buffer will stay in memory. > > Presumably the blobs are some sort of binary data that are being > uploaded directly to the graphics card? In this case, it is essential > that the endianness of the data sent over the network match that of > the host. You can certainly optimize this in your application and > server, but the DataView was designed for this use case, not the typed > array views. > > > If not careful, > > one could end up keeping around thousands of potentially large buffers if > > they used subarray. As apps get larger and are passing around typed > arrays > > to various pieces of code this is likely to happen. Instead I have to > > allocate a new array and manually copy the values. > > So maybe I guess what I really want is a slice, which is different than > what > > Mark mentioned (which is essentially a memcpy). A proper slice would be > > ideal, as then you could slice the blob and create a whole bunch of new > > views on it, having the backing store now separate from the source. I > > absolutely love that typed arrays has the concept of views, as gc is a > big > > perf problem in high performance js right now and being able to prevent > > extra garbage in most cases is great. That said, however, sometimes you > just > > really need a copy. > > A slice operation is something that would make sense from a performance > > perspective, as a single call to the runtime to new and copy the data > should > > always be faster than a new and then an copy. Plus, if js code can be > faster > > than the system memcpy, the system memcpy must really suck ;) > > All that said, when working with large blobs things like memcpy are > really > > handy - having a nice generalized way to do that (in Mark's suggestion, > an > > overload of set) would be a useful primitive. Of course, it's pretty easy > to > > build function memcpy() {}, and if there really is no perf benefit then > meh. > > Only one way to find out! > > As part of the planned Typed Array API changes to support efficient > communication with web workers, the plan is to add convenience methods > to copy ArrayBuffers and possibly sub-portions of them. I think we > should invest our time in moving those changes forward. > > -Ken > > > -- > > Ben Vanik > > http://www.noxa.org > > > > > > On Thu, Apr 21, 2011 at 3:25 PM, Kenneth Russell wrote: > >> > >> Mark: the poor performance of the set(Array, offset) variant in > >> Chromium is surprising, and I would encourage you to file a bug about > >> it. However, in an optimizing JavaScript VM, writing the associated > >> JavaScript code to do these sorts of operations will be faster than > >> adding another built-in, because in the former case the JIT has a > >> chance to generate specialized code, and in the latter case you're > >> calling in to and out of the VM's runtime system (typically written in > >> C++) which can't perform the same sorts of optimizations. > >> > >> I am not personally convinced that we should add this new entry point. > >> Especially in low-level APIs like typed arrays, every new one has a > >> high maintenance cost. Also, there are API changes lined up which will > >> address known performance bottlenecks on the web platform that I think > >> should take priority. > >> > >> Ben: since it sounds like you are doing network I/O, should you be > >> using DataView instead of the typed array view types? > >> > >> -Ken > >> > >> On Thu, Apr 21, 2011 at 11:57 AM, Ben Vanik > wrote: > >> > I agree this method would be really helpful. If the offset/count > values > >> > were > >> > in bytes, it would allow for some awesome uses of typed arrays. > >> > The primary use case that comes to mind is packed data transfer. I've > >> > been > >> > experimenting with loading geometry/textures/etc from data blobs, and > >> > being > >> > able to subset the data efficiently (without using views, as I want an > >> > actual copy for modification) would make things much nicer. The other > >> > side > >> > of this is using it to construct data blobs - saving off content from > >> > client->server that contains large typed array chunks would greatly > >> > benefit > >> > from the speed boost. > >> > And as a nodejs user, this would be a tremendously useful thing when > >> > using > >> > protocol buffers and other sorts of binary message formats where perf > >> > really > >> > matters or doing large file system manipulations. > >> > As for the microbenchmarks, I've noticed the same thing. I just > whipped > >> > this > >> > one up yesterday for testing out some common patterns I need for image > >> > processing: > >> > http://jsperf.com/typed-arrays-vs-arrays > >> > The time for creating and initializing a JS array is two orders of > >> > magnitude > >> > longer than for typed arrays, but all other operations are 2x+ faster > >> > than > >> > typed arrays. > >> > I threw in CanvasPixelArray just to see if there were any > >> > special optimizations there - it's pretty much the same as Uint8Array > >> > (which > >> > makes sense). > >> > Here's a great blog post on perf comparison that just came > >> > out: http://blog.n01se.net/?p=248 > >> > -- > >> > Ben Vanik > >> > http://www.noxa.org > >> > > >> > > >> > 2011/4/21 Mark Callow > >> >> > >> >> Hi, > >> >> > >> >> Because I keep needing to do it, I have become irritated by the lack > of > >> >> a > >> >> function in the typed array specification do copy the partial > contents > >> >> of a > >> >> JS source array, something like: > >> >> > >> >> void set(type[] array, optional unsigned long offset, unsigned > >> >> long > >> >> srcOffset, unsigned long count) > >> >> > >> >> The obvious answer is a wrapper but I suspected that a loop of, e.g, > >> >> i16array[i] = src[i] in JS would be slower than something internal to > >> >> the > >> >> typed array implementation. I wrote a short test for this. The result > >> >> on FF4 > >> >> is as I expected: > >> >> > >> >> Int16Array.set(2000 byte array) x 100 times took 1ms (400000000 > >> >> bytes/second). > >> >> > >> >> Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000 > >> >> bytes/second). > >> >> > >> >> Int16Array.set(200000 byte array) x 1 times took 1ms (400000000 > >> >> bytes/second). > >> >> > >> >> Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000 > >> >> bytes/second). > >> >> > >> >> To ensure the result is not influenced by smart optimizers the test > is > >> >> repeated with a longer array and a single iteration. The bytes copied > >> >> is the > >> >> same in each case. > >> >> > >> >> The "wrapper" runs at one quarter the speed of a native > implementation > >> >> so > >> >> I think the above described set function is a badly needed addition > to > >> >> typed > >> >> arrays. > >> >> > >> >> If the source is a typed array, one can always create another view or > >> >> subarray so it is not so important to add a new function for this > case, > >> >> though there is the issue of the garbage that must then be collected. > >> >> > >> >> When I ran the same test on Chromium 12.0.717.0 (79525) I got a very > >> >> surprising result: > >> >> > >> >> Int16Array.set(2000 byte array) x 100 times took 49ms > >> >> (8163265.306122449 > >> >> bytes/second). > >> >> > >> >> Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664 > >> >> bytes/second). > >> >> > >> >> Int16Array.set(200000 byte array) x 1 times took 38ms > >> >> (10526315.789473685 > >> >> bytes/second). > >> >> > >> >> Int16Array[j] = data[j] 200000 x 1 times took 24ms > (16666666.666666666 > >> >> bytes/second). > >> >> > >> >> It is surprising for 3 reasons: > >> >> > >> >> the overall poor performance > >> >> the fact that the Int16Array.set takes longer than a JS loop setting > >> >> individual elements > >> >> the fact that a single loop of 200,000 setting individual elements > took > >> >> 4 > >> >> times longer than a double loop of 100 x 2000. > >> >> > >> >> The test is attached. > >> >> > >> >> Regards > >> >> > >> >> -Mark > >> >> > >> >> > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Thu Apr 21 19:41:06 2011 From: cal...@ (Mark Callow) Date: Fri, 22 Apr 2011 11:41:06 +0900 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: <4DB0EAC2.9000108@hicorp.co.jp> On 22/04/2011 07:25, Kenneth Russell wrote: > ... However, in an optimizing JavaScript VM, writing the associated > JavaScript code to do these sorts of operations will be faster than > adding another built-in, because in the former case the JIT has a > chance to generate specialized code, and in the latter case you're > calling in to and out of the VM's runtime system (typically written in > C++) which can't perform the same sorts of optimizations. But doesn't each typedarray[x] = y in the Javascript code require calling into and out of the VM's runtime system? Also like Ben Vanik, I would be really surprised if the JIT generated was faster than memcpy(). At best I would expect it to be the same. Lastly my little benchmark shows that the built-in is much faster (at least on FF4). I can't agree with your argument. > I am not personally convinced that we should add this new entry point. > Especially in low-level APIs like typed arrays, every new one has a > high maintenance cost. Also, there are API changes lined up which will > address known performance bottlenecks on the web platform that I think > should take priority. > As part of the planned Typed Array API changes to support efficient > communication with web workers, the plan is to add convenience methods > to copy ArrayBuffers and possibly sub-portions of them. I think we > should invest our time in moving those changes forward. > I will certainly track the API changes and make suggestions. I like Ben's suggestion of real slices but those do not address my use case. I think support for copying sub-portions of both JS arrays and ArrayBuffers are really useful. The former because of performance and the latter because of the garbage generated by making new views or subarrays solely for the purpose of being the source of a copy. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From kbr...@ Thu Apr 21 19:50:42 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 21 Apr 2011 19:50:42 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: <4DB0EAC2.9000108@hicorp.co.jp> References: <4DB00602.5000002@hicorp.co.jp> <4DB0EAC2.9000108@hicorp.co.jp> Message-ID: On Thu, Apr 21, 2011 at 7:41 PM, Mark Callow wrote: > On 22/04/2011 07:25, Kenneth Russell wrote: >> ... However, in an optimizing JavaScript VM, writing the associated >> JavaScript code to do these sorts of operations will be faster than >> adding another built-in, because in the former case the JIT has a >> chance to generate specialized code, and in the latter case you're >> calling in to and out of the VM's runtime system (typically written in >> C++) which can't perform the same sorts of optimizations. > But doesn't each typedarray[x] = y in the Javascript code require > calling into and out of the VM's runtime system? Not necessarily. As one example, in the V8 virtual machine, the JIT has recently been made aware of the typed array types, so specialized assembly code is generated for the assignment operator which is extremely efficient. > Also like Ben Vanik, I > would be really surprised if the JIT generated was faster than memcpy(). Copying a JavaScript array into a typed array isn't a memcpy() operation, at least not in V8. Because JavaScript arrays can hold any kind of object, it's necessary to iterate object-by-object through the JS array, converting each value to a number. This operation is much slower when written in C++ using the JS engine's API rather than allowing the JIT to compile the code which does the conversions. > At best I would expect it to be the same. Lastly my little benchmark > shows that the built-in is much faster (at least on FF4). > > I can't agree with your argument. I hear you. >> I am not personally convinced that we should add this new entry point. >> Especially in low-level APIs like typed arrays, every new one has a >> high maintenance cost. Also, there are API changes lined up which will >> address known performance bottlenecks on the web platform that I think >> should take priority. >> As part of the planned Typed Array API changes to support efficient >> communication with web workers, the plan is to add convenience methods >> to copy ArrayBuffers and possibly sub-portions of them. I think we >> should invest our time in moving those changes forward. >> > > I will certainly track the API changes and make suggestions. I like > Ben's suggestion of real slices but those do not address my use case. I > think support for copying ?sub-portions of both JS arrays and > ArrayBuffers are really useful. The former because of performance and > the latter because of the garbage generated by making new views or > subarrays solely for the purpose of being the source of a copy. I hope that further optimizations in the current crop of JavaScript engines will make it unnecessary to add more APIs just to avoid the generation of garbage. -Ken > Regards > > ? ?-Mark > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Thu Apr 21 23:28:01 2011 From: cal...@ (Mark Callow) Date: Fri, 22 Apr 2011 15:28:01 +0900 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> <4DB0EAC2.9000108@hicorp.co.jp> Message-ID: <4DB11FF1.5040708@hicorp.co.jp> On 22/04/2011 11:50, Kenneth Russell wrote: > On Thu, Apr 21, 2011 at 7:41 PM, Mark Callow wrote: >> On 22/04/2011 07:25, Kenneth Russell wrote: >>> ... However, in an optimizing JavaScript VM, writing the associated >>> JavaScript code to do these sorts of operations will be faster than >>> adding another built-in, because in the former case the JIT has a >>> chance to generate specialized code, and in the latter case you're >>> calling in to and out of the VM's runtime system (typically written in >>> C++) which can't perform the same sorts of optimizations. >> But doesn't each typedarray[x] = y in the Javascript code require >> calling into and out of the VM's runtime system? > Not necessarily. As one example, in the V8 virtual machine, the JIT > has recently been made aware of the typed array types, so specialized > assembly code is generated for the assignment operator which is > extremely efficient. Interesting. If the JIT is so wonderful why do we need any API except the ArrayBuffer & typed array constructors and the DataView class? Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From kbr...@ Fri Apr 22 12:50:15 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 22 Apr 2011 12:50:15 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: <4DB11FF1.5040708@hicorp.co.jp> References: <4DB00602.5000002@hicorp.co.jp> <4DB0EAC2.9000108@hicorp.co.jp> <4DB11FF1.5040708@hicorp.co.jp> Message-ID: On Thu, Apr 21, 2011 at 11:28 PM, Mark Callow wrote: > On 22/04/2011 11:50, Kenneth Russell wrote: >> On Thu, Apr 21, 2011 at 7:41 PM, Mark Callow wrote: >>> On 22/04/2011 07:25, Kenneth Russell wrote: >>>> ... However, in an optimizing JavaScript VM, writing the associated >>>> JavaScript code to do these sorts of operations will be faster than >>>> adding another built-in, because in the former case the JIT has a >>>> chance to generate specialized code, and in the latter case you're >>>> calling in to and out of the VM's runtime system (typically written in >>>> C++) which can't perform the same sorts of optimizations. >>> But doesn't each typedarray[x] = y in the Javascript code require >>> calling into and out of the VM's runtime system? >> Not necessarily. As one example, in the V8 virtual machine, the JIT >> has recently been made aware of the typed array types, so specialized >> assembly code is generated for the assignment operator which is >> extremely efficient. > Interesting. If the JIT is so wonderful why do we need any API except > the ArrayBuffer & typed array constructors and the DataView class? That's my point exactly. (I realize your reply is tongue in cheek, but mine isn't, really.) -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri Apr 22 18:20:38 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 22 Apr 2011 18:20:38 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals Message-ID: The Typed Array editors' draft has been updated: http://www.khronos.org/registry/typedarray/specs/latest/ with changes supporting the following functionality: - Ability to copy sections of an ArrayBuffer - Read-only ArrayBuffers - Support for zero-copy data transfer via postMessage by defining the behavior of ArrayBuffers and ArrayBufferViews under structured clone The changes are clearly highlighted in the spec with "Strawman proposal". The strawman proposal for the behavior of ArrayBuffers and views under structured clone was discussed informally between Mozilla and Google, and has undergone some iteration. (Earlier iterations involved making an explicit API call to achieve transfer of ownership, and having the default behavior perform a copy.) The current behavior was preferred by members of the TC-39 committee, because it achieves unsurprising performance characteristics. We believe that these changes will be efficiently implementable in current JavaScript engines and web browsers. Your feedback on these changes would be greatly appreciated. Please send them to the list. 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 ben...@ Fri Apr 22 19:22:12 2011 From: ben...@ (Ben Vanik) Date: Fri, 22 Apr 2011 19:22:12 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: Love it! Two comments: Any reason that it's 'copyRange' instead of 'slice'? 'copyRange' is more explicit, but 'slice' is more consistent. 'isReadOnly' should probably be 'readOnly' (the name that is used elsewhere in the html spec, for example on the element). -- Ben Vanik http://www.noxa.org On Fri, Apr 22, 2011 at 6:20 PM, Kenneth Russell wrote: > > The Typed Array editors' draft has been updated: > > http://www.khronos.org/registry/typedarray/specs/latest/ > > with changes supporting the following functionality: > > - Ability to copy sections of an ArrayBuffer > - Read-only ArrayBuffers > - Support for zero-copy data transfer via postMessage by defining the > behavior of ArrayBuffers and ArrayBufferViews under structured clone > > The changes are clearly highlighted in the spec with "Strawman proposal". > > The strawman proposal for the behavior of ArrayBuffers and views under > structured clone was discussed informally between Mozilla and Google, > and has undergone some iteration. (Earlier iterations involved making > an explicit API call to achieve transfer of ownership, and having the > default behavior perform a copy.) The current behavior was preferred > by members of the TC-39 committee, because it achieves unsurprising > performance characteristics. > > We believe that these changes will be efficiently implementable in > current JavaScript engines and web browsers. > > Your feedback on these changes would be greatly appreciated. Please > send them to the list. > > 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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Fri Apr 22 21:23:55 2011 From: ben...@ (Ben Vanik) Date: Fri, 22 Apr 2011 21:23:55 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: It be useful to have an exception thrown on writes to closed arrays, just as exceptions are thrown on writes to read-only arrays. If I were in a large, multi-threaded application and trying to debug flakiness it'd be a lot easier to identify write-after-postMessage cases as opposed to random code just not doing anything. I like setting all the sizes to zero, but on writes you'd get range exceptions and other things that aren't immediately traceable to the close action. -- Ben Vanik http://www.noxa.org On Fri, Apr 22, 2011 at 7:22 PM, Ben Vanik wrote: > Love it! > > Two comments: > > Any reason that it's 'copyRange' instead of 'slice'? 'copyRange' is more > explicit, but 'slice' is more consistent. > > 'isReadOnly' should probably be 'readOnly' (the name that is used elsewhere > in the html spec, for example on the element). > > -- > Ben Vanik > http://www.noxa.org > > > > On Fri, Apr 22, 2011 at 6:20 PM, Kenneth Russell wrote: > >> >> The Typed Array editors' draft has been updated: >> >> http://www.khronos.org/registry/typedarray/specs/latest/ >> >> with changes supporting the following functionality: >> >> - Ability to copy sections of an ArrayBuffer >> - Read-only ArrayBuffers >> - Support for zero-copy data transfer via postMessage by defining the >> behavior of ArrayBuffers and ArrayBufferViews under structured clone >> >> The changes are clearly highlighted in the spec with "Strawman proposal". >> >> The strawman proposal for the behavior of ArrayBuffers and views under >> structured clone was discussed informally between Mozilla and Google, >> and has undergone some iteration. (Earlier iterations involved making >> an explicit API call to achieve transfer of ownership, and having the >> default behavior perform a copy.) The current behavior was preferred >> by members of the TC-39 committee, because it achieves unsurprising >> performance characteristics. >> >> We believe that these changes will be efficiently implementable in >> current JavaScript engines and web browsers. >> >> Your feedback on these changes would be greatly appreciated. Please >> send them to the list. >> >> 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 >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Sat Apr 23 10:19:44 2011 From: gle...@ (Glenn Maynard) Date: Sat, 23 Apr 2011 13:19:44 -0400 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: On Fri, Apr 22, 2011 at 9:20 PM, Kenneth Russell wrote: > > The Typed Array editors' draft has been updated: > > http://www.khronos.org/registry/typedarray/specs/latest/ > > with changes supporting the following functionality: > > - Ability to copy sections of an ArrayBuffer > - Read-only ArrayBuffers > - Support for zero-copy data transfer via postMessage by defining the > behavior of ArrayBuffers and ArrayBufferViews under structured clone > This breaks specs that use structured clone within getter operations: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#history-traversal http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#object-store-retrieval-operation http://dev.w3.org/html5/webstorage/#dom-storage-getitem For example, it causes "x = localStorage.arrayBuffer" to clear the arrayBuffer within localStorage as a side-effect of retrieving it, which is clearly unintended. Structured clone is a const operation; making a structured clone of something doesn't modify it. You're changing a fundamental property of structured clone, which isn't a change one spec should be making to another spec. (Has Ian Hickson been involved in this discussion?) It also effectively changes every setter API that uses structured clone, changing them into functions that modify their arguments as well. It's also generally inconvenient. For example, if I have an object describing the current state and I want to stash it in History, I now have to be very careful to copy off any ArrayBuffers within it before doing so, and to update any references to those buffers. I can currently say "history.pushState(anything, title, url)" without having to care about what "anything" is and whether it might be modified; please don't break that. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Sat Apr 23 10:42:58 2011 From: gle...@ (Glenn Maynard) Date: Sat, 23 Apr 2011 13:42:58 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: On Thu, Apr 21, 2011 at 6:56 PM, Kenneth Russell wrote: > I wonder whether it would be an improvement if Canvas's getContext() > algorithm admitted the possibility of an exception being thrown during > context creation. As it stands, every new context type which has the > possibility of failing to initialize has to define its own, > callback-based, error reporting mechanism. Maybe this isn't that big a > deal, because these context types might have to deal with "lost" > contexts like WebGL does. > That's what I thought originally. I talked to Ian Hickson about this, and his take was that getContext should never fail; it should either give a usable context or not. This way is more consistent when combined with recoverable errors (eg. lost contexts) anyway. > This comment aside, the semantic change to return a non-null context > when an error condition occurs sounds acceptable to me. I'm not > completely happy with it, because I think that it will make error > detection harder for the developer. I think we should gather more > feedback, in particular from other browser vendors on the working > group, before committing to make this change. Note that existing WebGL > content is going to have to be updated to deal with this change, in > order to continue to properly detect the situation when the graphics > card is blacklisted. > It's not quite harder, but it's a bit easier to miss: if you don't set up an error handler then you can end up just drawing on a lost context and not showing any error message. Unless the definition of getContext is changed to support errors, I think that's inherent--and of course, you *should* be setting up an error handler. Note that this problem wouldn't exist with an async path. I'll open a separate discussion about that now, since it's come up several times. If we proceed with this change, I agree that we need an indication > that the failure was not recoverable, so that the application can > display appropriate UI to the end user. Adding a boolean to the > webglcontextlost event seems somewhat like a hack, because it > essentially changes the meaning of the event to exactly that of > webglcontextcreationerror. Does anyone have an alternative idea? > Subclassing the event type? Continuing to use a different kind of > event listener? If there's no better suggestion then it sounds okay. > I thought about this, but left it out of the summary to simplify a bit. It can either be a "recoverable" property on the event, or by sending separate events, eg. "webglcontextlost" and "webglcontexterror", which are exactly identical, except the former is used for recoverable errors and the latter isn't cancelable (preventDefault does nothing, since it can't recover anyway). I prefer a "recoverable" event property. It's simpler, the two cases are very similar, and users will often do the same thing in both cases. Also, the "context fatally lost after the context was successfully created" (eg. the GPU blacklist was updated and the WebGL context was permanently revoked) case is very rare. I suspect handling them with the same message will improve the odds of scripts handling this case reasonably. > Additionally, if we proceed with this change, I do not support the > removal of the statusMessage. As an implementor of WebGL, I require > the ability to provide some information to application developers > (which might end up being sent back in in bug reports) when for some > reason WebGL could not initialize. > My suggestion was to include the statusMessage within webglcontextlost. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Sat Apr 23 11:28:32 2011 From: gle...@ (Glenn Maynard) Date: Sat, 23 Apr 2011 14:28:32 -0400 Subject: [Public WebGL] Asynchronous context creation Message-ID: Context creation via getContext can take some time, depending on the operating system, drivers, and so on. Pages may create lots of small WebGL contexts to composit into a larger page. This can take enough time to perceptibly slow page loads. I'd propose the following, which is a very small tweak to the proposal in the "Canvas.getContext error handling" thread [1]: var ctx = canvas.getContext("webgl", {async: true}); assert(ctx.isContextLost()); // guaranteed function initWebGL(event) { // init ctx normally } function webGLError(event) { alert("WebGL error: " + event.statusMessage); event.preventDefault(); // permit recovery if it becomes possible later } canvas.addEventListener("webglcontextrestored", initWebGL, false); canvas.addEventListener("webglcontextlost", webGLError, false); webglcontextrestored or webglcontextlost would be fired from the event loop (not from getContext), indicating that initialization succeeded or failed. The context would initially be lost. This is natural to JavaScript developers, following the callback mechanism used by other async APIs like XHR and FileReader. Note that browsers wouldn't be required to actually initialize contexts in a thread; only the API semantics would actually be required. This also encourages an initialization pattern where handling context loss is straightforward. Currently, people tend to first write code without considering context loss, and need to refactor later to support it, which often is simply never done. Context restoration would still need to be tested by developers, of course, but the likelihood of it just working is much higher. (For those not familiar with DOM Events and the event loop, note that in the above sample code, it's guaranteed safe to call addEventListener after calling getContext. Those events are fired from a queued task, which won't run until the user code returns to the event loop. This mechanism is used by all modern web APIs.) [1] https://www.khronos.org/webgl/public-mailing-list/archives/1104/msg00096.html -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Sun Apr 24 21:31:52 2011 From: cvi...@ (Cedric Vivier) Date: Mon, 25 Apr 2011 11:31:52 +0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: On Sun, Apr 24, 2011 at 00:42, Glenn Maynard wrote: >> Additionally, if we proceed with this change, I do not support the >> removal of the statusMessage. As an implementor of WebGL, I require >> the ability to provide some information to application developers >> (which might end up being sent back in in bug reports) when for some >> reason WebGL could not initialize. > > My suggestion was to include the statusMessage within webglcontextlost. statusMessage is already present in the WebGLContextEvent object all WebGL-initiated events share. My proposal is to add a boolean flag to know whether a context loss is permanent or not, as Mark and I pointed out, having to parse a (possibly localized) string to check this simple boolean status is error-prone and confusing at best. I understand statusMessage can provide a bit additional information, however I'm not sure this is the right channel to expose this information. It is only useful to the end-user for applications that do something smart about it. I'm wary that apps will just display it at best... obviously every app would display the status message in different ways, which could be confusing to the end-user. The browser, on the other hand could present it better with non-obstrusive information/error that gives a more consistent experience and potential action items to the user, through the browser vendor's favorite channel (eg. an information bar similar to what most browser do wrt geolocation UI, linking to browservendor.com/webgl/troubleshooting/). Regards, ----------------------------------------------------------- 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 gle...@ Sun Apr 24 21:45:44 2011 From: gle...@ (Glenn Maynard) Date: Mon, 25 Apr 2011 00:45:44 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: On Mon, Apr 25, 2011 at 12:31 AM, Cedric Vivier wrote: > On Sun, Apr 24, 2011 at 00:42, Glenn Maynard wrote: > >> Additionally, if we proceed with this change, I do not support the > >> removal of the statusMessage. As an implementor of WebGL, I require > >> the ability to provide some information to application developers > >> (which might end up being sent back in in bug reports) when for some > >> reason WebGL could not initialize. > > > > My suggestion was to include the statusMessage within webglcontextlost. > > statusMessage is already present in the WebGLContextEvent object all > WebGL-initiated events share. > Yes, but in webglcontextlost it's currently empty. My proposal is to add a boolean flag to know whether a context loss is > permanent or not, as Mark and I pointed out, having to parse a > (possibly localized) string to check this simple boolean status is > error-prone and confusing at best. > You're replying to something unrelated--I already agreed that the flag should be there. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Sun Apr 24 22:52:20 2011 From: cvi...@ (Cedric Vivier) Date: Mon, 25 Apr 2011 12:52:20 +0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: On Mon, Apr 25, 2011 at 11:45, Glenn Maynard wrote: >> My proposal is to add a boolean flag to know whether a context loss is >> permanent or not, as Mark and I pointed out, having to parse a >> (possibly localized) string to check this simple boolean status is >> error-prone and confusing at best. > > You're replying to something unrelated--I already agreed that the flag > should be there. Sorry I misquoted. As you might have guessed from the rest of my message, this was rather a reply to Gregg's on why I believe exposing a statusMessage is not necessarily a good idea, more so when we expose a flag that provides the actual bit of information application developers can easily/usefully act upon. IMHO we should - at least - clarify in the spec that statusMessage is intended for debugging purposes only, similarly to Geolocation API's positionError.message [1]. Regards, [1] : http://www.w3.org/TR/geolocation-API/#message ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Apr 25 09:58:34 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 25 Apr 2011 09:58:34 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: On Fri, Apr 22, 2011 at 7:22 PM, Ben Vanik wrote: > Love it! > Two comments: > Any reason that it's 'copyRange' instead of 'slice'? 'copyRange' is more > explicit, but 'slice' is more consistent. No good reason. I was wary of calling it "slice" because of the renaming we had to do to the view classes' slice-like method. However, I forgot that this method's copy semantics match those of Arrays', unlike the view classes'. Changed. > 'isReadOnly' should probably be 'readOnly' (the name that is used elsewhere > in the html spec, for example on the element). Good point. Changed. Hopefully this won't conflict with Web IDL's readonly attribute -- it probably won't because the capitalization is different. -Ken > -- > Ben Vanik > http://www.noxa.org > > > On Fri, Apr 22, 2011 at 6:20 PM, Kenneth Russell wrote: >> >> The Typed Array editors' draft has been updated: >> >> http://www.khronos.org/registry/typedarray/specs/latest/ >> >> with changes supporting the following functionality: >> >> ?- Ability to copy sections of an ArrayBuffer >> ?- Read-only ArrayBuffers >> ?- Support for zero-copy data transfer via postMessage by defining the >> behavior of ArrayBuffers and ArrayBufferViews under structured clone >> >> The changes are clearly highlighted in the spec with "Strawman proposal". >> >> The strawman proposal for the behavior of ArrayBuffers and views under >> structured clone was discussed informally between Mozilla and Google, >> and has undergone some iteration. (Earlier iterations involved making >> an explicit API call to achieve transfer of ownership, and having the >> default behavior perform a copy.) The current behavior was preferred >> by members of the TC-39 committee, because it achieves unsurprising >> performance characteristics. >> >> We believe that these changes will be efficiently implementable in >> current JavaScript engines and web browsers. >> >> Your feedback on these changes would be greatly appreciated. Please >> send them to the list. >> >> 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...@ Mon Apr 25 10:07:55 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 25 Apr 2011 10:07:55 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: On Fri, Apr 22, 2011 at 9:23 PM, Ben Vanik wrote: > It be useful to have an exception thrown on writes to closed arrays, just as > exceptions are thrown on writes to read-only arrays. > If I were in a large, multi-threaded application and trying to debug > flakiness it'd be a lot easier to identify write-after-postMessage cases as > opposed to random code just not doing anything.?I like setting all the sizes > to zero, but on writes you'd get range exceptions and other things that > aren't immediately traceable to the close action. There's a problem with doing this: according to JavaScript semantics, using the [] operator to fetch a missing property is supposed to return "undefined", and performing an assignment to a missing property is supposed to add the property to the object. This means that if we set the lengths to zero during the close operation, then we can't throw exceptions from the getters and setters. (Earlier versions of the typed array spec used to do this in various situations, and we had to back off from doing so.) An alternative would be to indicate the closed property in another way, leave the length property alone, and begin to throw exceptions for all reads and writes to the previously valid indexed properties. (I personally prefer setting the lengths to zero, because I think doing so makes it more apparent what happened.) -Ken > -- > Ben Vanik > http://www.noxa.org > > > On Fri, Apr 22, 2011 at 7:22 PM, Ben Vanik wrote: >> >> Love it! >> Two comments: >> Any reason that it's 'copyRange' instead of 'slice'? 'copyRange' is more >> explicit, but 'slice' is more consistent. >> 'isReadOnly' should probably be 'readOnly' (the name that is used >> elsewhere in the html spec, for example on the element). >> >> -- >> Ben Vanik >> http://www.noxa.org >> >> >> On Fri, Apr 22, 2011 at 6:20 PM, Kenneth Russell wrote: >>> >>> The Typed Array editors' draft has been updated: >>> >>> http://www.khronos.org/registry/typedarray/specs/latest/ >>> >>> with changes supporting the following functionality: >>> >>> ?- Ability to copy sections of an ArrayBuffer >>> ?- Read-only ArrayBuffers >>> ?- Support for zero-copy data transfer via postMessage by defining the >>> behavior of ArrayBuffers and ArrayBufferViews under structured clone >>> >>> The changes are clearly highlighted in the spec with "Strawman proposal". >>> >>> The strawman proposal for the behavior of ArrayBuffers and views under >>> structured clone was discussed informally between Mozilla and Google, >>> and has undergone some iteration. (Earlier iterations involved making >>> an explicit API call to achieve transfer of ownership, and having the >>> default behavior perform a copy.) The current behavior was preferred >>> by members of the TC-39 committee, because it achieves unsurprising >>> performance characteristics. >>> >>> We believe that these changes will be efficiently implementable in >>> current JavaScript engines and web browsers. >>> >>> Your feedback on these changes would be greatly appreciated. Please >>> send them to the list. >>> >>> 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 tim...@ Wed Apr 27 01:26:02 2011 From: tim...@ (Tim Johansson) Date: Wed, 27 Apr 2011 10:26:02 +0200 Subject: [Public WebGL] preserveDrawingBuffer = false In-Reply-To: References: Message-ID: <4DB7D31A.2000502@opera.com> On 2011-04-20 03:56, Gregg Tavares (wrk) wrote: > I'd like to suggest that the preserveDrawingBuffer = false spec be > revisited. > > The spec was written so that the drawing buffer is cleared if a > compositing operation is done. This was done so that apps would not > rely on the contents of the drawing buffer being preserved. > > Unfortunately it has the opposite effect. Apps are now written to > expect the drawing buffer to be cleared. But, the spec does not > actually require the drawing buffer to be cleared unless the buffer is > composited. > > So, we have the same situation. Apps expect the drawing buffer to be > cleared but depending on the browser, timing, etc there is no > guarantee that the buffer was actually composited. If it wasn't the > contents is still there. You write some code, it seems to work and > only later do you find out that on some slow machine or some specific > browser on a specific platform you're getting inconsistent behavior > and tracking that down can be really hard (I just got through tracking > it down for one app) > > Would it be possible to change the spec to effectively say > > If preserveDrawingBuffer is false, then when JavaScript enters a > callback if the user does not clear the drawingbuffer before the first > draw call the implementation will clear it? > > This doesn't seem like it would change any of the performance issues > nor the effective semantics of the spec but it would make the behavior > 100% consistent. > Sounds good to me, I agree having it consistent in all cases would be much better. //Tim ----------------------------------------------------------- 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 tim...@ Wed Apr 27 04:11:38 2011 From: tim...@ (Tim Johansson) Date: Wed, 27 Apr 2011 13:11:38 +0200 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> Message-ID: <4DB7F9EA.9030104@opera.com> On 2011-04-22 00:56, Kenneth Russell wrote: > On Tue, Apr 19, 2011 at 7:35 PM, Cedric Vivier wrote: >> On Wed, Apr 20, 2011 at 10:20, Mark Callow wrote: >>> On 19/04/2011 04:06, Glenn Maynard wrote: >>>> Following up from whatwg: >>>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031192.html. >>>> To recap, step 6 of getContext ("Return a new object for contextId"), >>>> which is where WebGL takes over, was never intended to return null. >>>> null isn't a "new object", it's no object. >>> What happens if the context type passed to getContext is not recognized >>> by the browser, e.g., when WebGL is not supported by the browser? >> Null is returned, as specified in the Canvas spec. >> >>> If we go this route, a status message in webglcontextlost is >>> insufficient. Applications that wish to handle webglcontextlost will not >>> want to be parsing strings, especially localized strings, to determine >>> if the browser is refusing to create a context, so there is no >>> possibility of restoration, or if it is a normal context lost event. >>> Some kind of error code will be needed. >> Yes, I believe adding an isRestorable boolean to the webglcontextlost >> event would help to differentiate between a permanent or transient >> error. >> >> statusMessage should be used for display only and should never have to >> be parsed. >> To make sure it does not get abused *and* to let browsers give better >> diagnostic to users, we might even want to get rid of it, if the >> browser actually has useful failure information to provide, it could >> expose it in a more useful/consistent way to the user directly. > I wonder whether it would be an improvement if Canvas's getContext() > algorithm admitted the possibility of an exception being thrown during > context creation. As it stands, every new context type which has the > possibility of failing to initialize has to define its own, > callback-based, error reporting mechanism. Maybe this isn't that big a > deal, because these context types might have to deal with "lost" > contexts like WebGL does. > > This comment aside, the semantic change to return a non-null context > when an error condition occurs sounds acceptable to me. I'm not > completely happy with it, because I think that it will make error > detection harder for the developer. I think we should gather more > feedback, in particular from other browser vendors on the working > group, before committing to make this change. Note that existing WebGL > content is going to have to be updated to deal with this change, in > order to continue to properly detect the situation when the graphics > card is blacklisted. > For creating context when the context is lost it sounds OK, but I don't really understand why we would want to return a valid context that will never work when the GPU is blacklisted. If the GPU is blacklisted or missing features WebGL is IMO not supported on that device, and if webgl is not supported getContext should return null. That is all according to the spec as far as I can tell. Should we also return a valid context when trying to create a context on a device where there is no capable graphics chip, for example on a mobile only supporting OpenGL ES 1.1? What about if there is a setting to disable webgl, should we still return a context then? I am also not sure how this would work with switchable graphics. If only one of the GPUs are capable of running webgl and that is active when creating the context you might get an unrecoverable error (unless you can find out that there are two GPUs and the other will work). But if the other context is capable and the user switches to that you could possibly restore the context. Should we always assume non-recoverable errors if we are not sure it is recoverable, or always assume recoverable if we are not sure it is non-recoverable? //Tim > If we proceed with this change, I agree that we need an indication > that the failure was not recoverable, so that the application can > display appropriate UI to the end user. Adding a boolean to the > webglcontextlost event seems somewhat like a hack, because it > essentially changes the meaning of the event to exactly that of > webglcontextcreationerror. Does anyone have an alternative idea? > Subclassing the event type? Continuing to use a different kind of > event listener? If there's no better suggestion then it sounds okay. > > Additionally, if we proceed with this change, I do not support the > removal of the statusMessage. As an implementor of WebGL, I require > the ability to provide some information to application developers > (which might end up being sent back in in bug reports) when for some > reason WebGL could not initialize. > > -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 gle...@ Wed Apr 27 08:10:37 2011 From: gle...@ (Glenn Maynard) Date: Wed, 27 Apr 2011 11:10:37 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: <4DB7F9EA.9030104@opera.com> References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> Message-ID: On Wed, Apr 27, 2011 at 7:11 AM, Tim Johansson wrote: > For creating context when the context is lost it sounds OK, but I don't > really understand why we would want to return a valid context that will > never work when the GPU is blacklisted. If the GPU is blacklisted or missing > features WebGL is IMO not supported on that device, and if webgl is not > supported getContext should return null. That is all according to the spec > as far as I can tell. > WebGL isn't quite defining context creation properly. It defines the getContext call itself, which isn't part of WebGL; it's specified by HTML5. Context APIs (WebGL and 2d canvas) just specify the "Return a new object for contextId" algorithm, which getContext refers to in step 6. That algorithm can't return null--it can only return an object. Handling errors by treating them as "contextId is not the name of a context supported by the user agent" (getContext step 2) was discussed. In principle the error event could be wedged in there ("when WebGL is required to determine if "webgl" is a context supported by the user agent for a given canvas, run the following steps..."). That's odd, though, and assumes that a canvas object is always around when "is the name of a context supported" happens, which isn't necessarily true. I think consolidating error reporting and consistently supporting recoverable errors is a win. If you have time, please also check the thread on async context creation, which also ties in well with this. Should we also return a valid context when trying to create a context on a > device where there is no capable graphics chip, for example on a mobile only > supporting OpenGL ES 1.1? What about if there is a setting to disable webgl, > should we still return a context then? > I think it's ultimately up to the browser. If it doesn't want to return an error message for some unrecoverable errors, it can always opt to return null and pretend WebGL isn't implemented at all. This would still be allowed because of step 2 of getContext: the UA can treat "webgl" as not a supported contextId, in which case it returns null before the WebGL is even invoked. If there's a setting to disable WebGL, that can be recoverable, since the user can change the setting. If the user reenables WebGL in his settings, pages would see a context restoration event and begin working immediately, instead of the user having to refresh the page or take some other action. This would be consistent whether getContext failed initially (WebGL was turned off when the page was loaded) or whether the context was lost later (the user disabled WebGL while the page was already loaded). I am also not sure how this would work with switchable graphics. If only one > of the GPUs are capable of running webgl and that is active when creating > the context you might get an unrecoverable error (unless you can find out > that there are two GPUs and the other will work). But if the other context > is capable and the user switches to that you could possibly restore the > context. Should we always assume non-recoverable errors if we are not sure > it is recoverable, or always assume recoverable if we are not sure it is > non-recoverable? > I don't think it's either extreme. It's always possible that a recoverable error might never recover in a particular situation, and there can be vanishingly rare cases where "fatal" errors might actually be recoverable (a browser's GPU blacklist being updated dynamically, unblacklisting the user's hardware). It's ultimately a judgement call for implementations, I think. The only requirement I think should be in the spec is that nonrecoverable errors are guaranteed to not recover. Maybe "fatal" is a clearer name than "recoverable". "!event.fatal" doesn't guarantee recoverability, "event.fatal" just guarantees unrecoverability. [1] http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Wed Apr 27 10:48:43 2011 From: cma...@ (Chris Marrin) Date: Wed, 27 Apr 2011 10:48:43 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: > > ... > As part of the planned Typed Array API changes to support efficient > communication with web workers, the plan is to add convenience methods > to copy ArrayBuffers and possibly sub-portions of them. I think we > should invest our time in moving those changes forward. Why is it necessary to have functions to copy ArrayBuffers. Isn't the copy constructor in the TypedArrays sufficient? ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From vla...@ Wed Apr 27 15:51:11 2011 From: vla...@ (Vladimir Vukicevic) Date: Wed, 27 Apr 2011 22:51:11 +0000 (GMT) Subject: [Public WebGL] preserveDrawingBuffer = false In-Reply-To: <4DB7D31A.2000502@opera.com> Message-ID: <30189503.28746.1303944671547.JavaMail.root@zimbra.off.net> ----- Original Message ----- > On 2011-04-20 03:56, Gregg Tavares (wrk) wrote: > > I'd like to suggest that the preserveDrawingBuffer = false spec be > > revisited. > > > > The spec was written so that the drawing buffer is cleared if a > > compositing operation is done. This was done so that apps would not > > rely on the contents of the drawing buffer being preserved. > > > > Unfortunately it has the opposite effect. Apps are now written to > > expect the drawing buffer to be cleared. But, the spec does not > > actually require the drawing buffer to be cleared unless the buffer > > is composited. > > > > So, we have the same situation. Apps expect the drawing buffer to be > > cleared but depending on the browser, timing, etc there is no > > guarantee that the buffer was actually composited. If it wasn't the > > contents is still there. You write some code, it seems to work and > > only later do you find out that on some slow machine or some > > specific browser on a specific platform you're getting inconsistent > > behavior and tracking that down can be really hard (I just got > > through tracking > > it down for one app) > > > > Would it be possible to change the spec to effectively say > > > > If preserveDrawingBuffer is false, then when JavaScript enters > > a > > callback if the user does not clear the drawingbuffer before the > > first draw call the implementation will clear it? > > > > This doesn't seem like it would change any of the performance issues > > nor the effective semantics of the spec but it would make the > > behavior 100% consistent. > > Sounds good to me, I agree having it consistent in all cases would be > much better. I don't think it's all that easy to know "when a callback is entered" without a lot of potentially expensive state tracking and checking that you'd have to do on every draw call. I agree that consistency is important, but I don't think this is the right way to get it. If apps are incorrectly relying on this, we should consider changing the "default clear" color to be a random non-black color (or explicitly specify hot pink) as a way of forcing apps to do the clear themselves. We shouldn't be letting apps use this as a crutch for not clearing themselves. - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Wed Apr 27 15:57:19 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Wed, 27 Apr 2011 15:57:19 -0700 Subject: [Public WebGL] preserveDrawingBuffer = false In-Reply-To: <30189503.28746.1303944671547.JavaMail.root@zimbra.off.net> References: <4DB7D31A.2000502@opera.com> <30189503.28746.1303944671547.JavaMail.root@zimbra.off.net> Message-ID: A random or flashing color would work In reference to your comment, in my particular case it wasn't that I was counting on WebGL doing the clear, it was that I had a bug and for any WebGL that did not clear the bug was hidden. Once I ran into an implementation the didn't clear I saw the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Wed Apr 27 17:44:06 2011 From: gle...@ (Glenn Maynard) Date: Wed, 27 Apr 2011 20:44:06 -0400 Subject: [Public WebGL] preserveDrawingBuffer = false In-Reply-To: References: Message-ID: Some complications: do you trigger this behavior at the beginning of every DOM event dispatch, or at the beginning of each event handler invocation[1]? What happens if a WebGL call causes an event to be fired synchronously, causing nested callbacks? There are probably interactions with other specs that I'm not thinking of, too. Also, needing to check a list of callback hooks before all script callbacks are executed could cause overhead for everything else. It would be good to avoid all of this. You could think about an explicit ctx.present() function. Instead of drawing functions marking the drawing buffer as modified (ready to be presented to the compositor and then cleared), present() would do that. Calling any drawing function on a drawing buffer marked as modified would clear it (if preserveDrawingBuffer is false) and mark the drawing buffer unmodified, regardless of entering or exiting any callbacks. This would replace the clearing that currently happens after compositing, and give completely deterministic behavior. The backwards-incompatibility would be unfortunate, though, even though it's a trivial change for users. [1] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dispatching-events -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Thu Apr 28 03:45:05 2011 From: tim...@ (Tim Johansson) Date: Thu, 28 Apr 2011 12:45:05 +0200 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> Message-ID: <4DB94531.3070705@opera.com> On 2011-04-27 17:10, Glenn Maynard wrote: > On Wed, Apr 27, 2011 at 7:11 AM, Tim Johansson > wrote: > > For creating context when the context is lost it sounds OK, but I > don't really understand why we would want to return a valid > context that will never work when the GPU is blacklisted. If the > GPU is blacklisted or missing features WebGL is IMO not supported > on that device, and if webgl is not supported getContext should > return null. That is all according to the spec as far as I can tell. > > > WebGL isn't quite defining context creation properly. It defines the > getContext call itself, which isn't part of WebGL; it's specified by > HTML5. Context APIs (WebGL and 2d canvas) just specify the "Return a > new object for contextId" algorithm, which getContext refers to in > step 6. That algorithm can't return null--it can only return an object. > What I meant was that for non-recoverable, permanent errors the WebGL spec could say something along the lines of "If the device is not capable of running WebGL content WebGL should be considered unsupported." That would make getContext return null in step two (without sending an event). > Handling errors by treating them as "contextId is not the name of a > context supported by the user agent" (getContext step 2) was > discussed. In principle the error event could be wedged in there > ("when WebGL is required to determine if "webgl" is a context > supported by the user agent for a given canvas, run the following > steps..."). That's odd, though, and assumes that a canvas object is > always around when "is the name of a context supported" happens, which > isn't necessarily true. > To send an event there is odd yes, that was not what I meant we should do. You could easily check for permanent errors (such as GPU not present or blacklisted) when checking if webgl is supported. Or you could check at startup and cache the result. > I think consolidating error reporting and consistently supporting > recoverable errors is a win. If you have time, please also check the > thread on async context creation, which also ties in well with this. > > Should we also return a valid context when trying to create a > context on a device where there is no capable graphics chip, for > example on a mobile only supporting OpenGL ES 1.1? What about if > there is a setting to disable webgl, should we still return a > context then? > > > I think it's ultimately up to the browser. If it doesn't want to > return an error message for some unrecoverable errors, it can always > opt to return null and pretend WebGL isn't implemented at all. This > would still be allowed because of step 2 of getContext: the UA can > treat "webgl" as not a supported contextId, in which case it returns > null before the WebGL is even invoked. > I really don't like unspecified behavior, 99.9% of the time that means we'll have to try to figure out what others are doing and do the same thing in order to be compatible with content on the web. I would prefer if the spec said something about what should happen when the device is not capable of supporting webgl, which would include blacklisting. > If there's a setting to disable WebGL, that can be recoverable, since > the user can change the setting. If the user reenables WebGL in his > settings, pages would see a context restoration event and begin > working immediately, instead of the user having to refresh the page or > take some other action. This would be consistent whether getContext > failed initially (WebGL was turned off when the page was loaded) or > whether the context was lost later (the user disabled WebGL while the > page was already loaded). > Right, but generally when you disable a feature you want to get the same thing you would get if the feature was not present, which generally is to give you fallback content. If you disable javascript you want to get the noscript tag, if you disable canvas you want to get the canvas fallback content etc. For WebGL the fallback could be to render using the 2d context if the webgl content is not present. It does not seem entirely unreasonable that apps would use webgl to render 2d content for performance reasons but fall back to the 2d context to be compatible with older browsers, devices with blacklisted GPUs and ie9. I would personally rather remove the context creation error event than making a change that will complicate context creation. The permanent errors should be easy to handle by returning null without an event. For context lost on context creation (which is probably going to be very rare since it is mainly crashers, sleep and in some cases screensaver) we could potentially return a context which is lost. In order to recover it we would have to specify the contextlost event to trigger if it is set while the context is lost so you can call preventDefault and restore the context. //Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Thu Apr 28 04:09:42 2011 From: tim...@ (Tim Johansson) Date: Thu, 28 Apr 2011 13:09:42 +0200 Subject: [Public WebGL] Asynchronous context creation In-Reply-To: References: Message-ID: <4DB94AF6.1080500@opera.com> On 2011-04-23 20:28, Glenn Maynard wrote: > Context creation via getContext can take some time, depending on the > operating system, drivers, and so on. Pages may create lots of small > WebGL contexts to composit into a larger page. This can take enough > time to perceptibly slow page loads. I'd propose the following, which > is a very small tweak to the proposal in the "Canvas.getContext error > handling" thread [1]: > Creating webgl contexts, at least in our implementation, is not really more expensive than creating 2d contexts (regardless of OS/drivers). Even if creating many contexts can take some time in some implementations, creating multiple context will be potentially bad for many other reasons than context creation time so I don't think that is a usage pattern we should encourage. In most examples I have seen which takes time to initialize it is not the context creation that takes time. It is far more common that for example shader compile takes lots of time, and creating multiple webgl context instead of using fbos mean you cannot reuse shaders as much (since shader objects are not shared between contexts). I don't see any need for async context creation, at least not right now. //Tim > var ctx = canvas.getContext("webgl", {async: true}); > assert(ctx.isContextLost()); // guaranteed > > function initWebGL(event) > { > // init ctx normally > } > > function webGLError(event) > { > alert("WebGL error: " + event.statusMessage); > event.preventDefault(); // permit recovery if it becomes possible > later > } > > canvas.addEventListener("webglcontextrestored", initWebGL, false); > canvas.addEventListener("webglcontextlost", webGLError, false); > > webglcontextrestored or webglcontextlost would be fired from the event > loop (not from getContext), indicating that initialization succeeded > or failed. The context would initially be lost. > > This is natural to JavaScript developers, following the callback > mechanism used by other async APIs like XHR and FileReader. Note that > browsers wouldn't be required to actually initialize contexts in a > thread; only the API semantics would actually be required. > > This also encourages an initialization pattern where handling context > loss is straightforward. Currently, people tend to first write code > without considering context loss, and need to refactor later to > support it, which often is simply never done. Context restoration > would still need to be tested by developers, of course, but the > likelihood of it just working is much higher. > > (For those not familiar with DOM Events and the event loop, note that > in the above sample code, it's guaranteed safe to call > addEventListener after calling getContext. Those events are fired > from a queued task, which won't run until the user code returns to the > event loop. This mechanism is used by all modern web APIs.) > > > [1] > https://www.khronos.org/webgl/public-mailing-list/archives/1104/msg00096.html > > -- > Glenn Maynard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Thu Apr 28 04:16:58 2011 From: tim...@ (Tim Johansson) Date: Thu, 28 Apr 2011 13:16:58 +0200 Subject: [Public WebGL] preserveDrawingBuffer = false In-Reply-To: <30189503.28746.1303944671547.JavaMail.root@zimbra.off.net> References: <30189503.28746.1303944671547.JavaMail.root@zimbra.off.net> Message-ID: <4DB94CAA.4010203@opera.com> On 2011-04-28 00:51, Vladimir Vukicevic wrote: > ----- Original Message ----- >> On 2011-04-20 03:56, Gregg Tavares (wrk) wrote: >>> I'd like to suggest that the preserveDrawingBuffer = false spec be >>> revisited. >>> >>> The spec was written so that the drawing buffer is cleared if a >>> compositing operation is done. This was done so that apps would not >>> rely on the contents of the drawing buffer being preserved. >>> >>> Unfortunately it has the opposite effect. Apps are now written to >>> expect the drawing buffer to be cleared. But, the spec does not >>> actually require the drawing buffer to be cleared unless the buffer >>> is composited. >>> >>> So, we have the same situation. Apps expect the drawing buffer to be >>> cleared but depending on the browser, timing, etc there is no >>> guarantee that the buffer was actually composited. If it wasn't the >>> contents is still there. You write some code, it seems to work and >>> only later do you find out that on some slow machine or some >>> specific browser on a specific platform you're getting inconsistent >>> behavior and tracking that down can be really hard (I just got >>> through tracking >>> it down for one app) >>> >>> Would it be possible to change the spec to effectively say >>> >>> If preserveDrawingBuffer is false, then when JavaScript enters >>> a >>> callback if the user does not clear the drawingbuffer before the >>> first draw call the implementation will clear it? >>> >>> This doesn't seem like it would change any of the performance issues >>> nor the effective semantics of the spec but it would make the >>> behavior 100% consistent. >> Sounds good to me, I agree having it consistent in all cases would be >> much better. > I don't think it's all that easy to know "when a callback is entered" without a lot of potentially expensive state tracking and checking that you'd have to do on every draw call. I agree that consistency is important, but I don't think this is the right way to get it. If apps are incorrectly relying on this, we should consider changing the "default clear" color to be a random non-black color (or explicitly specify hot pink) as a way of forcing apps to do the clear themselves. We shouldn't be letting apps use this as a crutch for not clearing themselves. > In our implementation it would not be any overhead to always clear, but if changing the default clear color is easier to implement in other browsers I am fine with that. Doing so should also solve the issue in more or less all cases. //Tim ----------------------------------------------------------- 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 gle...@ Thu Apr 28 08:36:58 2011 From: gle...@ (Glenn Maynard) Date: Thu, 28 Apr 2011 11:36:58 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: <4DB94531.3070705@opera.com> References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> Message-ID: On Thu, Apr 28, 2011 at 6:45 AM, Tim Johansson wrote: > > I really don't like unspecified behavior, 99.9% of the time that means > we'll have to try to figure out what others are doing and do the same thing > in order to be compatible with content on the web. I would prefer if the > spec said something about what should happen when the device is not capable > of supporting webgl, which would include blacklisting. > Note that blacklisting is different than the device not being able to support WebGL, since device blacklists are updated on the fly in some implementations (Chrome, from what I understand) which can cause WebGL support to go away (or return) after pages are already running. Insufficient hardware is unlikely to change at runtime. Right, but generally when you disable a feature you want to get the same > thing you would get if the feature was not present, which generally is to > give you fallback content. If you disable javascript you want to get the > noscript tag, if you disable canvas you want to get the canvas fallback > content etc. For WebGL the fallback could be to render using the 2d context > if the webgl content is not present. It does not seem entirely unreasonable > that apps would use webgl to render 2d content for performance reasons but > fall back to the 2d context to be compatible with older browsers, devices > with blacklisted GPUs and ie9. > It seems hard to get both this and the ability to return an error message to the application, unless HTML5's getContext spec is changed or it's wedged in as I described earlier (ugly). It would be easier to do if getContext was modified to make step 2 ("If contextId is not the name of a context supported by the user agent...") an explicit algorithm, eg. "*Determine if contextId is supported by the user agent for canvas*. If false, return null and abort these steps." (That's in HTML5, so we'd need to convince Ian Hickson to make the change.) That would give WebGL a clear spec entry point with a reference to the canvas, so it could say "When the user agent is required to determine if *webgl* is supported by the user agent for *canvas*, ...". It now has an explicit canvas to report errors with (whether using an event or other means), while still causing step 2 to return null. I would personally rather remove the context creation error event than > making a change that will complicate context creation. The permanent errors > should be easy to handle by returning null without an event. > Being able to supply an error message to the calling application when context creation fails was given as a requirement earlier in the discussion. I'll defer to Ken and others about that. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Thu Apr 28 09:01:11 2011 From: tim...@ (Tim Johansson) Date: Thu, 28 Apr 2011 18:01:11 +0200 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> Message-ID: <4DB98F47.3010107@opera.com> On 4/28/11 5:36 PM, Glenn Maynard wrote: > On Thu, Apr 28, 2011 at 6:45 AM, Tim Johansson > wrote: > > I really don't like unspecified behavior, 99.9% of the time that > means we'll have to try to figure out what others are doing and do > the same thing in order to be compatible with content on the web. > I would prefer if the spec said something about what should happen > when the device is not capable of supporting webgl, which would > include blacklisting. > > > Note that blacklisting is different than the device not being able to > support WebGL, since device blacklists are updated on the fly in some > implementations (Chrome, from what I understand) which can cause WebGL > support to go away (or return) after pages are already running. > Insufficient hardware is unlikely to change at runtime. > In theory they are different yes, but the chances that the blacklist will be updated to remove blacklisting of a gpu while you are looking at a page that did not load (because the gpu was blacklisted) are so insignificant that for all practical purposes they are the same thing. A driver being added to the blacklist cannot affect the context creation of a running app since that context has already been created so it only the - probably extremely rare - "webgl returns" case that would mater. It would have to signal a lost context in the case of "webgl goes away". > > Right, but generally when you disable a feature you want to get > the same thing you would get if the feature was not present, which > generally is to give you fallback content. If you disable > javascript you want to get the noscript tag, if you disable canvas > you want to get the canvas fallback content etc. For WebGL the > fallback could be to render using the 2d context if the webgl > content is not present. It does not seem entirely unreasonable > that apps would use webgl to render 2d content for performance > reasons but fall back to the 2d context to be compatible with > older browsers, devices with blacklisted GPUs and ie9. > > > It seems hard to get both this and the ability to return an error > message to the application, unless HTML5's getContext spec is changed > or it's wedged in as I described earlier (ugly). > Yes, this all assumed that non recoverable errors would not send a message but leave it up to the browser or a troubleshooting page to notify the user of why the context creation failed. The app would only know that context creation failed and it cannot be solved by trying again. Recoverable errors could still get a status message as it would be signalled through context lost. //Tim ----------------------------------------------------------- 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 gle...@ Thu Apr 28 09:58:10 2011 From: gle...@ (Glenn Maynard) Date: Thu, 28 Apr 2011 12:58:10 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: <4DB98F47.3010107@opera.com> References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Thu, Apr 28, 2011 at 12:01 PM, Tim Johansson wrote: > On 4/28/11 5:36 PM, Glenn Maynard wrote: > > Note that blacklisting is different than the device not being able to >> support WebGL, since device blacklists are updated on the fly in some >> implementations (Chrome, from what I understand) which can cause WebGL >> support to go away (or return) after pages are already running. >> Insufficient hardware is unlikely to change at runtime. >> >> In theory they are different yes, but the chances that the blacklist will > be updated to remove blacklisting of a gpu while you are looking at a page > that did not load (because the gpu was blacklisted) are so insignificant > that for all practical purposes they are the same thing. > A driver being added to the blacklist cannot affect the context creation of > a running app since that context has already been created so it only the - > probably extremely rare - "webgl returns" case that would mater. It would > have to signal a lost context in the case of "webgl goes away". Pages can create WebGL contexts at any time. For example, you can create a context in a hidden canvas to perform off-screen image manipulation, which you pull out of the canvas by other means like canvas.toDataURL. Long-lived web apps are now common; I often leave pages loaded in tabs for weeks without reloading them. It's very possible for pages to attempt to create a WebGL context when the GPU is blacklisted, but wasn't when the page was originally loaded. (You can still say that "the contextId 'webgl' is not a supported rendering context" and return null from step 2, despite this. It just means that the contextId would be considered unsupported despite the fact that WebGLRenderingContext, etc. are present in the window. That's not a big deal.) Yes, this all assumed that non recoverable errors would not send a message > but leave it up to the browser or a troubleshooting page to notify the user > of why the context creation failed. The app would only know that context > creation failed and it cannot be solved by trying again. Recoverable errors > could still get a status message as it would be signalled through context > lost. > I suggested that earlier and it was rejected--addressing that objection was where this proposal originated. My main underlying goal is just to reconcile WebGL with HTML5's getContext spec. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 28 17:06:22 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 28 Apr 2011 17:06:22 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: > > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: > >> >> ... >> As part of the planned Typed Array API changes to support efficient >> communication with web workers, the plan is to add convenience methods >> to copy ArrayBuffers and possibly sub-portions of them. I think we >> should invest our time in moving those changes forward. > > Why is it necessary to have functions to copy ArrayBuffers. Isn't the copy constructor in the TypedArrays sufficient? That's a fair point. During one of the face-to-face meetings with Mozilla it seemed that if we used transfer-of-ownership for ArrayBuffers sent via postMessage, then we had to make it easy to copy them. You're right, though, that the slice() operation can be easily implemented in pure JavaScript, with the only cost the creation of two temporary Uint8Arrays. Should we just get rid of it and provide non-normative text showing how it could be implemented? -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 ben...@ Thu Apr 28 17:22:29 2011 From: ben...@ (Ben Vanik) Date: Thu, 28 Apr 2011 17:22:29 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: Extra garbage is scary - especially the large garbage likely created by doing that operation. Another nice thing about having a slice() is that it makes Typed Arrays more consistent with normal JS arrays, and eases the developer 'wth?' moments when discovering that for some reason slice() doesn't exist. If there were no slice() method in JS I'd say leave it out, but it seems better to create a consistent API across the whole web ecosystem. -- Ben Vanik http://www.noxa.org On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell wrote: > On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: > > > > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: > > > >> > >> ... > >> As part of the planned Typed Array API changes to support efficient > >> communication with web workers, the plan is to add convenience methods > >> to copy ArrayBuffers and possibly sub-portions of them. I think we > >> should invest our time in moving those changes forward. > > > > Why is it necessary to have functions to copy ArrayBuffers. Isn't the > copy constructor in the TypedArrays sufficient? > > That's a fair point. During one of the face-to-face meetings with > Mozilla it seemed that if we used transfer-of-ownership for > ArrayBuffers sent via postMessage, then we had to make it easy to copy > them. You're right, though, that the slice() operation can be easily > implemented in pure JavaScript, with the only cost the creation of two > temporary Uint8Arrays. > > Should we just get rid of it and provide non-normative text showing > how it could be implemented? > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Apr 28 19:45:14 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 28 Apr 2011 19:45:14 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: There's no large garbage: function sliceFloat32Array(original, start, end) { var view = original.subarray(start, end); // this allocates almost no memory. It's just a view return new Float32Array(view); // this makes the same copy slice would have. } On Thu, Apr 28, 2011 at 5:22 PM, Ben Vanik wrote: > Extra garbage is scary - especially the large garbage likely created by > doing that operation. Another nice thing about having a slice() is that it > makes Typed Arrays more consistent with normal JS arrays, and eases the > developer 'wth?' moments when discovering that for some reason slice() > doesn't exist. If there were no slice() method in JS I'd say leave it out, > but it seems better to create a consistent API across the whole web > ecosystem. > > > -- > Ben Vanik > http://www.noxa.org > > > On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell wrote: > >> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: >> > >> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: >> > >> >> >> >> ... >> >> As part of the planned Typed Array API changes to support efficient >> >> communication with web workers, the plan is to add convenience methods >> >> to copy ArrayBuffers and possibly sub-portions of them. I think we >> >> should invest our time in moving those changes forward. >> > >> > Why is it necessary to have functions to copy ArrayBuffers. Isn't the >> copy constructor in the TypedArrays sufficient? >> >> That's a fair point. During one of the face-to-face meetings with >> Mozilla it seemed that if we used transfer-of-ownership for >> ArrayBuffers sent via postMessage, then we had to make it easy to copy >> them. You're right, though, that the slice() operation can be easily >> implemented in pure JavaScript, with the only cost the creation of two >> temporary Uint8Arrays. >> >> Should we just get rid of it and provide non-normative text showing >> how it could be implemented? >> >> -Ken >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Apr 29 06:08:25 2011 From: bja...@ (Benoit Jacob) Date: Fri, 29 Apr 2011 06:08:25 -0700 (PDT) Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: Message-ID: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Hi all, Here is an attempt at summarizing the main question in this debate, as was discussed during yesterday's conference call. We need to choose between two main options: Option 1: keep current WebGL spec behavior -> That is: getContext returns null, generates a webglcontextcreationerror event, but does not throw . Option 2: change WebGL spec to throw exceptions -> That is: getContext throws an exception; the webglcontextcreationerror event becomes redundant/useless and its fate needs to be decided. Here is some analysis of how these two options compare: * Both options requiring changing the HTML canvas spec, since it currently requires a non-null object and no exception. This should be easy as it's not yet ratified. * Option 2 also requires changing the WebGL spec to allow throwing an exception. This may be harder (require versioning) since WebGL 1.0 is already ratified. * Option 2 also requires deciding on the fate of webglcontextcreationerror, which is part of the WebGL 1.0 spec. * Both options preserve compatibility with existing content: option 1 is the current spec and option 2 is what (because of a bug) Firefox is currently doing. * API comparison: depending on taste, one may prefer one option or the other. ** Both options are acceptable. The HTML canvas spec already allows throwing exceptions in other places. Exceptions are not JS-specific. ** Exceptions are a single unified mechanism; while with the webglcontextcreationerror way, every new canvas context type will have to introduce its own event type. But one may also argue that that's actually a good thing as different contexts have different kinds of failures and different messages to pass to the user. So, no clear advantage for either option. In short, both options are acceptable to me, so I won't oppose either. By default, I'm inclined to just go for option 1 as it avoids having to change the WebGL spec and debate what to do about webglcontextcreationerror; but obviously, especially since option 2 is what Firefox currently does, I'm not opposed to it either. Cheers, Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Apr 29 08:13:24 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 29 Apr 2011 08:13:24 -0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Well, if we're taking a vote between those two I'd vote for #2. I just seems a more natural syntax to me and doesn't seem like it breaks anything. The HTML5 spec will have to change but a "2d" context can be speced as never throwing which means nothing has to change for 2d contexts and as you pointed out, people are already handling try/catch for webgl contexts because of FF. -g On Fri, Apr 29, 2011 at 6:08 AM, Benoit Jacob wrote: > Hi all, > > Here is an attempt at summarizing the main question in this debate, as was > discussed during yesterday's conference call. > > We need to choose between two main options: > > Option 1: keep current WebGL spec behavior > -> That is: getContext returns null, generates a webglcontextcreationerror > event, but does not throw. > Option 2: change WebGL spec to throw exceptions > -> That is: getContext throws an exception; the webglcontextcreationerror > event becomes redundant/useless and its fate needs to be decided. > > Here is some analysis of how these two options compare: > > * Both options requiring changing the HTML canvas spec, since it currently > requires a non-null object and no exception. This should be easy as it's not > yet ratified. > * Option 2 also requires changing the WebGL spec to allow throwing an > exception. This may be harder (require versioning) since WebGL 1.0 is > already ratified. > * Option 2 also requires deciding on the fate of webglcontextcreationerror, > which is part of the WebGL 1.0 spec. > * Both options preserve compatibility with existing content: option 1 is > the current spec and option 2 is what (because of a bug) Firefox is > currently doing. > * API comparison: depending on taste, one may prefer one option or the > other. > ** Both options are acceptable. The HTML canvas spec already allows > throwing exceptions in other places. Exceptions are not JS-specific. > ** Exceptions are a single unified mechanism; while with the > webglcontextcreationerror way, every new canvas context type will have to > introduce its own event type. But one may also argue that that's actually a > good thing as different contexts have different kinds of failures and > different messages to pass to the user. So, no clear advantage for either > option. > > In short, both options are acceptable to me, so I won't oppose either. By > default, I'm inclined to just go for option 1 as it avoids having to change > the WebGL spec and debate what to do about webglcontextcreationerror; but > obviously, especially since option 2 is what Firefox currently does, I'm not > opposed to it either. > > Cheers, > Benoit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Fri Apr 29 08:24:34 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 29 Apr 2011 22:24:34 +0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Hey, On Fri, Apr 29, 2011 at 20:08, Benoit Jacob wrote: > ** Exceptions are a single unified mechanism; while with the > webglcontextcreationerror way, every new canvas context type will have to > introduce its own event type. This argument implies the Canvas spec defines an exception object that works for every potential new canvas context type. Otherwise, every new canvas context type would still have to define the exception object it throws. > So, no clear advantage for either option. One advantage of an event over an exception is that it does not interfere with debugging tools (eg. "break on error") - just to pass to the application mere "additional information" that it might not even want/need and should be used for debugging purposes only [1]. [1] Because there is no standardized statusMessage strings that an application could use for something useful besides displaying it. Anyways, a browser can present more useful and consistent troubleshooting UI than every application ever could... imho the troubleshooting/reporting problem should not be pushed to application developers. Regards, ----------------------------------------------------------- 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 gle...@ Fri Apr 29 08:59:40 2011 From: gle...@ (Glenn Maynard) Date: Fri, 29 Apr 2011 11:59:40 -0400 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Fri, Apr 29, 2011 at 11:24 AM, Cedric Vivier wrote: > On Fri, Apr 29, 2011 at 20:08, Benoit Jacob wrote: > > ** Exceptions are a single unified mechanism; while with the > > webglcontextcreationerror way, every new canvas context type will have to > > introduce its own event type. > > This argument implies the Canvas spec defines an exception object that > works for every potential new canvas context type. > Otherwise, every new canvas context type would still have to define > the exception object it throws. > Canvas can just declare a base exception that getContext throws, I think. Contexts would throw exception types that implement it, adding any context-specific information. Exceptions have a strong advantage: they're the ordinary, established method of reporting errors in synchronous functions. Events are used for reporting errors in async functions. I didn't have luck convincing upstream to add an exception path for getContext, but I'd expect much stronger resistance to using an event. One advantage of an event over an exception is that it does not > interfere with debugging tools (eg. "break on error") - just to pass > to the application mere "additional information" that it might not > even want/need and should be used for debugging purposes only [1]. > Debuggers shouldn't be breaking on exceptions that are caught anyway, or they'll have tons of false positives. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Fri Apr 29 09:29:57 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 29 Apr 2011 23:29:57 +0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Fri, Apr 29, 2011 at 22:59, Glenn Maynard wrote: > Canvas can just declare a base exception that getContext throws, I think. > Contexts would throw exception types that implement it, adding any > context-specific information. Agreed, I was just pointing out that the stated advantage of not having to specify context-specific information is pretty much non-existent then. > Exceptions have a strong advantage: they're the ordinary, established method > of reporting errors in synchronous functions.? Events are used for reporting > errors in async functions. That WebGL is not supported _right now_ and cannot be used by the application is already conveyed by null. The fact that it is a temporary error - because of one of many potential reasons - is more of an implementation detail on some platforms/browsers, that should not matter to the applications. Do you agree that we should not push the trouble of troubleshooting (and troubleshooting UI) to application developers? The browser can do much better at it. >? I didn't have luck convincing upstream to add an > exception path for getContext, but I'd expect much stronger resistance to > using an event. Yes I've seen that iirc and I certainly understand their concerns. On the other hand, the event is already what we have and is independent from the Canvas spec (it does not forbid it), so no resistance to fight here. Also, events will possibly be what we use in the future if we go the asynchronous way you've proposed. >> One advantage of an event over an exception is that it does not >> interfere with debugging tools (eg. "break on error") - just to pass >> to the application mere "additional information" that it might not >> even want/need and should be used for debugging purposes only [1]. > > Debuggers shouldn't be breaking on exceptions that are caught anyway, or > they'll have tons of false positives. Yet that's what they do (not limited to JS dev tools)... and developers don't run into tons of false positives because exceptions in JS do happen primarily because of wrong API usage (edit-time) rather than temporary failure (run-time). Regards, ----------------------------------------------------------- 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 cma...@ Fri Apr 29 09:31:16 2011 From: cma...@ (Chris Marrin) Date: Fri, 29 Apr 2011 09:31:16 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: On Apr 28, 2011, at 5:06 PM, Kenneth Russell wrote: > > On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: >> >> On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: >> >>> >>> ... >>> As part of the planned Typed Array API changes to support efficient >>> communication with web workers, the plan is to add convenience methods >>> to copy ArrayBuffers and possibly sub-portions of them. I think we >>> should invest our time in moving those changes forward. >> >> Why is it necessary to have functions to copy ArrayBuffers. Isn't the copy constructor in the TypedArrays sufficient? > > That's a fair point. During one of the face-to-face meetings with > Mozilla it seemed that if we used transfer-of-ownership for > ArrayBuffers sent via postMessage, then we had to make it easy to copy > them. You're right, though, that the slice() operation can be easily > implemented in pure JavaScript, with the only cost the creation of two > temporary Uint8Arrays. > > Should we just get rid of it and provide non-normative text showing > how it could be implemented? That seems better to me. Less is more... ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Fri Apr 29 10:55:08 2011 From: gle...@ (Glenn Maynard) Date: Fri, 29 Apr 2011 13:55:08 -0400 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Fri, Apr 29, 2011 at 12:29 PM, Cedric Vivier wrote: > Agreed, I was just pointing out that the stated advantage of not > having to specify context-specific information is pretty much > non-existent then. > A generic event.message isn't context-specific, and could go in the base exception (with the stipulation that it may be empty). > That WebGL is not supported _right now_ and cannot be used by the > application is already conveyed by null. > The fact that it is a temporary error - because of one of many > potential reasons - is more of an implementation detail on some > platforms/browsers, that should not matter to the applications. > > Do you agree that we should not push the trouble of troubleshooting > (and troubleshooting UI) to application developers? > The browser can do much better at it. > I'm not the one pushing to keep diagnostic messages around. :) That said, while web developers shouldn't be *forced* to handle these errors, it's entirely different to *allow* them to do so. If I'm releasing a commercial game using WebGL, I *want* to be able to support my users. It's certainly better when I don't have to, but there are points between "only the browser can provide troubleshooting at all" and "the application developer is forced to do everything". An aside: It's definitely good if browsers can offer help for known problems. For example, if your video drivers are known to be too old for WebGL, but newer video drivers are available which will work, showing a "you should update your video drivers to make WebGL work, click here for more info" box could be a big help. That's definitely the browser's job and not job of each web page. However, how does the browser know when it's appropriate to show this? If my page is a game and I have no fallback, then I probably do want this. But what if I have a 2d fallback? I (the application developer) may want to simply use it and not distract the user with video driver diagnostics. What if WebGL is used by an optional, secondary feature? I may prefer to simply disable it if it fails. (If using WebGL causes some percentage of users who might have purchased something on a page to instead go off and download video drivers--and forget that they were about to buy something--then that would be a deterrent to using WebGL entirely.) > I didn't have luck convincing upstream to add an > > exception path for getContext, but I'd expect much stronger resistance to > > using an event. > > Yes I've seen that iirc and I certainly understand their concerns. > On the other hand, the event is already what we have and is > independent from the Canvas spec (it does not forbid it), so no > resistance to fight here. > It's awkward to spec "dispatch an event and return null" with the current getContext spec. That should be done from step 2 of getContext ("If contextId is not the name of ..."), and it'd be unnatural to have a definition that looks like: "when required to determine if contextId is the name of a context supported by the user agent, create the underlying context; if it fails, dispatch an event and return false from this algorithm". Whether using events or exceptions, it would be much clearer if getContext was adjusted--right now WebGL is essentially wedging error handling into a function not designed for it. > Yet that's what they do (not limited to JS dev tools)... and > developers don't run into tons of false positives because exceptions > in JS do happen primarily because of wrong API usage (edit-time) > rather than temporary failure (run-time). > It's normal for APIs to throw exceptions based on runtime errors. Design the API properly and debuggers will catch up quickly enough. Debuggers advance over time, but once an API is out there we're stuck with it forever. There aren't so many of these yet because most runtime errors in JavaScript APIs are asynchronous. You'll be seeing more use of traditional exceptions in the future, since the existance of Web Workers means synchronous APIs make more sense. For example, FileReaderSync methods throw on read errors. Web Storage has QUOTA_EXCEEDED_ERR, too. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Fri Apr 29 11:50:45 2011 From: cvi...@ (Cedric Vivier) Date: Sat, 30 Apr 2011 01:50:45 +0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Sat, Apr 30, 2011 at 00:55, Glenn Maynard wrote: >> Do you agree that we should not push the trouble of troubleshooting >> (and troubleshooting UI) to application developers? >> The browser can do much better at it. > > I'm not the one pushing to keep diagnostic messages around.? :) I think we both agree on that ;) However, for now, we are trying to reconcile Canvas spec and WebGL spec as part of a minor revision. > That said, while web developers shouldn't be *forced* to handle these > errors, it's entirely different to *allow* them to do so. Conceptually, an exception *forces* all developers to handle errors through a catch block. An event *allows* only if the developer chooses to. > However, how does the browser know when it's appropriate to show this?? If > my page is a game and I have no fallback, then I probably do want this.? But > what if I have a 2d fallback?? I (the application developer) may want to > simply use it and not distract the user with video driver diagnostics. On top of my head, this could possibly be handled through an unobstrusive UI (geolocation API style) with : _ This web page failed to initialize WebGL [Upgrade my drivers] [Not now] [Forget about it] _ Your use case is doubly interesting as it shows how throwing an exception would force to developers quite a bit of verbosity/indentation to handle multiple fallbacks compared to only handling null... As code examples are worth 1000 words, consider : try { ctx = getContext("webgl-2.0") if (!ctx) { /* webgl-2.0 is not supported _at all_ */ throw "dummy exception to avoid multiple function calls that would make this example even more verbose"; } return initializeWebGL2(ctx); } catch (e) { /* webgl-2.0 is not supported _right now_ */ try { ctx = getContext("webgl") if (!ctx) { /* webgl is not supported _at all_ */ throw "dummy exception to avoid multiple function calls that would make this example even more verbose"; } return initializeWebGL(ctx); } catch (e) { /* webgl is not supported _right now_ */ ctx = getContext("2d") // oh well for this context we do not need a try/catch at least... if (!ctx) { /* 2d is not supported _al all_ */ unsupportedBrowser(); } return initialize2D(ctx); } } VS ctx = getContext("webgl-2.0"); if (ctx) { return initializeWebGL2(ctx); } ctx = getContext("webgl"); /* webgl-2.0 was not supported (at all or right now, we do not really care) */ if (ctx) { return initializeWebGL(ctx); } ctx = getContext("2d"); /* webgl was not supported (at all or right now, we do not really care) */ if (ctx) { return initialize2D(ctx); } unsupportedBrowser(); > It's awkward to spec "dispatch an event and return null" with the current > getContext spec.? That should be done from step 2 of getContext ("If > contextId is not the name of ..."), and it'd be unnatural to have a > definition that looks like: "when required to determine if contextId is the > name of a context supported by the user agent, create the underlying > context; if it fails, dispatch an event and return false from this > algorithm". An application is notified that a context is not supported by returning null. The Canvas spec needs a minimal change equivalent of adding "or not supported _right now_" to the statement above. getContext spec does not have to even talk about the event at all : > Whether using events or exceptions, it would be much clearer if > getContext was adjusted--right now WebGL is essentially wedging error > handling into a function not designed for it. webglcontextcreationerror _is not_ an error-handling mechanism, it is an opt-in mechanism to convey additional debugging/error information only if desired. For all these reasons, I believe throwing an exception changes 1.0 semantics for little benefit if any whereas it adds some clear disadvantages (debugging experience, verbosity, goes against the principle of least surprise). Regards, ----------------------------------------------------------- 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 gle...@ Fri Apr 29 15:06:43 2011 From: gle...@ (Glenn Maynard) Date: Fri, 29 Apr 2011 18:06:43 -0400 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Fri, Apr 29, 2011 at 2:50 PM, Cedric Vivier wrote: > > That said, while web developers shouldn't be *forced* to handle these > > errors, it's entirely different to *allow* them to do so. > > Conceptually, an exception *forces* all developers to handle errors > through a catch block. > An event *allows* only if the developer chooses to. > Your quote is out of context; I was talking about providing end-user support for diagnosing browser problems, not about merely catching an exception. "Forcing" code to catch an exception when an error occurs is completely ordinary. > As code examples are worth 1000 words, consider : > > try { > ctx = getContext("webgl-2.0") > if (!ctx) { /* webgl-2.0 is not supported _at all_ */ > throw "dummy exception to avoid multiple function calls that > would make this example even more verbose"; > } > return initializeWebGL2(ctx); > } catch (e) { /* webgl-2.0 is not supported _right now_ */ > try { > ctx = getContext("webgl") > if (!ctx) { /* webgl is not supported _at all_ */ > throw "dummy exception to avoid multiple function calls > that would make this example even more verbose"; > } > return initializeWebGL(ctx); > } catch (e) { /* webgl is not supported _right now_ */ > ctx = getContext("2d") // oh well for this context we do not > need a try/catch at least... > if (!ctx) { /* 2d is not supported _al all_ */ > unsupportedBrowser(); > } > return initialize2D(ctx); > } > } > If you don't care about the information in the exception you can just write a function. You don't need anything convoluted. HTMLCanvasElement.prototype.getContextWithoutExceptions = function() { try { return this.getContext.apply(this, arguments); } catch(e) { return null; } }; ctx = canvas.getContextWithoutExceptions("webgl"); >From what Benoit described, you'll need to do this anyway if you want compatibility with current versions of Firefox. An application is notified that a context is not supported by returning > null. > The Canvas spec needs a minimal change equivalent of adding "or not > supported _right now_" to the statement above. > > getContext spec does not have to even talk about the event at all : > I think you're misunderstanding the problem. The WebGL spec defines getContext as if it owns that API, but that API is part of and defined by the Canvas spec. WebGL talks about things like "called for the first time" and "subsequent calls". This is all precisely defined by HTML5. A spec that's making use of getContext should be defining it in terms of the existing Canvas spec. That means defining things like "Return a new object for the contextId 'webgl'"--an abstract method called by the getContext spec--as 2d Canvas does. If you ignore the normative spec for getContext, then you can indeed define getContext to do whatever you want, include dispatching an event, but that's not a good way to spec an API that makes use of another API. This is what I'm trying to help fix. > Whether using events or exceptions, it would be much clearer if > > getContext was adjusted--right now WebGL is essentially wedging error > > handling into a function not designed for it. > > webglcontextcreationerror _is not_ an error-handling mechanism, it is > an opt-in mechanism to convey additional debugging/error information > only if desired. > Semantic nitpicks aside, it's not something that getContext supports. This should be any easy thing to change, but the change belongs in HTML5, not by redefining getContext outside of HTML5. For all these reasons, I believe throwing an exception changes 1.0 > semantics for little benefit if any whereas it adds some clear > disadvantages (debugging experience, verbosity, goes against the > principle of least surprise). > I disagree with each these. If throwing an exception causes problems with debuggers, the debuggers need improvement. (Again, don't write APIs in unnatural ways to cope with temporary bugs in tools; write them correctly and the tools will improve.) It doesn't cause verbosity (you can write code identically, if you want, as above), and I find just the opposite: it's surprising to find that I have to listen to an event to read an error message from a synchronous call. I'm not married to throwing an exception (though I do strongly believe it's cleaner than an event); the problem is that I don't thing *either* way can be specced properly without some help from HTML5's getContext spec. It would be nice if somebody more directly involved with WebGL could contact Ian Hickson about adding an error reporting mechanism--of any kind--to the getContext spec. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: