From joh...@ Thu Aug 1 06:12:45 2013 From: joh...@ (Johannes Behr) Date: Thu, 1 Aug 2013 15:12:45 +0200 Subject: [Public WebGL] IE 11 In-Reply-To: References: Message-ID: <7183174D-AB96-4422-92DA-E0A94F7448F3@gmail.com> Hi, we have some issues while testing X3DOM on IE11. There are some strange limitations in regards to function calls in GLSL. Is Ben Constable reading this list? Is there a WebGL-related bug-tracker for IE11? Best regards Johannes > > Let's not jump to the conclusion that Microsoft will never fully > support the WebGL specification. It is clear that the implementation > in IE 11 is incomplete. The majority of demos I tested with it didn't > work because of some entry point or another simply being > unimplemented. Microsoft stated in the WebGL BOF at SIGGRAPH that they > know their implementation is incomplete, and they're prioritizing what > missing pieces to fix. > > At the same time, yes, the WebGL community should collectively reach > out to Microsoft to point out use cases that don't work. I suspect > they will realize that the entry points they've stated they have no > intent to support (like VertexAttrib[1234]f[v]) are not difficult to > emulate, and are required for some applications. > > Finally, from talking with Ben Constable at SIGGRAPH (Principal > Engineer on IE and author of its WebGL implementation), Microsoft has > good ideas about how to specify whether a given shader is going to run > on a given piece of hardware, and defining performance characteristics > of the GPU. I am looking forward to collaborating with them to improve > the WebGL spec. > > -Ken > > > > On Wed, Jul 31, 2013 at 10:36 AM, Brandon Jones wrote: >> It seems to me like the most effective thing at the moment may be to try and >> mobilize WebGL developers to contact Microsoft with real-world apps/demos >> that indicate a need for API "X". I'd imagine that if enough developers >> wrote in eventually the entire API would worm it's way onto Microsoft's >> "priority" list. >> >> And, if after all that some APIs just don't see much or any demand, it's >> honestly probably not a crisis is MS excludes them. I'm all for supporting >> the standard as is, but there is something to be said for not spending >> resources supporting a function call only 3 developers have ever tried. >> >> --Brandon >> >> >> On Wed, Jul 31, 2013 at 10:26 AM, Ben Vanik wrote: >>> >>> (opinions are my own, not my employers) >>> >>> What IE is shipping should be called 'WebGL Lite', if they are not going >>> to be implementing the full spec. >>> >>> Had they wanted to encourage the removal of these calls from the spec they >>> should have participated earlier. Developers writing code will now have to >>> worry about which features IE has arbitrarily chosen not to implement and as >>> such will learn to avoid using them even though doing so may have been a >>> perfectly sensible thing to do. It feels like a ham-fisted effort to force >>> changes to the spec after it's been shipped without the involvement of >>> Khronos and its members (who spent a great deal of effort making sure the >>> spec was good) or the community. >>> >>> Can anyone help the IE team see reason here? I feel like they are hurting >>> their image in what could have been their moment of triumph :/ >>> >>> >>> >>> On Wed, Jul 31, 2013 at 4:50 AM, Daniel Koch wrote: >>>> >>>> That seems kind of silly. There already is an existence proof out there >>>> that all the WebGL features can be mapped to D3D9 and D3D11 fairly >>>> reasonably? (and it's even open source if they need help figuring it out). >>>> Ah well, I suppose something is better than nothing? >>>> >>>> -Daniel >>>> >>>> >>>> Microsoft's message at the moment is that it's an early developer preview >>>> and they are actively working on implementing more functionality before >>>> launch. They have also stated that they do not intend to implement every >>>> WebGL API (They explicitly called out vertexAttrib[1234]f as an API they are >>>> planning to ignore as it doesn't map to D3D11 well), and are looking for >>>> developer feedback on which APIs should receive priority. >>>> >>>> --Brandon >>>> >>>> >>>> On Tue, Jul 30, 2013 at 5:19 PM, Mark Callow >>>> wrote: >>>>> >>>>> I tried the IE 11 preview. The simple get.webgl.org cube works as does >>>>> the slightly more complex one on khronos.org. However the WebGL aquarium >>>>> does not. I get a cyan background and the menu but nothing else. I do not >>>>> have time to investigate. >>>>> >>>>> Regards >>>>> >>>>> -Mark >>>>> >>>>> -- >>>>> ???????????????????????????????????????????????????????????????? >>>>> ???????????????????????????????????????????????????????????????? ??. >>>>> >>>>> NOTE: This electronic mail message may contain confidential and >>>>> privileged information from HI Corporation. If you are not the intended >>>>> recipient, any disclosure, photocopying, distribution or use of the contents >>>>> of the received information is prohibited. If you have received this e-mail >>>>> in error, please notify the sender immediately and permanently delete this >>>>> message and all related copies. >>>> >>>> >>> >> > > ----------------------------------------------------------- > You are currently 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 elf...@ Thu Aug 1 07:00:42 2013 From: elf...@ (=?ISO-8859-1?Q?Francisco_=C1vila?=) Date: Thu, 1 Aug 2013 09:00:42 -0500 Subject: [Public WebGL] IE 11 In-Reply-To: <7183174D-AB96-4422-92DA-E0A94F7448F3@gmail.com> References: <7183174D-AB96-4422-92DA-E0A94F7448F3@gmail.com> Message-ID: Hi, he said that we can report bugs in http://connect.microsoft.com or in his email (bencon at microsoft dot com). What kind of limitations? he also mentioned that there is a maximum size for shaders (I guess it was 16K). ~Frank On Thu, Aug 1, 2013 at 8:12 AM, Johannes Behr wrote: > > Hi, > > we have some issues while testing X3DOM on IE11. There are some strange > limitations in regards to function calls in GLSL. > Is Ben Constable reading this list? Is there a WebGL-related bug-tracker > for IE11? > > Best regards > Johannes > > > > > Let's not jump to the conclusion that Microsoft will never fully > > support the WebGL specification. It is clear that the implementation > > in IE 11 is incomplete. The majority of demos I tested with it didn't > > work because of some entry point or another simply being > > unimplemented. Microsoft stated in the WebGL BOF at SIGGRAPH that they > > know their implementation is incomplete, and they're prioritizing what > > missing pieces to fix. > > > > At the same time, yes, the WebGL community should collectively reach > > out to Microsoft to point out use cases that don't work. I suspect > > they will realize that the entry points they've stated they have no > > intent to support (like VertexAttrib[1234]f[v]) are not difficult to > > emulate, and are required for some applications. > > > > Finally, from talking with Ben Constable at SIGGRAPH (Principal > > Engineer on IE and author of its WebGL implementation), Microsoft has > > good ideas about how to specify whether a given shader is going to run > > on a given piece of hardware, and defining performance characteristics > > of the GPU. I am looking forward to collaborating with them to improve > > the WebGL spec. > > > > -Ken > > > > > > > > On Wed, Jul 31, 2013 at 10:36 AM, Brandon Jones > wrote: > >> It seems to me like the most effective thing at the moment may be to > try and > >> mobilize WebGL developers to contact Microsoft with real-world > apps/demos > >> that indicate a need for API "X". I'd imagine that if enough developers > >> wrote in eventually the entire API would worm it's way onto Microsoft's > >> "priority" list. > >> > >> And, if after all that some APIs just don't see much or any demand, it's > >> honestly probably not a crisis is MS excludes them. I'm all for > supporting > >> the standard as is, but there is something to be said for not spending > >> resources supporting a function call only 3 developers have ever tried. > >> > >> --Brandon > >> > >> > >> On Wed, Jul 31, 2013 at 10:26 AM, Ben Vanik > wrote: > >>> > >>> (opinions are my own, not my employers) > >>> > >>> What IE is shipping should be called 'WebGL Lite', if they are not > going > >>> to be implementing the full spec. > >>> > >>> Had they wanted to encourage the removal of these calls from the spec > they > >>> should have participated earlier. Developers writing code will now > have to > >>> worry about which features IE has arbitrarily chosen not to implement > and as > >>> such will learn to avoid using them even though doing so may have been > a > >>> perfectly sensible thing to do. It feels like a ham-fisted effort to > force > >>> changes to the spec after it's been shipped without the involvement of > >>> Khronos and its members (who spent a great deal of effort making sure > the > >>> spec was good) or the community. > >>> > >>> Can anyone help the IE team see reason here? I feel like they are > hurting > >>> their image in what could have been their moment of triumph :/ > >>> > >>> > >>> > >>> On Wed, Jul 31, 2013 at 4:50 AM, Daniel Koch wrote: > >>>> > >>>> That seems kind of silly. There already is an existence proof out > there > >>>> that all the WebGL features can be mapped to D3D9 and D3D11 fairly > >>>> reasonably? (and it's even open source if they need help figuring it > out). > >>>> Ah well, I suppose something is better than nothing? > >>>> > >>>> -Daniel > >>>> > >>>> > >>>> Microsoft's message at the moment is that it's an early developer > preview > >>>> and they are actively working on implementing more functionality > before > >>>> launch. They have also stated that they do not intend to implement > every > >>>> WebGL API (They explicitly called out vertexAttrib[1234]f as an API > they are > >>>> planning to ignore as it doesn't map to D3D11 well), and are looking > for > >>>> developer feedback on which APIs should receive priority. > >>>> > >>>> --Brandon > >>>> > >>>> > >>>> On Tue, Jul 30, 2013 at 5:19 PM, Mark Callow < > callow.mark...@> > >>>> wrote: > >>>>> > >>>>> I tried the IE 11 preview. The simple get.webgl.org cube works as > does > >>>>> the slightly more complex one on khronos.org. However the WebGL > aquarium > >>>>> does not. I get a cyan background and the menu but nothing else. I > do not > >>>>> have time to investigate. > >>>>> > >>>>> Regards > >>>>> > >>>>> -Mark > >>>>> > >>>>> -- > >>>>> ???????????????????????????????????????????????????????????????? > >>>>> ???????????????????????????????????????????????????????????????? ??. > >>>>> > >>>>> NOTE: This electronic mail message may contain confidential and > >>>>> privileged information from HI Corporation. If you are not the > intended > >>>>> recipient, any disclosure, photocopying, distribution or use of the > contents > >>>>> of the received information is prohibited. If you have received this > e-mail > >>>>> in error, please notify the sender immediately and permanently > delete this > >>>>> message and all related copies. > >>>> > >>>> > >>> > >> > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thu...@ Thu Aug 1 07:26:32 2013 From: thu...@ (Ben Adams) Date: Thu, 1 Aug 2013 15:26:32 +0100 Subject: [Public WebGL] IE 11 In-Reply-To: References: <7183174D-AB96-4422-92DA-E0A94F7448F3@gmail.com> Message-ID: As Frank says If you join the IE11 Public Feedback Program here: https://connect.microsoft.com/directory/accepting-bugs/internet/ There is an issue tracker and a set of community forums for it. Kind regards Ben On 1 August 2013 15:00, Francisco ?vila wrote: > Hi, > > he said that we can report bugs in http://connect.microsoft.com or in his > email (bencon at microsoft dot com). > > What kind of limitations? he also mentioned that there is a maximum size > for shaders (I guess it was 16K). > > ~Frank > > > On Thu, Aug 1, 2013 at 8:12 AM, Johannes Behr wrote: > >> >> Hi, >> >> we have some issues while testing X3DOM on IE11. There are some strange >> limitations in regards to function calls in GLSL. >> Is Ben Constable reading this list? Is there a WebGL-related bug-tracker >> for IE11? >> >> Best regards >> Johannes >> >> > >> > Let's not jump to the conclusion that Microsoft will never fully >> > support the WebGL specification. It is clear that the implementation >> > in IE 11 is incomplete. The majority of demos I tested with it didn't >> > work because of some entry point or another simply being >> > unimplemented. Microsoft stated in the WebGL BOF at SIGGRAPH that they >> > know their implementation is incomplete, and they're prioritizing what >> > missing pieces to fix. >> > >> > At the same time, yes, the WebGL community should collectively reach >> > out to Microsoft to point out use cases that don't work. I suspect >> > they will realize that the entry points they've stated they have no >> > intent to support (like VertexAttrib[1234]f[v]) are not difficult to >> > emulate, and are required for some applications. >> > >> > Finally, from talking with Ben Constable at SIGGRAPH (Principal >> > Engineer on IE and author of its WebGL implementation), Microsoft has >> > good ideas about how to specify whether a given shader is going to run >> > on a given piece of hardware, and defining performance characteristics >> > of the GPU. I am looking forward to collaborating with them to improve >> > the WebGL spec. >> > >> > -Ken >> > >> > >> > >> > On Wed, Jul 31, 2013 at 10:36 AM, Brandon Jones >> wrote: >> >> It seems to me like the most effective thing at the moment may be to >> try and >> >> mobilize WebGL developers to contact Microsoft with real-world >> apps/demos >> >> that indicate a need for API "X". I'd imagine that if enough developers >> >> wrote in eventually the entire API would worm it's way onto Microsoft's >> >> "priority" list. >> >> >> >> And, if after all that some APIs just don't see much or any demand, >> it's >> >> honestly probably not a crisis is MS excludes them. I'm all for >> supporting >> >> the standard as is, but there is something to be said for not spending >> >> resources supporting a function call only 3 developers have ever tried. >> >> >> >> --Brandon >> >> >> >> >> >> On Wed, Jul 31, 2013 at 10:26 AM, Ben Vanik >> wrote: >> >>> >> >>> (opinions are my own, not my employers) >> >>> >> >>> What IE is shipping should be called 'WebGL Lite', if they are not >> going >> >>> to be implementing the full spec. >> >>> >> >>> Had they wanted to encourage the removal of these calls from the spec >> they >> >>> should have participated earlier. Developers writing code will now >> have to >> >>> worry about which features IE has arbitrarily chosen not to implement >> and as >> >>> such will learn to avoid using them even though doing so may have >> been a >> >>> perfectly sensible thing to do. It feels like a ham-fisted effort to >> force >> >>> changes to the spec after it's been shipped without the involvement of >> >>> Khronos and its members (who spent a great deal of effort making sure >> the >> >>> spec was good) or the community. >> >>> >> >>> Can anyone help the IE team see reason here? I feel like they are >> hurting >> >>> their image in what could have been their moment of triumph :/ >> >>> >> >>> >> >>> >> >>> On Wed, Jul 31, 2013 at 4:50 AM, Daniel Koch >> wrote: >> >>>> >> >>>> That seems kind of silly. There already is an existence proof out >> there >> >>>> that all the WebGL features can be mapped to D3D9 and D3D11 fairly >> >>>> reasonably? (and it's even open source if they need help figuring it >> out). >> >>>> Ah well, I suppose something is better than nothing? >> >>>> >> >>>> -Daniel >> >>>> >> >>>> >> >>>> Microsoft's message at the moment is that it's an early developer >> preview >> >>>> and they are actively working on implementing more functionality >> before >> >>>> launch. They have also stated that they do not intend to implement >> every >> >>>> WebGL API (They explicitly called out vertexAttrib[1234]f as an API >> they are >> >>>> planning to ignore as it doesn't map to D3D11 well), and are looking >> for >> >>>> developer feedback on which APIs should receive priority. >> >>>> >> >>>> --Brandon >> >>>> >> >>>> >> >>>> On Tue, Jul 30, 2013 at 5:19 PM, Mark Callow < >> callow.mark...@> >> >>>> wrote: >> >>>>> >> >>>>> I tried the IE 11 preview. The simple get.webgl.org cube works as >> does >> >>>>> the slightly more complex one on khronos.org. However the WebGL >> aquarium >> >>>>> does not. I get a cyan background and the menu but nothing else. I >> do not >> >>>>> have time to investigate. >> >>>>> >> >>>>> Regards >> >>>>> >> >>>>> -Mark >> >>>>> >> >>>>> -- >> >>>>> ???????????????????????????????????????????????????????????????? >> >>>>> ???????????????????????????????????????????????????????????????? ??. >> >>>>> >> >>>>> NOTE: This electronic mail message may contain confidential and >> >>>>> privileged information from HI Corporation. If you are not the >> intended >> >>>>> recipient, any disclosure, photocopying, distribution or use of the >> contents >> >>>>> of the received information is prohibited. If you have received >> this e-mail >> >>>>> in error, please notify the sender immediately and permanently >> delete this >> >>>>> message and all related copies. >> >>>> >> >>>> >> >>> >> >> >> > >> > ----------------------------------------------------------- >> > You are currently subscribed to public_webgl...@ >> > To unsubscribe, send an email to majordomo...@ with >> > the following command in the body of your email: >> > unsubscribe public_webgl >> > ----------------------------------------------------------- >> > >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joh...@ Thu Aug 1 08:13:21 2013 From: joh...@ (Johannes Behr) Date: Thu, 1 Aug 2013 17:13:21 +0200 Subject: [Public WebGL] IE 11 In-Reply-To: References: <7183174D-AB96-4422-92DA-E0A94F7448F3@gmail.com> Message-ID: <526B5664-06C9-40CB-AE99-B10172CB688B@gmail.com> Hi, thanks for the link. We'll try to submit the issues there as soon as we better understand what went wrong. I'm still excited and did not expect a perfect implementation right from the start. best regards Johannes > As Frank says If you join the IE11 Public Feedback Program here: > > https://connect.microsoft.com/directory/accepting-bugs/internet/ > > There is an issue tracker and a set of community forums for it. > > Kind regards > > Ben > > > On 1 August 2013 15:00, Francisco ?vila wrote: > Hi, > > he said that we can report bugs in http://connect.microsoft.com or in his email (bencon at microsoft dot com). > > What kind of limitations? he also mentioned that there is a maximum size for shaders (I guess it was 16K). > > ~Frank > > > On Thu, Aug 1, 2013 at 8:12 AM, Johannes Behr wrote: > > Hi, > > we have some issues while testing X3DOM on IE11. There are some strange limitations in regards to function calls in GLSL. > Is Ben Constable reading this list? Is there a WebGL-related bug-tracker for IE11? > > Best regards > Johannes > > > > > Let's not jump to the conclusion that Microsoft will never fully > > support the WebGL specification. It is clear that the implementation > > in IE 11 is incomplete. The majority of demos I tested with it didn't > > work because of some entry point or another simply being > > unimplemented. Microsoft stated in the WebGL BOF at SIGGRAPH that they > > know their implementation is incomplete, and they're prioritizing what > > missing pieces to fix. > > > > At the same time, yes, the WebGL community should collectively reach > > out to Microsoft to point out use cases that don't work. I suspect > > they will realize that the entry points they've stated they have no > > intent to support (like VertexAttrib[1234]f[v]) are not difficult to > > emulate, and are required for some applications. > > > > Finally, from talking with Ben Constable at SIGGRAPH (Principal > > Engineer on IE and author of its WebGL implementation), Microsoft has > > good ideas about how to specify whether a given shader is going to run > > on a given piece of hardware, and defining performance characteristics > > of the GPU. I am looking forward to collaborating with them to improve > > the WebGL spec. > > > > -Ken > > > > > > > > On Wed, Jul 31, 2013 at 10:36 AM, Brandon Jones wrote: > >> It seems to me like the most effective thing at the moment may be to try and > >> mobilize WebGL developers to contact Microsoft with real-world apps/demos > >> that indicate a need for API "X". I'd imagine that if enough developers > >> wrote in eventually the entire API would worm it's way onto Microsoft's > >> "priority" list. > >> > >> And, if after all that some APIs just don't see much or any demand, it's > >> honestly probably not a crisis is MS excludes them. I'm all for supporting > >> the standard as is, but there is something to be said for not spending > >> resources supporting a function call only 3 developers have ever tried. > >> > >> --Brandon > >> > >> > >> On Wed, Jul 31, 2013 at 10:26 AM, Ben Vanik wrote: > >>> > >>> (opinions are my own, not my employers) > >>> > >>> What IE is shipping should be called 'WebGL Lite', if they are not going > >>> to be implementing the full spec. > >>> > >>> Had they wanted to encourage the removal of these calls from the spec they > >>> should have participated earlier. Developers writing code will now have to > >>> worry about which features IE has arbitrarily chosen not to implement and as > >>> such will learn to avoid using them even though doing so may have been a > >>> perfectly sensible thing to do. It feels like a ham-fisted effort to force > >>> changes to the spec after it's been shipped without the involvement of > >>> Khronos and its members (who spent a great deal of effort making sure the > >>> spec was good) or the community. > >>> > >>> Can anyone help the IE team see reason here? I feel like they are hurting > >>> their image in what could have been their moment of triumph :/ > >>> > >>> > >>> > >>> On Wed, Jul 31, 2013 at 4:50 AM, Daniel Koch wrote: > >>>> > >>>> That seems kind of silly. There already is an existence proof out there > >>>> that all the WebGL features can be mapped to D3D9 and D3D11 fairly > >>>> reasonably? (and it's even open source if they need help figuring it out). > >>>> Ah well, I suppose something is better than nothing? > >>>> > >>>> -Daniel > >>>> > >>>> > >>>> Microsoft's message at the moment is that it's an early developer preview > >>>> and they are actively working on implementing more functionality before > >>>> launch. They have also stated that they do not intend to implement every > >>>> WebGL API (They explicitly called out vertexAttrib[1234]f as an API they are > >>>> planning to ignore as it doesn't map to D3D11 well), and are looking for > >>>> developer feedback on which APIs should receive priority. > >>>> > >>>> --Brandon > >>>> > >>>> > >>>> On Tue, Jul 30, 2013 at 5:19 PM, Mark Callow > >>>> wrote: > >>>>> > >>>>> I tried the IE 11 preview. The simple get.webgl.org cube works as does > >>>>> the slightly more complex one on khronos.org. However the WebGL aquarium > >>>>> does not. I get a cyan background and the menu but nothing else. I do not > >>>>> have time to investigate. > >>>>> > >>>>> Regards > >>>>> > >>>>> -Mark > >>>>> > >>>>> -- > >>>>> ???????????????????????????????????????????????????????????????? > >>>>> ???????????????????????????????????????????????????????????????? ??. > >>>>> > >>>>> NOTE: This electronic mail message may contain confidential and > >>>>> privileged information from HI Corporation. If you are not the intended > >>>>> recipient, any disclosure, photocopying, distribution or use of the contents > >>>>> of the received information is prohibited. If you have received this e-mail > >>>>> in error, please notify the sender immediately and permanently delete this > >>>>> message and all related copies. > >>>> > >>>> > >>> > >> > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From din...@ Fri Aug 2 07:31:21 2013 From: din...@ (Dean Jackson) Date: Sat, 03 Aug 2013 00:31:21 +1000 Subject: [Public WebGL] WebGL spec needs clarification around extensions and context lost / restored events In-Reply-To: References: Message-ID: On 07/06/2013, at 8:09 AM, Kenneth Russell wrote: > I think we should first fix up the context lost language for > extensions I've submitted a pull request for a spec update around extensions and context lost: https://github.com/KhronosGroup/WebGL/issues/334 Dean ----------------------------------------------------------- You are currently 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...@ Fri Aug 2 11:10:19 2013 From: cal...@ (Mark Callow) Date: Fri, 02 Aug 2013 11:10:19 -0700 Subject: [Public WebGL] WebGL spec needs clarification around extensions and context lost / restored events In-Reply-To: References: Message-ID: <51FBF60B.50102@artspark.co.jp> On 13/08/02 7:31, Dean Jackson wrote: > I've submitted a pull request for a spec update around extensions and context lost: > https://github.com/KhronosGroup/WebGL/issues/334 > There is a typo in the revision history of WEBGL_lose_context: "steps outlines in" Seeing all the ancilliary files in the pull request, that result from rebuilding the extension repository, reminds of something I've been meaning to propose. Why don't we limit the Git repo to true source files (i.e. the xml and xsl files and scripts, etc.) and have submissions trigger rebuilding the extension repository. Nothing that results from the build should be versioned in Git. It is unnecessary and tends to complicate gets and merges. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Fri Aug 2 12:14:07 2013 From: din...@ (Dean Jackson) Date: Sat, 03 Aug 2013 05:14:07 +1000 Subject: [Public WebGL] Ancillary files In-Reply-To: <51FBF60B.50102@artspark.co.jp> References: <51FBF60B.50102@artspark.co.jp> Message-ID: <8991E60A-72D7-4701-9121-0616B64B0C13@apple.com> On 03/08/2013, at 4:10 AM, Mark Callow wrote: > Seeing all the ancilliary files in the pull request, that result from rebuilding the extension repository, reminds of something I've been meaning to propose. Why don't we limit the Git repo to true source files (i.e. the xml and xsl files and scripts, etc.) and have submissions trigger rebuilding the extension repository. Nothing that results from the build should be versioned in Git. It is unnecessary and tends to complicate gets and merges. Yeah. That's a good suggestion. I'd like to fix up a few minor spec things similar to that: - There are some spec snapshots of particular revisions. They could probably be added as tags (although I'm not yet sure how much of the SVN history was preserved) - The sections in the specification need named ids. At the moment the ids are generated with a section number, which is fine except makes it more likely an external reference to a particular section will break. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kir...@ Mon Aug 5 02:53:16 2013 From: kir...@ (Kirill Prazdnikov) Date: Mon, 05 Aug 2013 13:53:16 +0400 Subject: [Public WebGL] Texture formats matrix Message-ID: <51FF760C.7090005@jetbrains.com> Hi, Where can I find information about how to query which texture formats are supported on my current platform ? According to glTexImage2D spec it should be { GL_ALPHA, GL_LUMINANCE, GL_LUMINANCE_ALPHA, GL_RGB, GL_RGBA }. Is all of that should be supported on all platforms? Thanks -Kirill ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From wba...@ Mon Aug 5 09:31:41 2013 From: wba...@ (Bill Baxter) Date: Mon, 5 Aug 2013 09:31:41 -0700 Subject: [Public WebGL] Texture formats matrix In-Reply-To: <51FF760C.7090005@jetbrains.com> References: <51FF760C.7090005@jetbrains.com> Message-ID: On Mon, Aug 5, 2013 at 2:53 AM, Kirill Prazdnikov < kirill.prazdnikov...@> wrote: > > Hi, > > Where can I find information about how to query which texture formats are > supported on my current platform ? > > According to glTexImage2D spec it should be { GL_ALPHA, GL_LUMINANCE, > GL_LUMINANCE_ALPHA, GL_RGB, GL_RGBA }. > Is all of that should be supported on all platforms? > > Yes, all those are part of the base spec. Things beyond that, like compressed texture formats, are handled as extensions ( http://www.khronos.org/registry/webgl/extensions/). For how to use compressed texture extensions, see tojicode's article: http://blog.tojicode.com/2011/12/compressed-textures-in-webgl.html The extensions supported by an implementation can be found by calling gl.getSupportedExtensions(). Hope that helps! --bb -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Aug 5 17:57:00 2013 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Aug 2013 17:57:00 -0700 Subject: [Public WebGL] WebGL spec needs clarification around extensions and context lost / restored events In-Reply-To: <51FBF60B.50102@artspark.co.jp> References: <51FBF60B.50102@artspark.co.jp> Message-ID: On Fri, Aug 2, 2013 at 11:10 AM, Mark Callow wrote: > On 13/08/02 7:31, Dean Jackson wrote: > > I've submitted a pull request for a spec update around extensions and > context lost: > https://github.com/KhronosGroup/WebGL/issues/334 > > There is a typo in the revision history of WEBGL_lose_context: "steps > outlines in" Preemptively fixed to save round-trip review time. > Seeing all the ancilliary files in the pull request, that result from > rebuilding the extension repository, reminds of something I've been meaning > to propose. Why don't we limit the Git repo to true source files (i.e. the > xml and xsl files and scripts, etc.) and have submissions trigger rebuilding > the extension repository. Nothing that results from the build should be > versioned in Git. It is unnecessary and tends to complicate gets and merges. Will reply to this on the newly created thread for it. -Ken > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??. > > NOTE: This electronic mail message may contain confidential and privileged > information from HI Corporation. If you are not the intended recipient, any > disclosure, photocopying, distribution or use of the contents of the > received information is prohibited. If you have received this e-mail in > error, please notify the sender immediately and permanently delete this > message and all related copies. ----------------------------------------------------------- You are currently 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 Aug 5 18:04:10 2013 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Aug 2013 18:04:10 -0700 Subject: [Public WebGL] Ancillary files In-Reply-To: <8991E60A-72D7-4701-9121-0616B64B0C13@apple.com> References: <51FBF60B.50102@artspark.co.jp> <8991E60A-72D7-4701-9121-0616B64B0C13@apple.com> Message-ID: On Fri, Aug 2, 2013 at 12:14 PM, Dean Jackson wrote: > > On 03/08/2013, at 4:10 AM, Mark Callow wrote: > > Seeing all the ancilliary files in the pull request, that result from > rebuilding the extension repository, reminds of something I've been meaning > to propose. Why don't we limit the Git repo to true source files (i.e. the > xml and xsl files and scripts, etc.) and have submissions trigger rebuilding > the extension repository. Nothing that results from the build should be > versioned in Git. It is unnecessary and tends to complicate gets and merges. > > > Yeah. That's a good suggestion. This is a good suggestion. The primary concern I have with making this change is that it will make the steps run on Khronos' servers after every git commit more complex. If a change to the repository causes those steps to fail -- or worse, requires them to be updated -- then manual intervention is needed, which is a major pain. It looks like a 'make clean' followed by a 'make' in the extensions directory should be robust, though. I'll ask Khronos' webmaster to add those steps to the update process. At that point it should be possible to delete the generated sources from the git repository. > I'd like to fix up a few minor spec things similar to that: > > - There are some spec snapshots of particular revisions. They could probably > be added as tags (although I'm not yet sure how much of the SVN history was > preserved) It should be safe to delete these snapshots at this point. They've been preserved elsewhere. > - The sections in the specification need named ids. At the moment the ids > are generated with a section number, which is fine except makes it more > likely an external > reference to a particular section will break. Yes. This is a significant problem. Any work in this area would be great. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Aug 5 19:48:44 2013 From: kbr...@ (Kenneth Russell) Date: Mon, 5 Aug 2013 19:48:44 -0700 Subject: [Public WebGL] Community approval for a few draft extensions Message-ID: I would like to propose moving a few draft WebGL extensions to community approved: http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float_linear/ ANGLE_instanced_arrays has been implemented in experimental form in Chrome, and the Maps team at Google has found that it yields a significant reduction in GPU resource consumption. OES_texture_float_linear and half_float_linear have recently been implemented in Chrome, and it's been found that some WebGL content has mistakenly been assuming that linear filtering works for floating-point textures. This mistake should be corrected as soon as possible by enforcing the behavior consistently in WebGL implementations. Are there any objections to moving these to Community Approved status? -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 din...@ Mon Aug 5 19:52:10 2013 From: din...@ (Dean Jackson) Date: Tue, 06 Aug 2013 12:52:10 +1000 Subject: [Public WebGL] Ancillary files In-Reply-To: References: <51FBF60B.50102@artspark.co.jp> <8991E60A-72D7-4701-9121-0616B64B0C13@apple.com> Message-ID: <75BB7DEF-A033-481F-A1CC-5508C06A539D@apple.com> On 06/08/2013, at 11:04 AM, Kenneth Russell wrote: > > On Fri, Aug 2, 2013 at 12:14 PM, Dean Jackson wrote: >> >> On 03/08/2013, at 4:10 AM, Mark Callow wrote: >> >> Seeing all the ancilliary files in the pull request, that result from >> rebuilding the extension repository, reminds of something I've been meaning >> to propose. Why don't we limit the Git repo to true source files (i.e. the >> xml and xsl files and scripts, etc.) and have submissions trigger rebuilding >> the extension repository. Nothing that results from the build should be >> versioned in Git. It is unnecessary and tends to complicate gets and merges. >> >> >> Yeah. That's a good suggestion. > > This is a good suggestion. The primary concern I have with making this > change is that it will make the steps run on Khronos' servers after > every git commit more complex. If a change to the repository causes > those steps to fail -- or worse, requires them to be updated -- then > manual intervention is needed, which is a major pain. > > It looks like a 'make clean' followed by a 'make' in the extensions > directory should be robust, though. I'll ask Khronos' webmaster to add > those steps to the update process. At that point it should be possible > to delete the generated sources from the git repository. Excellent. I'll prepare a branch/pull with these changes. > >> I'd like to fix up a few minor spec things similar to that: >> >> - There are some spec snapshots of particular revisions. They could probably >> be added as tags (although I'm not yet sure how much of the SVN history was >> preserved) > > It should be safe to delete these snapshots at this point. They've > been preserved elsewhere. And another with these. > >> - The sections in the specification need named ids. At the moment the ids >> are generated with a section number, which is fine except makes it more >> likely an external >> reference to a particular section will break. > > Yes. This is a significant problem. Any work in this area would be great. And another, but this one will be my first priority. Dean ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Mon Aug 5 21:21:09 2013 From: jgi...@ (Jeff Gilbert) Date: Mon, 5 Aug 2013 21:21:09 -0700 (PDT) Subject: [Public WebGL] Community approval for a few draft extensions In-Reply-To: References: Message-ID: <417330733.537295.1375762869710.JavaMail.zimbra@mozilla.com> None here. -Jeff ----- Original Message ----- From: "Kenneth Russell" To: "public webgl" Sent: Monday, August 5, 2013 7:48:44 PM Subject: [Public WebGL] Community approval for a few draft extensions I would like to propose moving a few draft WebGL extensions to community approved: http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float_linear/ ANGLE_instanced_arrays has been implemented in experimental form in Chrome, and the Maps team at Google has found that it yields a significant reduction in GPU resource consumption. OES_texture_float_linear and half_float_linear have recently been implemented in Chrome, and it's been found that some WebGL content has mistakenly been assuming that linear filtering works for floating-point textures. This mistake should be corrected as soon as possible by enforcing the behavior consistently in WebGL implementations. Are there any objections to moving these to Community Approved status? -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Mon Aug 5 21:46:09 2013 From: baj...@ (Brandon Jones) Date: Mon, 5 Aug 2013 21:46:09 -0700 Subject: [Public WebGL] Community approval for a few draft extensions In-Reply-To: <417330733.537295.1375762869710.JavaMail.zimbra@mozilla.com> References: <417330733.537295.1375762869710.JavaMail.zimbra@mozilla.com> Message-ID: +1, these would all be great extensions to make more widely available. On Mon, Aug 5, 2013 at 9:21 PM, Jeff Gilbert wrote: > > None here. > > -Jeff > > ----- Original Message ----- > From: "Kenneth Russell" > To: "public webgl" > Sent: Monday, August 5, 2013 7:48:44 PM > Subject: [Public WebGL] Community approval for a few draft extensions > > > I would like to propose moving a few draft WebGL extensions to > community approved: > > http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ > > http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ > > http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float_linear/ > > ANGLE_instanced_arrays has been implemented in experimental form in > Chrome, and the Maps team at Google has found that it yields a > significant reduction in GPU resource consumption. > > OES_texture_float_linear and half_float_linear have recently been > implemented in Chrome, and it's been found that some WebGL content has > mistakenly been assuming that linear filtering works for > floating-point textures. This mistake should be corrected as soon as > possible by enforcing the behavior consistently in WebGL > implementations. > > Are there any objections to moving these to Community Approved status? > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Mon Aug 5 22:39:25 2013 From: din...@ (Dean Jackson) Date: Tue, 06 Aug 2013 15:39:25 +1000 Subject: [Public WebGL] Community approval for a few draft extensions In-Reply-To: References: Message-ID: +1 to Community Approved. Dean On 06/08/2013, at 12:48 PM, Kenneth Russell wrote: > > I would like to propose moving a few draft WebGL extensions to > community approved: > > http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ > http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ > http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float_linear/ > > ANGLE_instanced_arrays has been implemented in experimental form in > Chrome, and the Maps team at Google has found that it yields a > significant reduction in GPU resource consumption. > > OES_texture_float_linear and half_float_linear have recently been > implemented in Chrome, and it's been found that some WebGL content has > mistakenly been assuming that linear filtering works for > floating-point textures. This mistake should be corrected as soon as > possible by enforcing the behavior consistently in WebGL > implementations. > > Are there any objections to moving these to Community Approved status? > > -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...@ Tue Aug 6 14:30:58 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 6 Aug 2013 14:30:58 -0700 Subject: [Public WebGL] Ancillary files In-Reply-To: <75BB7DEF-A033-481F-A1CC-5508C06A539D@apple.com> References: <51FBF60B.50102@artspark.co.jp> <8991E60A-72D7-4701-9121-0616B64B0C13@apple.com> <75BB7DEF-A033-481F-A1CC-5508C06A539D@apple.com> Message-ID: On Mon, Aug 5, 2013 at 7:52 PM, Dean Jackson wrote: > > On 06/08/2013, at 11:04 AM, Kenneth Russell wrote: > >> It looks like a 'make clean' followed by a 'make' in the extensions >> directory should be robust, though. I'll ask Khronos' webmaster to add >> those steps to the update process. At that point it should be possible >> to delete the generated sources from the git repository. > > Excellent. I'll prepare a branch/pull with these changes. Thanks to Khronos webmaster James Riordon and Dean, these changes have landed, significantly simplifying the WebGL repo. It's still possible to test changes to the extension registry locally by running "make" in the extensions/ directory. The generated sources will be ignored by git. -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 din...@ Tue Aug 6 14:49:56 2013 From: din...@ (Dean Jackson) Date: Wed, 07 Aug 2013 07:49:56 +1000 Subject: [Public WebGL] Community approval for a few draft extensions In-Reply-To: References: Message-ID: These have now been marked as community approved. Dean On 06/08/2013, at 12:48 PM, Kenneth Russell wrote: > > I would like to propose moving a few draft WebGL extensions to > community approved: > > http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ > http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ > http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float_linear/ > > ANGLE_instanced_arrays has been implemented in experimental form in > Chrome, and the Maps team at Google has found that it yields a > significant reduction in GPU resource consumption. > > OES_texture_float_linear and half_float_linear have recently been > implemented in Chrome, and it's been found that some WebGL content has > mistakenly been assuming that linear filtering works for > floating-point textures. This mistake should be corrected as soon as > possible by enforcing the behavior consistently in WebGL > implementations. > > Are there any objections to moving these to Community Approved status? > > -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...@ Tue Aug 6 15:14:04 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 6 Aug 2013 15:14:04 -0700 Subject: [Public WebGL] Community approval for a few draft extensions In-Reply-To: References: Message-ID: Excellent. On Tue, Aug 6, 2013 at 2:49 PM, Dean Jackson wrote: > > These have now been marked as community approved. > > Dean > > On 06/08/2013, at 12:48 PM, Kenneth Russell wrote: > >> >> I would like to propose moving a few draft WebGL extensions to >> community approved: >> >> http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ >> http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ >> http://www.khronos.org/registry/webgl/extensions/OES_texture_half_float_linear/ >> >> ANGLE_instanced_arrays has been implemented in experimental form in >> Chrome, and the Maps team at Google has found that it yields a >> significant reduction in GPU resource consumption. >> >> OES_texture_float_linear and half_float_linear have recently been >> implemented in Chrome, and it's been found that some WebGL content has >> mistakenly been assuming that linear filtering works for >> floating-point textures. This mistake should be corrected as soon as >> possible by enforcing the behavior consistently in WebGL >> implementations. >> >> Are there any objections to moving these to Community Approved status? >> >> -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 > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently 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 oet...@ Wed Aug 14 11:33:55 2013 From: oet...@ (Olli Etuaho) Date: Wed, 14 Aug 2013 20:33:55 +0200 Subject: [Public WebGL] Required fragment shader uniforms in conformance tests Message-ID: Hi all, I was fixing some issues in glsl/misc/shader-uniform-packing-restrictions.html WebGL 1.0.2 conformance test, and I noticed that the minimum amount of required rows for fragment shader uniforms is peculiarly low, only 16. GLSL spec makes no distinction between fragment shaders and vertex shaders in this respect, so it is odd that 128 rows are required from vertex shaders but not from pixel shaders. Is this just an accidental oversight in the patch "Update shader uniform packing test to check vertex shaders.", where this originates, or is there some specific reason why the minimum amount was lowered so much? And should we raise the amount back up in 1.0.2 if it was changed accidentally, even though it makes the test more strict? - Regards, Olli Etuaho ----------------------------------------------------------- You are currently 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 Aug 14 19:09:22 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 14 Aug 2013 19:09:22 -0700 Subject: [Public WebGL] Required fragment shader uniforms in conformance tests In-Reply-To: References: Message-ID: Per the comment on that line, the limitation comes from the minimums defined in GLSL ES 1.0.17 Appendix A. It looks like the comment is a little off, but these are the minimum values defined in A.8 for gl_MaxVertexUniformVectors and gl_MaxFragmentUniformVectors. -Ken On Wed, Aug 14, 2013 at 11:33 AM, Olli Etuaho wrote: > > Hi all, > > I was fixing some issues in glsl/misc/shader-uniform-packing-restrictions.html WebGL 1.0.2 conformance test, and I noticed that the minimum amount of required rows for fragment shader uniforms is peculiarly low, only 16. GLSL spec makes no distinction between fragment shaders and vertex shaders in this respect, so it is odd that 128 rows are required from vertex shaders but not from pixel shaders. Is this just an accidental oversight in the patch "Update shader uniform packing test to check vertex shaders.", where this originates, or is there some specific reason why the minimum amount was lowered so much? And should we raise the amount back up in 1.0.2 if it was changed accidentally, even though it makes the test more strict? > - > Regards, Olli Etuaho > ----------------------------------------------------------- > You are currently 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 oet...@ Thu Aug 15 04:40:16 2013 From: oet...@ (Olli Etuaho) Date: Thu, 15 Aug 2013 13:40:16 +0200 Subject: [Public WebGL] Required fragment shader uniforms in conformance tests In-Reply-To: References: , Message-ID: Oh, of course, I was just confused by the comment pointing to the wrong part of the spec. I updated the pull request so that it now refers to the correct part of the spec: https://github.com/KhronosGroup/WebGL/pull/346 -Olli ________________________________________ From: Kenneth Russell [kbr...@] Sent: Thursday, August 15, 2013 5:09 AM To: Olli Etuaho Cc: public_webgl...@ Subject: Re: [Public WebGL] Required fragment shader uniforms in conformance tests Per the comment on that line, the limitation comes from the minimums defined in GLSL ES 1.0.17 Appendix A. It looks like the comment is a little off, but these are the minimum values defined in A.8 for gl_MaxVertexUniformVectors and gl_MaxFragmentUniformVectors. -Ken On Wed, Aug 14, 2013 at 11:33 AM, Olli Etuaho wrote: > > Hi all, > > I was fixing some issues in glsl/misc/shader-uniform-packing-restrictions.html WebGL 1.0.2 conformance test, and I noticed that the minimum amount of required rows for fragment shader uniforms is peculiarly low, only 16. GLSL spec makes no distinction between fragment shaders and vertex shaders in this respect, so it is odd that 128 rows are required from vertex shaders but not from pixel shaders. Is this just an accidental oversight in the patch "Update shader uniform packing test to check vertex shaders.", where this originates, or is there some specific reason why the minimum amount was lowered so much? And should we raise the amount back up in 1.0.2 if it was changed accidentally, even though it makes the test more strict? > - > Regards, Olli Etuaho > ----------------------------------------------------------- > You are currently 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 wai...@ Fri Aug 16 12:55:33 2013 From: wai...@ (Wong, Alex) Date: Fri, 16 Aug 2013 19:55:33 +0000 Subject: [Public WebGL] Problems with textures/texture-size-limit.html Message-ID: <765398B7AA33EC4CB8164545DACDDB802B21467B@NASANEXD01E.na.qualcomm.com> Hi all, Two problems with https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.2/conformance/textures/texture-size-limit.html 1) Incorrect Mipmap Level in Inner Test Loop The first problem I discovered was an incorrect calculation of the intended mipmap level in the innermost test loop. On line 138 of the test, the original reads: var level = numLevels - l - 1; However, we see that earlier, on lines 133-134, that there is another value calculated, numTestLevels, that derives from the lesser of the calculated maximum possible mipmap level and the limit that's set for this particular test: var numLevels = numLevelsFromSize(t.maxSize); var numTestLevels = Math.min(numLevels, t.maxLevel); The t.maxLevel value comes from lines 71-91 of the tests, where specifics about each test case are defined. In the particular case of cubemap texture, the maximum mipmap level is meant to be limited to 5, not to the calculated maximum of 12. (The calculated maximum value is derived from the gl.MAX_CUBE_MAP_TEXTURE_SIZE using the numLevelsFromSize() function on line 47. Since our maximum cubemap texture size is 4096, the maximum mipmap level is 12.) Changing numLevels to numTestLevels on line 138 causes all the success cases to pass, and I believe is the intended test behavior. 2) Incorrect Calculation for Invalid Texture Size Making the first modification caused the cubemap success cases to pass, but also caused the cubemap failure cases to fail, when they had previously been passing. I tracked this down to an incorrect calculation of the texture size required to cause gl.texImage2D() to fail at a given mipmap level. The test assumes that doubling the size of the texture will cause the allocation to fail, as shown on line 140: var badSize = size * 2; This assumption is valid if we always start our testing with the maximum possible mipmap level (12 in our case). But since the test is changed to respect the maximum mipmap level specified in the test configuration (5 for cubemap textures), doubling the size at the given mipmap level no longer results in an invalid texture, since it would not necessarily expand level 0 beyond the texture size limit. The proper calculation to force level 0 to exceed the texture size limit is: var badSize = 1 << (numLevels - level); This ensures that the gl.texImage2D() calls that are meant to fail do, and I believe correctly expresses the intent of the test. Thanks Alex ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Sat Aug 24 00:59:47 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 24 Aug 2013 09:59:47 +0200 Subject: [Public WebGL] ArrayBufferView -> ArrayBuffer.isView In-Reply-To: References: Message-ID: FYI Chrome Android Beta disabled ArrayBufferView on the last update yesterday. I got a frantic call from a client that nothing works anymore a couple hours before a demo in front of an investor. It turns out that isView is not yet implemented even though the ArrayBufferView has been retired. Which led to code like this: isView = function(obj){ if(obj === undefined || obj === null){ return false; } else{ if(obj.buffer instanceof ArrayBuffer){ return true; } else{ return false; } } } On Fri, Jun 7, 2013 at 3:33 AM, Kenneth Russell wrote: > > A couple of months ago Mozilla and the ECMAScript committee expressed > concern with the typed array tests in the WebGL 1.0.2 conformance > suite. The specific concern was the exposure of the ArrayBufferView > interface in the IDL. The intent was to use this for type testing > (e.g., "val instanceof ArrayBufferView"), but it seems that the > preferred style in ECMAScript is to provide methods for these type > tests; for example, Array.isArray. > > There was agreement to expose a static method ArrayBuffer.isView for > these type tests instead, and add the NoInterfaceObject extended > attribute to ArrayBufferView again. The current ECMAScript 6 draft, > which incorporates typed arrays into the language, contains this > change. > > Note that while Safari and Chrome have exposed ArrayBufferView for a > while, Firefox never did, so we don't believe any apps will break with > this change since it has never been possible to assume the presence of > ArrayBufferView. > > The typed array editor's draft spec at > https://www.khronos.org/registry/typedarray/specs/latest/ has been > updated with these changes, and the 1.0.2 and top of tree WebGL > conformance tests have been updated as well to test > ArrayBuffer.isView. > > Please send any comments on this change 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 kbr...@ Sun Aug 25 16:11:22 2013 From: kbr...@ (Kenneth Russell) Date: Sun, 25 Aug 2013 16:11:22 -0700 Subject: [Public WebGL] ArrayBufferView -> ArrayBuffer.isView In-Reply-To: References: Message-ID: Sorry about the difficulty. The change in this area was made somewhat quickly in response to the ECMAScript committee, and yes, ArrayBuffer.isView isn't present in Chrome yet. ( https://code.google.com/p/v8/issues/detail?id=2747 tracks its implementation.) Firefox never exposed the ArrayBufferView interface, so it was assumed that nobody was relying on it. (How did your code work on Firefox?) -Ken On Sat, Aug 24, 2013 at 12:59 AM, Florian B?sch wrote: > FYI Chrome Android Beta disabled ArrayBufferView on the last update > yesterday. I got a frantic call from a client that nothing works anymore a > couple hours before a demo in front of an investor. > > It turns out that isView is not yet implemented even though the > ArrayBufferView has been retired. Which led to code like this: > > isView = function(obj){ > if(obj === undefined || obj === null){ > return false; > } > else{ > if(obj.buffer instanceof ArrayBuffer){ > return true; > } > else{ > return false; > } > } > } > > > On Fri, Jun 7, 2013 at 3:33 AM, Kenneth Russell wrote: >> >> >> A couple of months ago Mozilla and the ECMAScript committee expressed >> concern with the typed array tests in the WebGL 1.0.2 conformance >> suite. The specific concern was the exposure of the ArrayBufferView >> interface in the IDL. The intent was to use this for type testing >> (e.g., "val instanceof ArrayBufferView"), but it seems that the >> preferred style in ECMAScript is to provide methods for these type >> tests; for example, Array.isArray. >> >> There was agreement to expose a static method ArrayBuffer.isView for >> these type tests instead, and add the NoInterfaceObject extended >> attribute to ArrayBufferView again. The current ECMAScript 6 draft, >> which incorporates typed arrays into the language, contains this >> change. >> >> Note that while Safari and Chrome have exposed ArrayBufferView for a >> while, Firefox never did, so we don't believe any apps will break with >> this change since it has never been possible to assume the presence of >> ArrayBufferView. >> >> The typed array editor's draft spec at >> https://www.khronos.org/registry/typedarray/specs/latest/ has been >> updated with these changes, and the 1.0.2 and top of tree WebGL >> conformance tests have been updated as well to test >> ArrayBuffer.isView. >> >> Please send any comments on this change 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 pya...@ Sun Aug 25 23:16:44 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 26 Aug 2013 08:16:44 +0200 Subject: [Public WebGL] ArrayBufferView -> ArrayBuffer.isView In-Reply-To: References: Message-ID: On Mon, Aug 26, 2013 at 1:11 AM, Kenneth Russell wrote: > (How did your code work on Firefox?) > Chrome only target for reasons I can't divulge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Aug 27 15:57:20 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 27 Aug 2013 15:57:20 -0700 Subject: [Public WebGL] Problems with textures/texture-size-limit.html In-Reply-To: <765398B7AA33EC4CB8164545DACDDB802B21467B@NASANEXD01E.na.qualcomm.com> References: <765398B7AA33EC4CB8164545DACDDB802B21467B@NASANEXD01E.na.qualcomm.com> Message-ID: On Fri, Aug 16, 2013 at 12:55 PM, Wong, Alex wrote: > > Hi all, > > Two problems with https://github.com/KhronosGroup/WebGL/blob/master/conformance-suites/1.0.2/conformance/textures/texture-size-limit.html > > 1) Incorrect Mipmap Level in Inner Test Loop > > The first problem I discovered was an incorrect calculation of the intended mipmap level in the innermost test loop. On line 138 of the test, the original reads: > > var level = numLevels - l - 1; > > However, we see that earlier, on lines 133-134, that there is another value calculated, numTestLevels, that derives from the lesser of the calculated maximum possible mipmap level and the limit that's set for this particular test: > > var numLevels = numLevelsFromSize(t.maxSize); > var numTestLevels = Math.min(numLevels, t.maxLevel); > > The t.maxLevel value comes from lines 71-91 of the tests, where specifics about each test case are defined. In the particular case of cubemap texture, the maximum mipmap level is meant to be limited to 5, not to the calculated maximum of 12. (The calculated maximum value is derived from the gl.MAX_CUBE_MAP_TEXTURE_SIZE using the numLevelsFromSize() function on line 47. Since our maximum cubemap texture size is 4096, the maximum mipmap level is 12.) > > Changing numLevels to numTestLevels on line 138 causes all the success cases to pass, and I believe is the intended test behavior. After reading the test I'm afraid I don't agree. The comment at the top of the loop on line 136 says "Do bottom levels first", so it seems to me that the test was intended to allocate the bottom 5 mipmaps per cube map face. The test passes on Mac OS and Windows machines I've tested on. It also passes on a Nexus 4 running Chrome 29.0.1547.59, and this device uses a Qualcomm Adreno 320. What is the failure mode you are seeing? It sounds to me like there is a bug in the driver. > 2) Incorrect Calculation for Invalid Texture Size > > Making the first modification caused the cubemap success cases to pass, but also caused the cubemap failure cases to fail, when they had previously been passing. I tracked this down to an incorrect calculation of the texture size required to cause gl.texImage2D() to fail at a given mipmap level. > > The test assumes that doubling the size of the texture will cause the allocation to fail, as shown on line 140: > > var badSize = size * 2; > > This assumption is valid if we always start our testing with the maximum possible mipmap level (12 in our case). But since the test is changed to respect the maximum mipmap level specified in the test configuration (5 for cubemap textures), doubling the size at the given mipmap level no longer results in an invalid texture, since it would not necessarily expand level 0 beyond the texture size limit. The proper calculation to force level 0 to exceed the texture size limit is: > > var badSize = 1 << (numLevels - level); > > This ensures that the gl.texImage2D() calls that are meant to fail do, and I believe correctly expresses the intent of the test. Given the analysis in (1), this change doesn't apply. -Ken > Thanks > Alex > > ----------------------------------------------------------- > You are currently 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 yvo...@ Wed Aug 28 05:24:46 2013 From: yvo...@ (Jung, Yvonne) Date: Wed, 28 Aug 2013 12:24:46 +0000 Subject: [Public WebGL] Chrome problems with FBO and fp-textures Message-ID: Dear all, since today, Chrome has problems with rendering into an FBO when a texture with type gl.FLOAT is bound (though OES_texture_float is available)? The other browsers still work well. Has there been an interface change, and if so, what is the recommended correct way to do it now for Chrome (besides using UNSIGNED_BYTE instead)? Best regards Yvonne ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Aug 28 05:36:22 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 28 Aug 2013 14:36:22 +0200 Subject: [Public WebGL] Chrome problems with FBO and fp-textures In-Reply-To: References: Message-ID: https://github.com/pyalot/webgl-texture-float-extension-shims On Wed, Aug 28, 2013 at 2:24 PM, Jung, Yvonne wrote: > > Dear all, > > since today, Chrome has problems with rendering into an FBO when a texture > with type gl.FLOAT is bound (though OES_texture_float is available)? The > other browsers still work well. > Has there been an interface change, and if so, what is the recommended > correct way to do it now for Chrome (besides using UNSIGNED_BYTE instead)? > > Best regards > Yvonne > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Aug 28 16:33:14 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 28 Aug 2013 16:33:14 -0700 Subject: [Public WebGL] Chrome problems with FBO and fp-textures In-Reply-To: References: Message-ID: Please see https://www.khronos.org/webgl/public-mailing-list/archives/1305/msg00022.html and the follow-up emails in the archives. I'm quite sure the problem is incorrect assumptions about linear filtering being available. -Ken On Wed, Aug 28, 2013 at 5:24 AM, Jung, Yvonne wrote: > > Dear all, > > since today, Chrome has problems with rendering into an FBO when a texture with type gl.FLOAT is bound (though OES_texture_float is available)? The other browsers still work well. > Has there been an interface change, and if so, what is the recommended correct way to do it now for Chrome (besides using UNSIGNED_BYTE instead)? > > Best regards > Yvonne > > > ----------------------------------------------------------- > You are currently 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 -----------------------------------------------------------