From pya...@ Sat Dec 1 02:48:26 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 1 Dec 2012 11:48:26 +0100 Subject: [Public WebGL] Antialiasing being disabled on some Mac OS hardware In-Reply-To: References: <15CFF10C-1677-430B-89E3-0767F6CA1D1D@apple.com> Message-ID: I don't think you can shim AA from JS-userland for a couple of reasons 1) It would be contingent to know when a user has finished drawing, which we don't. 2) It would imply substituting the actual front buffer with an FBO (perhaps we can monkey patch gl.bindFramebuffer and ask for null or something) 3) Some anti-aliasing techniques (like SSAA and geometric aa) can only be done in userland if the whole scene is drawn multiple times (with offsets) which requires deep changes in a users shaders and renderloop. 4) Other anti-aliasing techniques rely on the presence of depth, normal and color. The depth could be obtained by faking the front buffer and attaching a depth texture, the normal however would again require deep changes in a users code. That leaves at least some techniques (FXAA for instance) if you can solve #1 which afaik we cannot. On Sat, Dec 1, 2012 at 4:29 AM, Gregg Tavares (??) wrote: > Just an idea, but someone could write a stub js library. > AlwaysGiveMeAntiAliasing.js > > That would check if the driver gave an anti-aliased backbuffer and if not > magically faked it with one of the mentioned workarounds. > > Fun weekend project? > > Even if the bugs get fixed there are reasons you might want to use the > other techniques > > http://www.iryoku.com/smaa/ > :-) > > > On Sat, Dec 1, 2012 at 5:31 AM, Tony Parisi wrote: > >> Hi all >> >> Thanks for the extra color on this (very important) topic >> >> >> On Fri, Nov 30, 2012 at 10:08 AM, Dean Jackson wrote: >> >>> >>> On 01/12/2012, at 5:00 AM, Dean Jackson wrote: >>> >>> If you are passionate about getting this fixed you need to make noise >>> where Apple can hear you. >>> >>> >>> .... and that place is >>> >>> http://bugreporter.apple.com/ >>> >>> If antialiasing is important to you please file a report there. Maybe >>> Ken could share the bug ids that he filed on this? That way any new bugs >>> could reference them which helps them get screened faster. >>> >>> Don't worry about filing duplicates. Consider that a vote for the >>> importance. Also, don't be put off by the fact you'll likely get told it is >>> a duplicate and then not see any updates. That's an unfortunate part of our >>> external bug system. Be assured that Apple really does notice and track >>> everything filed on that site. >>> >>> This goes for all Apple OpenGL and WebGL bugs (including "Please support >>> WebGL"). >>> >>> >>> Sorry for the email flood but there is one last thing. If you do file a >>> bug on WebGL, please note the bug id and email it to me (off-list). The >>> people who screen our bugs are not necessarily experts in whatever the >>> topic is, so I can maybe help it get processed faster. Also, I want to know >>> about any problems with WebGL :) >>> >>> Dean >>> >>> >>> Oh, and please attach a complete system profile. It's essential that we >>> know your hardware and OS configuration. >>> >>> >>> >> >> >> -- >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> >> Read my book! *WebGL, Up and Running* >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Dec 1 10:58:15 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 1 Dec 2012 19:58:15 +0100 Subject: [Public WebGL] Antialiasing being disabled on some Mac OS hardware In-Reply-To: References: <15CFF10C-1677-430B-89E3-0767F6CA1D1D@apple.com> Message-ID: Btw. this is what a gl.swap() or similar (blit, flip, what have you) would come in handy. We could monkey patch that and add after rendering effects. On Sat, Dec 1, 2012 at 11:48 AM, Florian B?sch wrote: > I don't think you can shim AA from JS-userland for a couple of reasons > > 1) It would be contingent to know when a user has finished drawing, which > we don't. > 2) It would imply substituting the actual front buffer with an FBO > (perhaps we can monkey patch gl.bindFramebuffer and ask for null or > something) > 3) Some anti-aliasing techniques (like SSAA and geometric aa) can only be > done in userland if the whole scene is drawn multiple times (with offsets) > which requires deep changes in a users shaders and renderloop. > 4) Other anti-aliasing techniques rely on the presence of depth, normal > and color. The depth could be obtained by faking the front buffer and > attaching a depth texture, the normal however would again require deep > changes in a users code. > > That leaves at least some techniques (FXAA for instance) if you can solve > #1 which afaik we cannot. > > > On Sat, Dec 1, 2012 at 4:29 AM, Gregg Tavares (??) wrote: > >> Just an idea, but someone could write a stub js library. >> AlwaysGiveMeAntiAliasing.js >> >> That would check if the driver gave an anti-aliased backbuffer and if not >> magically faked it with one of the mentioned workarounds. >> >> Fun weekend project? >> >> Even if the bugs get fixed there are reasons you might want to use the >> other techniques >> >> http://www.iryoku.com/smaa/ >> :-) >> >> >> On Sat, Dec 1, 2012 at 5:31 AM, Tony Parisi wrote: >> >>> Hi all >>> >>> Thanks for the extra color on this (very important) topic >>> >>> >>> On Fri, Nov 30, 2012 at 10:08 AM, Dean Jackson wrote: >>> >>>> >>>> On 01/12/2012, at 5:00 AM, Dean Jackson wrote: >>>> >>>> If you are passionate about getting this fixed you need to make noise >>>> where Apple can hear you. >>>> >>>> >>>> .... and that place is >>>> >>>> http://bugreporter.apple.com/ >>>> >>>> If antialiasing is important to you please file a report there. Maybe >>>> Ken could share the bug ids that he filed on this? That way any new bugs >>>> could reference them which helps them get screened faster. >>>> >>>> Don't worry about filing duplicates. Consider that a vote for the >>>> importance. Also, don't be put off by the fact you'll likely get told it is >>>> a duplicate and then not see any updates. That's an unfortunate part of our >>>> external bug system. Be assured that Apple really does notice and track >>>> everything filed on that site. >>>> >>>> This goes for all Apple OpenGL and WebGL bugs (including "Please >>>> support WebGL"). >>>> >>>> >>>> Sorry for the email flood but there is one last thing. If you do file a >>>> bug on WebGL, please note the bug id and email it to me (off-list). The >>>> people who screen our bugs are not necessarily experts in whatever the >>>> topic is, so I can maybe help it get processed faster. Also, I want to know >>>> about any problems with WebGL :) >>>> >>>> Dean >>>> >>>> >>>> Oh, and please attach a complete system profile. It's essential that we >>>> know your hardware and OS configuration. >>>> >>>> >>>> >>> >>> >>> -- >>> Tony Parisi tparisi...@ >>> CTO at Large 415.902.8002 >>> Skype auradeluxe >>> Follow me on Twitter! http://twitter.com/auradeluxe >>> Read my blog at http://www.tonyparisi.com/ >>> >>> Read my book! *WebGL, Up and Running* >>> http://shop.oreilly.com/product/0636920024729.do >>> http://www.amazon.com/dp/144932357X >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Dec 3 05:26:21 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 3 Dec 2012 14:26:21 +0100 Subject: [Public WebGL] Implement extension EXT_frag_depth in WebGL In-Reply-To: References: Message-ID: Any objections of moving this extension to draft status? On Wed, Nov 28, 2012 at 8:13 PM, Florian B?sch wrote: > The proposed extension as been merged into the khronos repository (thanks > Kenneth). > > Please review the extension proposal: > http://www.khronos.org/registry/webgl/extensions/proposals/EXT_frag_depth/ > > Thanks > > > On Thu, Nov 22, 2012 at 11:07 AM, Florian B?sch wrote: > >> Specified in: >> >> - OpenGL: Available in the core specification to OpenGL 2.0, released >> 2004 >> - OpenGL ES: >> - Available as extension ES: EXT_frag_depth, released 2010 >> - Available in the core specification to OpenGL ES 3.0, released >> 2012 >> - Direct3D: Available since Shader Model 2.0, Released with Direct3D >> 9.0 in 2002 >> >> Hardware availability >> >> - Desktops: 99.45% (not being DX8 GPUs or below), source: >> http://store.steampowered.com/hwsurvey >> - Mobiles: As of November 2012, 7 devices out of 783, source: >> http://www.glbenchmark.com/result.jsp >> - Freescale SABRESD-MX6DQ >> - Huawei MediaPad 10 FHD >> - Huawei U9508 >> - Huawei U9510 >> - Huawei U9510E >> - Marvell PXA988 >> - Panasonic Toughpad FZ-A1B >> >> >> Proposed Extension: https://github.com/KhronosGroup/WebGL/pull/84 >> >> >> On Thu, Nov 22, 2012 at 5:50 AM, Ben Adams wrote: >> >>> Its been mentioned several times before, however I'd like to request >>> that WEBGL_frag_depth be added to the extensions. >>> >>> http://www.khronos.org/registry/gles/extensions/EXT/EXT_frag_depth.txt >>> >>> Previous mentions: >>> >>> gl_FragDepth and the focus of WebGL >>> >>> https://www.khronos.org/webgl/public-mailing-list/archives/1204/msg00033.html >>> >>> >>> Dynamic loops and gl_FragDepth access in fragment shader >>> >>> https://www.khronos.org/webgl/public-mailing-list/archives/1201/msg00142.html >>> >>> As mentioned in follow up by Florian B?sch: >>> This is a useful capability in circumstances where >>> raycasting, raytracing, path-tracing, paralax-mapping, signed distance >>> fields, impostors etc. are involved and rendered together with >>> rasterized geometry. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Dec 3 10:12:39 2012 From: kbr...@ (Kenneth Russell) Date: Mon, 3 Dec 2012 10:12:39 -0800 Subject: [Public WebGL] Implement extension EXT_frag_depth in WebGL In-Reply-To: References: Message-ID: No objections here. Slight concern that it seems to be supported on very few mobile devices. FYI, implementing this will require changes to ANGLE's shader translator, similar to how OES_standard_derivatives was implemented. This means it'll be slightly more work to expose it than other extensions. -Ken On Mon, Dec 3, 2012 at 5:26 AM, Florian B?sch wrote: > Any objections of moving this extension to draft status? > > > On Wed, Nov 28, 2012 at 8:13 PM, Florian B?sch wrote: >> >> The proposed extension as been merged into the khronos repository (thanks >> Kenneth). >> >> Please review the extension proposal: >> http://www.khronos.org/registry/webgl/extensions/proposals/EXT_frag_depth/ >> >> Thanks >> >> >> On Thu, Nov 22, 2012 at 11:07 AM, Florian B?sch wrote: >>> >>> Specified in: >>> >>> OpenGL: Available in the core specification to OpenGL 2.0, released 2004 >>> OpenGL ES: >>> >>> Available as extension ES: EXT_frag_depth, released 2010 >>> Available in the core specification to OpenGL ES 3.0, released 2012 >>> >>> Direct3D: Available since Shader Model 2.0, Released with Direct3D 9.0 in >>> 2002 >>> >>> Hardware availability >>> >>> Desktops: 99.45% (not being DX8 GPUs or below), source: >>> http://store.steampowered.com/hwsurvey >>> Mobiles: As of November 2012, 7 devices out of 783, source: >>> http://www.glbenchmark.com/result.jsp >>> >>> Freescale SABRESD-MX6DQ >>> Huawei MediaPad 10 FHD >>> Huawei U9508 >>> Huawei U9510 >>> Huawei U9510E >>> Marvell PXA988 >>> Panasonic Toughpad FZ-A1B >>> >>> >>> Proposed Extension: https://github.com/KhronosGroup/WebGL/pull/84 >>> >>> >>> On Thu, Nov 22, 2012 at 5:50 AM, Ben Adams >>> wrote: >>>> >>>> Its been mentioned several times before, however I'd like to request >>>> that WEBGL_frag_depth be added to the extensions. >>>> >>>> http://www.khronos.org/registry/gles/extensions/EXT/EXT_frag_depth.txt >>>> >>>> Previous mentions: >>>> >>>> gl_FragDepth and the focus of WebGL >>>> >>>> https://www.khronos.org/webgl/public-mailing-list/archives/1204/msg00033.html >>>> >>>> Dynamic loops and gl_FragDepth access in fragment shader >>>> >>>> https://www.khronos.org/webgl/public-mailing-list/archives/1201/msg00142.html >>>> >>>> As mentioned in follow up by Florian B?sch: >>>> This is a useful capability in circumstances where raycasting, >>>> raytracing, path-tracing, paralax-mapping, signed distance fields, impostors >>>> etc. are involved and rendered together with rasterized geometry. >>> >>> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Dec 3 10:22:25 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 3 Dec 2012 19:22:25 +0100 Subject: [Public WebGL] Implement extension EXT_frag_depth in WebGL In-Reply-To: References: Message-ID: On Mon, Dec 3, 2012 at 7:12 PM, Kenneth Russell wrote: > Slight concern that it seems to be supported on > very few mobile devices. > I find that odd as well. Especially given that ES 2.0 was modelled after OGL 3.0 which has included that capability for nearly a decade. But I wouldn't be concerned about it for two reasons really: 1) It's coming anyway with ES 3.0 and presumably as vendors start supporting ES 3.0 support will go up. 2) I have a hard time imagining that it's actually absent in the hardware (after all it has been core part of any programmable hardware since a decade). I suspect it's just not exposed by the driver. So most likely vendors can provide a lot of support with a firmware update. Given that depth writes are not free (they abort early-z), techniques which use depth writes are nearly all in the category of high performance optimizations. It's unlikely those matter much on mobiles. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Dec 3 18:15:38 2012 From: cal...@ (Mark Callow) Date: Tue, 04 Dec 2012 11:15:38 +0900 Subject: [Public WebGL] Implement extension EXT_frag_depth in WebGL In-Reply-To: References: Message-ID: <50BD5CCA.9090400@artspark.co.jp> On 2012/12/04 3:22, Florian B?sch wrote: > On Mon, Dec 3, 2012 at 7:12 PM, Kenneth Russell > wrote: > > Slight concern that it seems to be supported on > very few mobile devices. > > I find that odd as well. Especially given that ES 2.0 was modelled > after OGL 3.0 which has included that capability for nearly a decade. > But I wouldn't be concerned about it for two reasons really: I don't know what gave you that idea. OpenGL 3.0 was released in August 2008, OpenGL ES 2.0 in March 2007. Clearly it is based on OpenGL 2.0. > 1) It's coming anyway with ES 3.0 and presumably as vendors start > supporting ES 3.0 support will go up. > 2) I have a hard time imagining that it's actually absent in the > hardware (after all it has been core part of any programmable hardware > since a decade). I suspect it's just not exposed by the driver. So > most likely vendors can provide a lot of support with a firmware update. I don't think the vendors have any interest in keeping features concealed. If it was in the hardware they would advertise the extension. 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 Dec 4 02:24:45 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 4 Dec 2012 11:24:45 +0100 Subject: [Public WebGL] Implement extension EXT_frag_depth in WebGL In-Reply-To: <50BD5CCA.9090400@artspark.co.jp> References: <50BD5CCA.9090400@artspark.co.jp> Message-ID: On Tue, Dec 4, 2012 at 3:15 AM, Mark Callow wrote: > I don't know what gave you that idea. OpenGL 3.0 was released in August > 2008, OpenGL ES 2.0 in March 2007. Clearly it is based on OpenGL 2.0. > Well even more mysterious then, since OpenGL 2.0 had frag depth for half a decade before ES copied the API (but not this functionality) > I don't think the vendors have any interest in keeping features concealed. > If it was in the hardware they would advertise the extension. > If you can call "discard" in a shader then the hardware/driver must have a path that excludes early-z as well as a conditional on the depth write. I just find it unlikely that you'd have an early-z switch and depth write conditional, but no way to set the depth value. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Dec 5 23:59:15 2012 From: jgi...@ (Jeff Gilbert) Date: Wed, 5 Dec 2012 23:59:15 -0800 (PST) Subject: [Public WebGL] y-orientation for texImage2D from HTML elements In-Reply-To: <1926635584.21104988.1354777247415.JavaMail.root@mozilla.com> Message-ID: <54853043.21108613.1354780755004.JavaMail.root@mozilla.com> It seems backwards (as implemented) and underdefined in the spec. It looks like we all upload HTML element texImage data with 0,0=top-left, making it effectively upside-down. The following two lines yield different results: [1] gl.copyTexImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight, 0); [2] gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, gl.canvas); [1] matches this: [3] var data = new Uint8Array(gl.drawingBufferWidth * gl.drawingBufferHeight * 4); gl.readPixels(0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight, gl.RGBA, gl.UNSIGNED_BYTE, data); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.drawingBufferWidth, gl.drawingBufferHeight, 0, gl.RGBA, gl.UNSIGNED_BYTE, data); UNPACK_FLIP_Y_WEBGL=true makes [2] the same as [1], but now [3] is upside-down. This is Mozilla bug 818810: https://bugzilla.mozilla.org/show_bug.cgi?id=818810 Testcase showing inconsistent behavior: https://bugzilla.mozilla.org/attachment.cgi?id=689110 As I mention in the bug, it doesn't look like y-orientation of texImage2D of HTML elements is well-specified in the spec. So far everyone appears to have implemented it the same, though. My suggestion was adding an UNPACK_ pixelStore option that allows us to get OpenGL-style 0,0=bottom-left texImage2D uploads of HTML elements. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Thu Dec 6 00:35:14 2012 From: gma...@ (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=) Date: Thu, 6 Dec 2012 17:35:14 +0900 Subject: [Public WebGL] y-orientation for texImage2D from HTML elements In-Reply-To: <54853043.21108613.1354780755004.JavaMail.root@mozilla.com> References: <1926635584.21104988.1354777247415.JavaMail.root@mozilla.com> <54853043.21108613.1354780755004.JavaMail.root@mozilla.com> Message-ID: This isn't a bug. it's by design. By default WebGL does the same as GL. It doesn't flip anything. The "data" pointer passed to texImage2D represents the bottom left corner of the texture. Whether that's an ArrayBuffer, an Image, a Canvas, a Video. For Image, Canvas, and Video that means by default they'be upside down (which is the same as GL). CopyTexImage2D in GL has always been "effectively" backward relative to TexImage2D when talking about images because most (all?) image libraries load images with the first pixel in the top, left and GL expects the first pixel is the bottom, left. Since CopyTexImage is copying internally it appears to have different behavior because it's matching src data 0x0 = bottom, left, dst data 0x0 = bottom left where as TexImage2D, when passing standard image data, is src data 0x0 = top,left, dest = bottom, left If you want WebGL to flip the data for you call gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true); There is no PACK_FLIP_Y so readPixels will always return the bottom,left as the first data in the array buffer. As for matching implementations it's all tested in the conformance tests AFAIK. On Thu, Dec 6, 2012 at 4:59 PM, Jeff Gilbert wrote: > > It seems backwards (as implemented) and underdefined in the spec. It looks > like we all upload HTML element texImage data with 0,0=top-left, making it > effectively upside-down. > > The following two lines yield different results: > [1] gl.copyTexImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 0, 0, > gl.drawingBufferWidth, gl.drawingBufferHeight, 0); > [2] gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, > gl.canvas); > > [1] matches this: [3] > var data = new Uint8Array(gl.drawingBufferWidth * gl.drawingBufferHeight * > 4); > gl.readPixels(0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight, > gl.RGBA, gl.UNSIGNED_BYTE, data); > gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.drawingBufferWidth, > gl.drawingBufferHeight, 0, gl.RGBA, gl.UNSIGNED_BYTE, data); > > UNPACK_FLIP_Y_WEBGL=true makes [2] the same as [1], but now [3] is > upside-down. > > This is Mozilla bug 818810: > https://bugzilla.mozilla.org/show_bug.cgi?id=818810 > > Testcase showing inconsistent behavior: > https://bugzilla.mozilla.org/attachment.cgi?id=689110 > > As I mention in the bug, it doesn't look like y-orientation of texImage2D > of HTML elements is well-specified in the spec. So far everyone appears to > have implemented it the same, though. > > My suggestion was adding an UNPACK_ pixelStore option that allows us to > get OpenGL-style 0,0=bottom-left texImage2D uploads of HTML elements. > > ----------------------------------------------------------- > 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 jgi...@ Thu Dec 6 16:51:09 2012 From: jgi...@ (Jeff Gilbert) Date: Thu, 6 Dec 2012 16:51:09 -0800 (PST) Subject: [Public WebGL] y-orientation for texImage2D from HTML elements In-Reply-To: Message-ID: <1818261404.21978268.1354841469068.JavaMail.root@mozilla.com> It most certainly is a bug that it is not specified. My point is we never specify that data is uploaded to texImage2D from HTML elements top-row-first. Just because we're 'used to' talking about image data top-row-first doesn't mean we shouldn't process this data into GL's coord system. The reasonable default, if we're doing the legwork of uploading HTML element contents, is to upload them (at least by default) in the orientation GL expects: bottom-row-first. If you want to specify everything top-row-first, we should use our UNPACK boolean for that. As it stands, it works consistently only if you pretend that for some reason, OpenGL textures coords are 0,0=top-left. That's the way we upload HTML elements, and if you pass texImage TypedArray data in top-row-first order, it'll upload upside-down, but since you y-flip the texture coords (that is, use 0,0=top-left), now it's correctly oriented. One of the key issues is there's no way to configure UNPACK such that texImage2D's upload orientation always matches GL's coord system. CopyTexImage isn't backwards, it matches GL's coordinate system. CopyTexImage, ReadPixels, and TexImage all specify that they are bottom-row-first. Scissor and Viewport, being in window space, are also 0,0=bottom-left. The idea that textures are 0,0=top-left goes against OpenGL's 0,0=bottom-left coord system. (actually -1,-1=bottom-left, for clip space) CopyTexImage matches the behavior of calling texImage2D on data retrieved from readPixels. It would *ideally* match calling texImage2D on our canvas, but it doesn't. Instead, we readPixels data down, y-flip it, then reupload it. Ideally we would just call CopyTexImage instead of ReadPixels+TexImage, but it doesn't looks like we even can. Instead, we would have to CopyTexImage, create a new texture, wrap it in a framebuffer, and draw a full-screen quad with the original copyTexImage texture, but with y coords flipped. TexImage2D with both TypedArrays and canvas/image/video elements is only consistent for u/v 0,0=top-left. But then it's no longer consistent with CopyTexImage or ReadPixels. Now we're in y-flip hell. Proposal: Since basically everyone uses texImage2D() for content delivery, I don't think we can afford to break compatibility there. What I propose is adding a new UNPACK_HTML_FLIP_Y_WEBGL, which defaults to `true`, which specifies that WebGL will upload HTML elements top-row-first into texImage2D, as we do today. However, with `false`, we would upload elements bottom-row-first, such that texImage2D(gl.canvas) has the same result as copyTexImage2D. -Jeff ----- Original Message ----- From: "Gregg Tavares (??)" To: "Jeff Gilbert" Cc: "public webgl" Sent: Thursday, December 6, 2012 12:35:14 AM Subject: Re: [Public WebGL] y-orientation for texImage2D from HTML elements This isn't a bug. it's by design. By default WebGL does the same as GL. It doesn't flip anything. The "data" pointer passed to texImage2D represents the bottom left corner of the texture. Whether that's an ArrayBuffer, an Image, a Canvas, a Video. For Image, Canvas, and Video that means by default they'be upside down (which is the same as GL). CopyTexImage2D in GL has always been "effectively" backward relative to TexImage2D when talking about images because most (all?) image libraries load images with the first pixel in the top, left and GL expects the first pixel is the bottom, left. Since CopyTexImage is copying internally it appears to have different behavior because it's matching src data 0x0 = bottom, left, dst data 0x0 = bottom left where as TexImage2D, when passing standard image data, is src data 0x0 = top,left, dest = bottom, left If you want WebGL to flip the data for you call gl.pixelStorei(gl.UNPACK_FLIP_Y_WEBGL, true); There is no PACK_FLIP_Y so readPixels will always return the bottom,left as the first data in the array buffer. As for matching implementations it's all tested in the conformance tests AFAIK. On Thu, Dec 6, 2012 at 4:59 PM, Jeff Gilbert < jgilbert...@ > wrote: It seems backwards (as implemented) and underdefined in the spec. It looks like we all upload HTML element texImage data with 0,0=top-left, making it effectively upside-down. The following two lines yield different results: [1] gl.copyTexImage2D(gl.TEXTURE_2D, 0, gl.RGBA, 0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight, 0); [2] gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, gl.canvas); [1] matches this: [3] var data = new Uint8Array(gl.drawingBufferWidth * gl.drawingBufferHeight * 4); gl.readPixels(0, 0, gl.drawingBufferWidth, gl.drawingBufferHeight, gl.RGBA, gl.UNSIGNED_BYTE, data); gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.drawingBufferWidth, gl.drawingBufferHeight, 0, gl.RGBA, gl.UNSIGNED_BYTE, data); UNPACK_FLIP_Y_WEBGL=true makes [2] the same as [1], but now [3] is upside-down. This is Mozilla bug 818810: https://bugzilla.mozilla.org/show_bug.cgi?id=818810 Testcase showing inconsistent behavior: https://bugzilla.mozilla.org/attachment.cgi?id=689110 As I mention in the bug, it doesn't look like y-orientation of texImage2D of HTML elements is well-specified in the spec. So far everyone appears to have implemented it the same, though. My suggestion was adding an UNPACK_ pixelStore option that allows us to get OpenGL-style 0,0=bottom-left texImage2D uploads of HTML elements. ----------------------------------------------------------- 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...@ Thu Dec 6 17:09:48 2012 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 7 Dec 2012 02:09:48 +0100 Subject: [Public WebGL] y-orientation for texImage2D from HTML elements In-Reply-To: <1818261404.21978268.1354841469068.JavaMail.root@mozilla.com> References: <1818261404.21978268.1354841469068.JavaMail.root@mozilla.com> Message-ID: copyTexImage2D, texImage2D, readPixels, scissors and viewport are defined in the ES 2.0 specification to be bottom up. When rendering to an FBO then left/bottom is UV 0,0. Internally the ES 2.0 specification is consistent. The correct choice would have been to upload bottom row first for all calls from , ,