From oet...@ Tue Apr 1 10:53:40 2014 From: oet...@ (Olli Etuaho) Date: Tue, 1 Apr 2014 19:53:40 +0200 Subject: [Public WebGL] Specifying width and height when calling texImage2D and texSubImage2D with an HTML element In-Reply-To: References: Message-ID: Hi all, I'd like to clarify the WebGL spec a bit as it comes to texImage2D and texSubImage2D variants which upload texture data from an HTML element: https://github.com/KhronosGroup/WebGL/pull/512 The current behavior is implicitly clear for a lot of the cases, but I feel that the current spec leaves too much up for interpretation especially in the case of SVG images and to some extent anamorphic video. If you have different ideas about how to address this, please weigh in! Regards, Olli ----------------------------------------------------------- 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...@ Tue Apr 8 20:43:39 2014 From: cal...@ (Mark Callow) Date: Wed, 09 Apr 2014 12:43:39 +0900 Subject: [Public WebGL] color_buffer_float In-Reply-To: References: <533D3A99.8030603@artspark.co.jp> <53435E2D.1060807@artspark.co.jp> Message-ID: <5344C1EB.80407@artspark.co.jp> On 2014/04/08 17:37, Florian B?sch wrote: > On Tue, Apr 8, 2014 at 4:25 AM, Mark Callow > > wrote: > > What is wrong is that WebGL2 implementations should not be > exposing WebGL_color_buffer_float as that is for OpenGL ES 2 and > leaves a lot of OES 3 and desktop features on the table and leaves > open the question of exactly what is the format of "FLOAT". > > > So the 6 extensions that cover floats (half/single | color buffer | > linear) are now obsolete? Yes. > > I see one problem with disabling these 6 extensions (or any of them). > If somebody does a canvas.getContext('webgl') and they get a WebGL 2.0 > context, and they used any of the extensions (properly) they will now > indicate that this WebGL implementation can't run the code because of > no float support whatsoever. I think we already decided that applications will have to explicitly request a WebGL 2 context by using a different context name. > > I can't currently consult the extension specification for > EXT_color_buffer_float because khronos website is down. Does > EXT_color_buffer_float cover texturing support, linear filtering > support, renderability in a framebuffer support for both 16-bit and > 32-bit? It covers all of those except texturing which is standard in OpenGL ES 3.0 so is in the core specification. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Apr 8 22:53:21 2014 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 9 Apr 2014 07:53:21 +0200 Subject: [Public WebGL] color_buffer_float In-Reply-To: <5344C1EB.80407@artspark.co.jp> References: <533D3A99.8030603@artspark.co.jp> <53435E2D.1060807@artspark.co.jp> <5344C1EB.80407@artspark.co.jp> Message-ID: On Wed, Apr 9, 2014 at 5:43 AM, Mark Callow wrote: > > I think we already decided that applications will have to explicitly > request a WebGL 2 context by using a different context name. > That's fine then. > It covers all of those except texturing which is standard in OpenGL ES 3.0 > so is in the core specification. > Excelent. One related task would be to split the extension registry such that people can browse which extensions are available for which WebGL version. Any ideas on how to represent that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Apr 15 16:49:51 2014 From: kbr...@ (Kenneth Russell) Date: Tue, 15 Apr 2014 16:49:51 -0700 Subject: [Public WebGL] IMPLEMENTATION_COLOR_READ_FORMAT/TYPE Message-ID: WebGL community: During development of the WebGL specification, the constants IMPLEMENTATION_COLOR_READ_FORMAT and _TYPE were removed because of a misunderstanding (principally on my part) on how they behaved. After discussion in the WebGL working group, they've been added back in and the conformance tests have been updated. More tests will follow once they've been added to implementations. (The 1.0.1 and 1.0.2 snapshots were updated to allow these constants to be present; the 1.0.3 beta conformance tests now require their presence.) crbug.com/363842 tracks their addition to Chrome. Sorry for the oversight. -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 khr...@ Fri Apr 25 23:40:46 2014 From: khr...@ (Gregg Tavares) Date: Sat, 26 Apr 2014 15:40:46 +0900 Subject: [Public WebGL] 8-bit (indexed) PNG files Message-ID: I noticed an issue with indexed PNG files. Both Chrome and Firefox don't seem to handle transparency for indexed PNG files in WebGL whereas they do handle it for Canvas It this a bug? Should I add a test? http://jsfiddle.net/greggman/nhxRa/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Sat Apr 26 10:26:27 2014 From: baj...@ (Brandon Jones) Date: Sat, 26 Apr 2014 17:26:27 +0000 Subject: [Public WebGL] 8-bit (indexed) PNG files References: Message-ID: I don't see anything about 8-bit images in the spec, so I would assume that it's either a bug or a spec clarification that needs to be made. On Fri, Apr 25, 2014 at 11:41 PM, Gregg Tavares wrote: > I noticed an issue with indexed PNG files. Both Chrome and Firefox don't > seem to handle transparency for indexed PNG files in WebGL whereas they do > handle it for Canvas > > It this a bug? Should I add a test? > > http://jsfiddle.net/greggman/nhxRa/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat Apr 26 10:56:26 2014 From: kbr...@ (Kenneth Russell) Date: Sat, 26 Apr 2014 10:56:26 -0700 Subject: [Public WebGL] 8-bit (indexed) PNG files In-Reply-To: References: Message-ID: Gregg, if it works in 2D canvas then yes, it's a bug in WebGL's image-to-texture upload path. Not sure the spec needs to be modified since it doesn't enumerate the browser's supported image formats. Could you please file a bug? Also, would it be possible for you to send a pull request for a WebGL conformance test? Thanks, -Ken On Sat, Apr 26, 2014 at 10:26 AM, Brandon Jones wrote: > I don't see anything about 8-bit images in the spec, so I would assume > that it's either a bug or a spec clarification that needs to be made. > > On Fri, Apr 25, 2014 at 11:41 PM, Gregg Tavares > wrote: > >> I noticed an issue with indexed PNG files. Both Chrome and Firefox don't >> seem to handle transparency for indexed PNG files in WebGL whereas they do >> handle it for Canvas >> >> It this a bug? Should I add a test? >> >> http://jsfiddle.net/greggman/nhxRa/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: