From pub...@ Sun Mar 22 12:59:20 2020 From: pub...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?= (...@...)) Date: Sun, 22 Mar 2020 21:59:20 +0200 Subject: [Public WebGL] EXT_pvrtc_sRGB extension to WebGL? In-Reply-To: References: Message-ID: Hi Kai, sorry for the very delayed reply. (the delay in the reply probably hints towards the answer..) We have had one or two queries from customers about supporting PVRTC as sRGB. If such an extension were available, Unity would easily be able to hook into using it, but the number of requests has not been particularly wide. I suppose it would be nice to have for parity, but looks like at this point it is not the biggest request or a showstopper by any account. Cheers, Jukka ke 4. jouluk. 2019 klo 22.14 Kai Ninomiya (kainino...@) kirjoitti: > > Hey Jukka, could you confirm whether ETC2 sRGB formats work as a replacement for PVRTC sRGB? > > On Thu, Oct 3, 2019 at 1:31 PM Ken Russell (kbr...@) wrote: >> >> FYI: collaboration with Apple's WebKit team is underway to support the ETC1 and ETC2 compressed texture formats in https://bugs.webkit.org/show_bug.cgi?id=197900 . ASTC support is already in WebKit but currently behind a flag; another goal is to take it out from behind that flag. >> >> -Ken >> >> >> On Thu, Oct 3, 2019 at 7:37 AM Kai Ninomiya (kainino...@) wrote: >>> >>> These devices also support ETC2-sRGB via OpenGL ES 3.0, but the WebGL 1/2 extension is not exposed yet in Safari. Would that work for you? Overall we are trying to focus on having good support for a smaller set of formats (ETC2 on mobile, S3TC on desktop, optionally ASTC) if other formats aren't necessary. >>> >>> On Wed, Oct 2, 2019, 7:07 AM Jukka Jyl?nki (jujjyl...@) wrote: >>>> >>>> >>>> Hi all, >>>> >>>> I wonder if there have been any prior discussions about adding >>>> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_pvrtc_sRGB.txt >>>> support over to WebGL side? >>>> >>>> That would help towards enabling Unity support for linear color space >>>> rendering on Apple iOS devices. >>>> >>>> Cheers, >>>> Jukka >>>> >>>> ----------------------------------------------------------- >>>> You are currently subscribed to public_webgl...@ >>>> To unsubscribe, send an email to majordomo...@ with >>>> the following command in the body of your email: >>>> unsubscribe public_webgl >>>> ----------------------------------------------------------- >>>> ----------------------------------------------------------- You are currently 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 pub...@ Sun Mar 22 13:04:27 2020 From: pub...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?= (...@...)) Date: Sun, 22 Mar 2020 22:04:27 +0200 Subject: [Public WebGL] OES_draw_elements_base_vertex extension to WebGL? Message-ID: Hello all, here's another extension that has come up in conversations: https://www.khronos.org/registry/OpenGL/extensions/OES/OES_draw_elements_base_vertex.txt That extension would help pack a lot of static indexed geometry into a single vertex+index buffer. There does exist the draft extension https://www.khronos.org/registry/webgl/extensions/WEBGL_draw_instanced_base_vertex_base_instance/ , which could be used for this, by placing instanceCount=1, baseInstance=0, though I wonder if it would be possibly more optimal or more widely supported to specifically enable the non-instanced variant as a glDrawElementsBaseVertex() function? Cheers, Jukka ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pub...@ Sun Mar 22 13:21:18 2020 From: pub...@ (Shrek Shao (...@...)) Date: Sun, 22 Mar 2020 13:21:18 -0700 Subject: [Public WebGL] OES_draw_elements_base_vertex extension to WebGL? In-Reply-To: References: Message-ID: Thanks Jukka for the feedback. Yes I was also considering adding the non-base-instance version entry point glDrawElementsBaseVertex as well to the extension based on some first round profiling. Your suggestion gives me more motivation to try this out. I will make a profiling comparison and bring this up in the WebGL working group meeting. On Sun, Mar 22, 2020 at 1:05 PM Jukka Jyl?nki (jujjyl...@) < public_webgl...@> wrote: > > Hello all, > > here's another extension that has come up in conversations: > > > https://www.khronos.org/registry/OpenGL/extensions/OES/OES_draw_elements_base_vertex.txt > > That extension would help pack a lot of static indexed geometry into a > single vertex+index buffer. > > There does exist the draft extension > > https://www.khronos.org/registry/webgl/extensions/WEBGL_draw_instanced_base_vertex_base_instance/ > , which could be used for this, by placing instanceCount=1, > baseInstance=0, though I wonder if it would be possibly more optimal > or more widely supported to specifically enable the non-instanced > variant as a glDrawElementsBaseVertex() function? > > Cheers, > Jukka > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Sun Mar 22 14:27:53 2020 From: pub...@ (Kai Ninomiya (...@...)) Date: Sun, 22 Mar 2020 14:27:53 -0700 Subject: [Public WebGL] OES_draw_elements_base_vertex extension to WebGL? In-Reply-To: References: Message-ID: I suspect we'll find that the performance is about the same, but we should definitely look into whether the support would be any wider On Sun, Mar 22, 2020 at 1:22 PM Shrek Shao (shrekshao...@) < public_webgl...@> wrote: > Thanks Jukka for the feedback. Yes I was also considering adding the > non-base-instance version entry point glDrawElementsBaseVertex as well to > the extension based on some first round profiling. Your suggestion gives me > more motivation to try this out. I will make a profiling comparison and > bring this up in the WebGL working group meeting. > > On Sun, Mar 22, 2020 at 1:05 PM Jukka Jyl?nki (jujjyl...@) < > public_webgl...@> wrote: > >> >> Hello all, >> >> here's another extension that has come up in conversations: >> >> >> https://www.khronos.org/registry/OpenGL/extensions/OES/OES_draw_elements_base_vertex.txt >> >> That extension would help pack a lot of static indexed geometry into a >> single vertex+index buffer. >> >> There does exist the draft extension >> >> https://www.khronos.org/registry/webgl/extensions/WEBGL_draw_instanced_base_vertex_base_instance/ >> , which could be used for this, by placing instanceCount=1, >> baseInstance=0, though I wonder if it would be possibly more optimal >> or more widely supported to specifically enable the non-instanced >> variant as a glDrawElementsBaseVertex() function? >> >> Cheers, >> Jukka >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3852 bytes Desc: S/MIME Cryptographic Signature URL: From pub...@ Mon Mar 23 11:41:17 2020 From: pub...@ (Kai Ninomiya (...@...)) Date: Mon, 23 Mar 2020 11:41:17 -0700 Subject: [Public WebGL] EXT_pvrtc_sRGB extension to WebGL? In-Reply-To: References: Message-ID: Thanks Jukka! I think we should continue prioritizing the ETC2-sRGB format support then. On Sun, Mar 22, 2020 at 12:59 PM Jukka Jyl?nki wrote: > Hi Kai, > > sorry for the very delayed reply. (the delay in the reply probably > hints towards the answer..) > > We have had one or two queries from customers about supporting PVRTC > as sRGB. If such an extension were available, Unity would easily be > able to hook into using it, but the number of requests has not been > particularly wide. I suppose it would be nice to have for parity, but > looks like at this point it is not the biggest request or a > showstopper by any account. > > Cheers, > Jukka > > ke 4. jouluk. 2019 klo 22.14 Kai Ninomiya (kainino...@) kirjoitti: > > > > Hey Jukka, could you confirm whether ETC2 sRGB formats work as a > replacement for PVRTC sRGB? > > > > On Thu, Oct 3, 2019 at 1:31 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > >> > >> FYI: collaboration with Apple's WebKit team is underway to support the > ETC1 and ETC2 compressed texture formats in > https://bugs.webkit.org/show_bug.cgi?id=197900 . ASTC support is already > in WebKit but currently behind a flag; another goal is to take it out from > behind that flag. > >> > >> -Ken > >> > >> > >> On Thu, Oct 3, 2019 at 7:37 AM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > >>> > >>> These devices also support ETC2-sRGB via OpenGL ES 3.0, but the WebGL > 1/2 extension is not exposed yet in Safari. Would that work for you? > Overall we are trying to focus on having good support for a smaller set of > formats (ETC2 on mobile, S3TC on desktop, optionally ASTC) if other formats > aren't necessary. > >>> > >>> On Wed, Oct 2, 2019, 7:07 AM Jukka Jyl?nki (jujjyl...@) < > public_webgl...@> wrote: > >>>> > >>>> > >>>> Hi all, > >>>> > >>>> I wonder if there have been any prior discussions about adding > >>>> > https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_pvrtc_sRGB.txt > >>>> support over to WebGL side? > >>>> > >>>> That would help towards enabling Unity support for linear color space > >>>> rendering on Apple iOS devices. > >>>> > >>>> Cheers, > >>>> Jukka > >>>> > >>>> ----------------------------------------------------------- > >>>> You are currently subscribed to public_webgl...@ > >>>> To unsubscribe, send an email to majordomo...@ with > >>>> the following command in the body of your email: > >>>> unsubscribe public_webgl > >>>> ----------------------------------------------------------- > >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3852 bytes Desc: S/MIME Cryptographic Signature URL: From pub...@ Wed Mar 25 13:10:35 2020 From: pub...@ (Ken Russell (...@...)) Date: Wed, 25 Mar 2020 13:10:35 -0700 Subject: [Public WebGL] WebGL Best Practices Message-ID: [cross-posted to webgl-dev-list] Dear WebGL community: Mozilla, with contributions from the rest of the WebGL working group, has just revised the WebGL Best Practices document. It contains a significant number of tips for best structuring WebGL applications and attaining top performance. Please check it out! On behalf of the WebGL working group, -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Thu Mar 26 01:45:26 2020 From: pub...@ (Michal Vodicka (...@...)) Date: Thu, 26 Mar 2020 09:45:26 +0100 Subject: [Public WebGL] WebGL Best Practices In-Reply-To: References: Message-ID: Hello Ken, that is awesome!!! Instant bookmark. Best regards, Michal Vodicka On Wed, Mar 25, 2020 at 9:11 PM Ken Russell (kbr...@) wrote: > > [cross-posted to webgl-dev-list] > > Dear WebGL community: > > Mozilla, with contributions from the rest of the WebGL working group, has just revised the WebGL Best Practices document. It contains a significant number of tips for best structuring WebGL applications and attaining top performance. Please check it out! > > On behalf of the WebGL working group, > > -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 pub...@ Thu Mar 26 05:04:20 2020 From: pub...@ (Won Chun (...@...)) Date: Thu, 26 Mar 2020 08:04:20 -0400 Subject: [Public WebGL] WebGL Best Practices In-Reply-To: References: Message-ID: Are there more resources about requestPostAnimationFrame? First I've heard of rPAF. -Won On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr...@) < public_webgl...@> wrote: > [cross-posted to webgl-dev-list] > > Dear WebGL community: > > Mozilla, with contributions from the rest of the WebGL working group, has > just revised the WebGL Best Practices > document. > It contains a significant number of tips for best structuring WebGL > applications and attaining top performance. Please check it out! > > On behalf of the WebGL working group, > > -Ken > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Thu Mar 26 11:39:45 2020 From: pub...@ (Kai Ninomiya (...@...)) Date: Thu, 26 Mar 2020 11:39:45 -0700 Subject: [Public WebGL] WebGL Best Practices In-Reply-To: References: Message-ID: The MDN doc links to an explainer: https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md It's pretty small, but it's also not a very complex feature (implementation-wise). As explained there, the original motivation was to allow querying computed DOM properties at a time when it's guaranteed it won't force a relayout. On Thu, Mar 26, 2020 at 5:05 AM Won Chun (won...@) < public_webgl...@> wrote: > Are there more resources about requestPostAnimationFrame? First I've heard > of rPAF. > > -Won > > On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr...@) < > public_webgl...@> wrote: > >> [cross-posted to webgl-dev-list] >> >> Dear WebGL community: >> >> Mozilla, with contributions from the rest of the WebGL working group, has >> just revised the WebGL Best Practices >> document. >> It contains a significant number of tips for best structuring WebGL >> applications and attaining top performance. Please check it out! >> >> On behalf of the WebGL working group, >> >> -Ken >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3852 bytes Desc: S/MIME Cryptographic Signature URL: From pub...@ Thu Mar 26 12:51:57 2020 From: pub...@ (Ken Russell (...@...)) Date: Thu, 26 Mar 2020 12:51:57 -0700 Subject: [Public WebGL] WebGL Best Practices In-Reply-To: References: Message-ID: Note that there's an active ongoing discussion about the requestPostAnimationFrame best practice. It seems that the polyfill works well in Firefox, but not in Chrome. Suggest holding off adding that to your applications for the moment. -Ken On Thu, Mar 26, 2020 at 11:40 AM Kai Ninomiya (kainino...@) < public_webgl...@> wrote: > The MDN doc links to an explainer: > https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md > It's pretty small, but it's also not a very complex feature > (implementation-wise). As explained there, the original motivation was to > allow querying computed DOM properties at a time when it's guaranteed it > won't force a relayout. > > On Thu, Mar 26, 2020 at 5:05 AM Won Chun (won...@) < > public_webgl...@> wrote: > >> Are there more resources about requestPostAnimationFrame? First I've >> heard of rPAF. >> >> -Won >> >> On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr...@) < >> public_webgl...@> wrote: >> >>> [cross-posted to webgl-dev-list] >>> >>> Dear WebGL community: >>> >>> Mozilla, with contributions from the rest of the WebGL working group, >>> has just revised the WebGL Best Practices >>> document. >>> It contains a significant number of tips for best structuring WebGL >>> applications and attaining top performance. Please check it out! >>> >>> On behalf of the WebGL working group, >>> >>> -Ken >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri Mar 27 09:08:49 2020 From: pub...@ (Ashley Gullen (...@...)) Date: Fri, 27 Mar 2020 16:08:49 +0000 Subject: [Public WebGL] WebGL Best Practices In-Reply-To: References: Message-ID: Why doesn't it work well in Chrome? rPAF seems to intuitively make sense once explained. Do you have a link to the discussion? On Thu, 26 Mar 2020 at 19:52, Ken Russell (kbr...@) < public_webgl...@> wrote: > Note that there's an active ongoing discussion about the > requestPostAnimationFrame best practice. It seems that the polyfill works > well in Firefox, but not in Chrome. Suggest holding off adding that to your > applications for the moment. > > -Ken > > > On Thu, Mar 26, 2020 at 11:40 AM Kai Ninomiya (kainino...@) < > public_webgl...@> wrote: > >> The MDN doc links to an explainer: >> https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md >> It's pretty small, but it's also not a very complex feature >> (implementation-wise). As explained there, the original motivation was to >> allow querying computed DOM properties at a time when it's guaranteed it >> won't force a relayout. >> >> On Thu, Mar 26, 2020 at 5:05 AM Won Chun (won...@) < >> public_webgl...@> wrote: >> >>> Are there more resources about requestPostAnimationFrame? First I've >>> heard of rPAF. >>> >>> -Won >>> >>> On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr...@) < >>> public_webgl...@> wrote: >>> >>>> [cross-posted to webgl-dev-list] >>>> >>>> Dear WebGL community: >>>> >>>> Mozilla, with contributions from the rest of the WebGL working group, >>>> has just revised the WebGL Best Practices >>>> document. >>>> It contains a significant number of tips for best structuring WebGL >>>> applications and attaining top performance. Please check it out! >>>> >>>> On behalf of the WebGL working group, >>>> >>>> -Ken >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pub...@ Fri Mar 27 10:29:01 2020 From: pub...@ (Ken Russell (...@...)) Date: Fri, 27 Mar 2020 10:29:01 -0700 Subject: [Public WebGL] WebGL Best Practices In-Reply-To: References: Message-ID: The investigation is underway in http://crbug.com/1065012 . The native implementation of requestPostAnimationFrame , which is behind the --enable-experimental-web-platform-features flag in Chrome, doesn't exhibit this problem. For the time being, the rPAF polyfill can be used in Firefox, and seems to carry some benefit there. On Fri, Mar 27, 2020 at 9:09 AM Ashley Gullen (ashley...@) < public_webgl...@> wrote: > Why doesn't it work well in Chrome? rPAF seems to intuitively make sense > once explained. Do you have a link to the discussion? > > On Thu, 26 Mar 2020 at 19:52, Ken Russell (kbr...@) < > public_webgl...@> wrote: > >> Note that there's an active ongoing discussion about the >> requestPostAnimationFrame best practice. It seems that the polyfill works >> well in Firefox, but not in Chrome. Suggest holding off adding that to your >> applications for the moment. >> >> -Ken >> >> >> On Thu, Mar 26, 2020 at 11:40 AM Kai Ninomiya (kainino...@) < >> public_webgl...@> wrote: >> >>> The MDN doc links to an explainer: >>> >>> https://github.com/WICG/requestPostAnimationFrame/blob/master/explainer.md >>> It's pretty small, but it's also not a very complex feature >>> (implementation-wise). As explained there, the original motivation was to >>> allow querying computed DOM properties at a time when it's guaranteed it >>> won't force a relayout. >>> >>> On Thu, Mar 26, 2020 at 5:05 AM Won Chun (won...@) < >>> public_webgl...@> wrote: >>> >>>> Are there more resources about requestPostAnimationFrame? First I've >>>> heard of rPAF. >>>> >>>> -Won >>>> >>>> On Wed, Mar 25, 2020, 4:11 PM Ken Russell (kbr...@) < >>>> public_webgl...@> wrote: >>>> >>>>> [cross-posted to webgl-dev-list] >>>>> >>>>> Dear WebGL community: >>>>> >>>>> Mozilla, with contributions from the rest of the WebGL working group, >>>>> has just revised the WebGL Best Practices >>>>> document. >>>>> It contains a significant number of tips for best structuring WebGL >>>>> applications and attaining top performance. Please check it out! >>>>> >>>>> On behalf of the WebGL working group, >>>>> >>>>> -Ken >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: