From bja...@ Mon Nov 1 04:27:30 2010 From: bja...@ (Benoit Jacob) Date: Mon, 1 Nov 2010 04:27:30 -0700 (PDT) Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CCE3F00.7040305@hicorp.co.jp> Message-ID: <1899691075.238623.1288610849995.JavaMail.root@cm-mail03.mozilla.org> >> Do you have webgl.verbose=true ? > When was this added? I'm running FF 4.0 beta 6 and there is no such > property in about:config . Yes, this was added after beta6. The reasons were that webgl messages were potentially too verbose, in some cases even slowing webgl demos down. I am still wondering whether we can rely on people to spontaneously find out about that, or if we should print at least one message "There are WebGL warnings in this page, go to about:config and set webgl.verbose to see them". Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From zhe...@ Mon Nov 1 06:59:08 2010 From: zhe...@ (Mo, Zhenyao) Date: Mon, 1 Nov 2010 06:59:08 -0700 Subject: [Public WebGL] Proposed clarification in spec section 6.3 Framebuffer Object Attachments In-Reply-To: <1601993758.223153.1288377299877.JavaMail.root@cm-mail03.mozilla.org> References: <1601993758.223153.1288377299877.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Add two more: copyTexImage2D and copyTexSubImage2D. Mo On Fri, Oct 29, 2010 at 11:34 AM, Benoit Jacob wrote: > Hi, > > In section 6.3 we say that in case of conflicting attachments, "Calls which modify the framebuffer such as clear and drawArrays must generate an INVALID_FRAMEBUFFER_OPERATION error, and leave the contents of the framebuffer untouched." > > I suggest to replace "which modify" by "which access" and to list explicitly all four (I believe) such functions: > ?clear() > ?drawArrays() > ?drawElements() > ?readPixels() > > Indeed, in OpenGL, glReadPixels is generating INVALID_FRAMEBUFFER_OPERATION on incomplete framebuffers, so I guess that this should be no different. > > Cheers, > Benoit > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From zhe...@ Mon Nov 1 09:55:13 2010 From: zhe...@ (Mo, Zhenyao) Date: Mon, 1 Nov 2010 09:55:13 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CCDD960.9070205@sjbaker.org> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> Message-ID: I tried your test case with top-of-tree Chrome on Mac and Windows. Both do not have the background leaking issue you saw here. Can you try the same build and confirm? For the Windows build, you need to pass in --use-gl=desktop flag. Apparently there is a bug in ANGLE, so without the flag you won't see the WebGL canvas at all - at least that's the case on my machine. Mo On Sun, Oct 31, 2010 at 2:02 PM, Steve Baker wrote: > OK - I finally have a reasonably simple test case at: > > ? ?http://www.sjbaker.org/test/index.php > > ...I apologize if some of the code doesn't look exactly pretty - it's > been brutally ripped out of a 5000 line application. ?The checkerboard > background helps you see the blending issues clearly - but it's a bit > hard on the eyes! > > We should see a dark brown canvas on a checkerboard background - with a > chair and a grey translucent 'smoke puff' slicing through it. > > * The only setup that I've found seems to display it "correctly" (ie > without dest-alpha) is Chrome under Linux/64bit...but I don't have a Mac > to test on so we'll give Safari the benefit of the doubt right now. > > * Minefield lets the background 'leak' through the image (presumably > because we can't shut off destination-alpha because of bug 539771. > (That's a **REALLY** serious bug!) > > * Chrome under Windows7/32bit also lets the background leak through - > but does a weird compositing job. > > * None of the browsers are getting the alpha=0 thing right. > > * If you remove the "alpha:false" from the getContext call - you can > also see that Chrome and Minefield composite the resulting dest-alpha > canvas differently. > >> If you go to about:config and set >> ? ?layers.accelerate-all=false >> ? ?layers.accelerate-none=true >> Does that make a difference? > > No...no difference at all. > >> If yes, you have found a bug in our accelerated compositing code. >> If no, we can't conclude anything. > > Oh. ? :-( > > ?-- Steve > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kwa...@ Mon Nov 1 10:08:27 2010 From: kwa...@ (Kenneth Waters) Date: Mon, 1 Nov 2010 10:08:27 -0700 Subject: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions) In-Reply-To: References: <1334986010.134216.1286311365139.JavaMail.root@cm-mail03.mozilla.org> <4CABA570.5050500@sjbaker.org> <2B3D9756-1126-4168-A5B0-C551DD0A586A@apple.com> <4CABDDDB.7080503@sjbaker.org> <4CABEE04.7030501@sjbaker.org> Message-ID: > > Actually, I think that this texture access pattern attack could be > detected by tracking variable use. Only allow untainted texture coords > in texture2D, mark variable as tainted if it is the lvalue of an > expression with a tainted rvalue or a texture2D call. > This is insufficient, you'd also have to block control flow based on tainted values. And tainted texture fetches in vertex shaders. And then I'm still not confident. -- Kenneth Waters -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Mon Nov 1 10:47:07 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 1 Nov 2010 10:47:07 -0700 Subject: [Public WebGL] Why have readpixels support 5_6_5? Message-ID: OpenGL ES 2.0 specifically only allows readpixels to work with 2 formats. 1: RGBA / UNSIGNED_BYTE 2: Implementation defined RGB or RGBA format I'm just guessing but the only reason for the second format is it's the "no conversion" path. In other words, if the hardware is rendering to 4_4_4_4 the second format on that implementation will be RGBA / UNSIGNED_SHORT_4_4_4_4 since no conversion = no memory needed + fast. WebGL on the other hand is currently speced as requiring the second format to be RGB / UNSIGNED_SHORT_5_6_5 so that the second format is consistent across browsers. The question I have is why even support a second format in WebGL? If the only reason for the existence of a second format is to avoid conversion and get speed then requiring a specific format in WebGL defeats that goal. A WebGL implementation will have to query if 5_6_5 is supported and if not do the conversion removing all the speed and memory benefits. With that benefit removed why not just change the WebGL spec only support RGBA / UNSIGNED_BYTE as a readpixels format? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon Nov 1 10:58:40 2010 From: jda...@ (John Davis) Date: Mon, 1 Nov 2010 12:58:40 -0500 Subject: [Public WebGL] Android Message-ID: Is there a nightly build for webgl on android? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Mon Nov 1 11:16:16 2010 From: ste...@ (ste...@) Date: Mon, 1 Nov 2010 11:16:16 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> Message-ID: <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> Yep - it looks fine in the Canary build under Windows with --use-gl=desktop. Presumably that's the difference though. Under Linux, Chrome is forced to use OpenGL because it's the only game in town. If there is no destination-alpha bug in Chrome/OpenGL then that explains what I'm seeing. You're not seeing my problem with ANGLE right now because it's broken and you don't see anything at all (neither do I since it auto-upgraded sometime yesterday). The older Windows build I have been using (sorry - I don't have the version number to hand right now) runs ANGLE OK - and there the background-leakage bug is more or less the same as in Minefield...but I don't think there is a common cause because Minefield under Linux uses OpenGL and it's also broken. I'd guess that ANGLE is ignoring "alpha:false" in getCompositor and returning me a destination-alpha canvas come-what-may - but OpenGL is doing the right thing. -- Steve > I tried your test case with top-of-tree Chrome on Mac and Windows. > Both do not have the background leaking issue you saw here. Can you > try the same build and confirm? > > For the Windows build, you need to pass in --use-gl=desktop flag. > Apparently there is a bug in ANGLE, so without the flag you won't see > the WebGL canvas at all - at least that's the case on my machine. > > Mo > > On Sun, Oct 31, 2010 at 2:02 PM, Steve Baker wrote: >> OK - I finally have a reasonably simple test case at: >> >> ? ?http://www.sjbaker.org/test/index.php >> >> ...I apologize if some of the code doesn't look exactly pretty - it's >> been brutally ripped out of a 5000 line application. ?The checkerboard >> background helps you see the blending issues clearly - but it's a bit >> hard on the eyes! >> >> We should see a dark brown canvas on a checkerboard background - with a >> chair and a grey translucent 'smoke puff' slicing through it. >> >> * The only setup that I've found seems to display it "correctly" (ie >> without dest-alpha) is Chrome under Linux/64bit...but I don't have a Mac >> to test on so we'll give Safari the benefit of the doubt right now. >> >> * Minefield lets the background 'leak' through the image (presumably >> because we can't shut off destination-alpha because of bug 539771. >> (That's a **REALLY** serious bug!) >> >> * Chrome under Windows7/32bit also lets the background leak through - >> but does a weird compositing job. >> >> * None of the browsers are getting the alpha=0 thing right. >> >> * If you remove the "alpha:false" from the getContext call - you can >> also see that Chrome and Minefield composite the resulting dest-alpha >> canvas differently. >> >>> If you go to about:config and set >>> ? ?layers.accelerate-all=false >>> ? ?layers.accelerate-none=true >>> Does that make a difference? >> >> No...no difference at all. >> >>> If yes, you have found a bug in our accelerated compositing code. >>> If no, we can't conclude anything. >> >> Oh. ? :-( >> >> ?-- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Mon Nov 1 11:55:36 2010 From: cma...@ (Chris Marrin) Date: Mon, 01 Nov 2010 11:55:36 -0700 Subject: [Public WebGL] Apple WebGL In-Reply-To: References: <8139E249-AEA2-4A6D-9C38-2A57B7919DBB@apple.com> Message-ID: On Oct 29, 2010, at 7:14 PM, John Davis wrote: > I'm sure it's speculation, assuming it's Safari on the Apple TV. But just to be clear, Apple has made no announcements about the availability of Safari or any other web browsing solution on Apple TV. > > On Fri, Oct 29, 2010 at 11:49 AM, Chris Marrin wrote: > > On Oct 28, 2010, at 4:36 PM, John Davis wrote: > > > Chris Marrin, will the upcoming web browser for gen2 Apple TV support WebGL just like Google TV? > > > > I can never comment on upcoming products. But what upcoming web browser are you talking about? > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > > ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From zhe...@ Mon Nov 1 11:59:02 2010 From: zhe...@ (Mo, Zhenyao) Date: Mon, 1 Nov 2010 11:59:02 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> Message-ID: Thx for helping identify the issue and providing a nice test case (please don't delete it. At least keep it for a few days, as I used the link in my bug report). Mo On Mon, Nov 1, 2010 at 11:16 AM, wrote: > Yep - it looks fine in the Canary build under Windows with --use-gl=desktop. > > Presumably that's the difference though. ?Under Linux, Chrome is forced to > use OpenGL because it's the only game in town. ?If there is no > destination-alpha bug in Chrome/OpenGL then that explains what I'm seeing. > > You're not seeing my problem with ANGLE right now because it's broken and > you don't see anything at all (neither do I since it auto-upgraded > sometime yesterday). ?The older Windows build I have been using (sorry - I > don't have the version number to hand right now) runs ANGLE OK - and there > the background-leakage bug is more or less the same as in Minefield...but > I don't think there is a common cause because Minefield under Linux uses > OpenGL and it's also broken. > > I'd guess that ANGLE is ignoring "alpha:false" in getCompositor and > returning me a destination-alpha canvas come-what-may - but OpenGL is > doing the right thing. > > ?-- Steve > >> I tried your test case with top-of-tree Chrome on Mac and Windows. >> Both do not have the background leaking issue you saw here. ?Can you >> try the same build and confirm? >> >> For the Windows build, you need to pass in --use-gl=desktop flag. >> Apparently there is a bug in ANGLE, so without the flag you won't see >> the WebGL canvas at all - at least that's the case on my machine. >> >> Mo >> >> On Sun, Oct 31, 2010 at 2:02 PM, Steve Baker wrote: >>> OK - I finally have a reasonably simple test case at: >>> >>> ? ?http://www.sjbaker.org/test/index.php >>> >>> ...I apologize if some of the code doesn't look exactly pretty - it's >>> been brutally ripped out of a 5000 line application. ?The checkerboard >>> background helps you see the blending issues clearly - but it's a bit >>> hard on the eyes! >>> >>> We should see a dark brown canvas on a checkerboard background - with a >>> chair and a grey translucent 'smoke puff' slicing through it. >>> >>> * The only setup that I've found seems to display it "correctly" (ie >>> without dest-alpha) is Chrome under Linux/64bit...but I don't have a Mac >>> to test on so we'll give Safari the benefit of the doubt right now. >>> >>> * Minefield lets the background 'leak' through the image (presumably >>> because we can't shut off destination-alpha because of bug 539771. >>> (That's a **REALLY** serious bug!) >>> >>> * Chrome under Windows7/32bit also lets the background leak through - >>> but does a weird compositing job. >>> >>> * None of the browsers are getting the alpha=0 thing right. >>> >>> * If you remove the "alpha:false" from the getContext call - you can >>> also see that Chrome and Minefield composite the resulting dest-alpha >>> canvas differently. >>> >>>> If you go to about:config and set >>>> ? ?layers.accelerate-all=false >>>> ? ?layers.accelerate-none=true >>>> Does that make a difference? >>> >>> No...no difference at all. >>> >>>> If yes, you have found a bug in our accelerated compositing code. >>>> If no, we can't conclude anything. >>> >>> Oh. ? :-( >>> >>> ?-- Steve > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From dan...@ Mon Nov 1 12:04:26 2010 From: dan...@ (Daniel Koch) Date: Mon, 1 Nov 2010 15:04:26 -0400 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: References: Message-ID: <9F2A8AFA-6B7C-492D-9157-49737A42B6A7@transgaming.com> Not that this exactly answers your question, but it is worth noting that the GLES2 implementation-defined format is actually framebuffer-dependent, and thus may not always be the same. Quoting from page 103 of the ES 2.0 spec: The values of format and type for this format may be determined by calling GetIntegerv with the symbolic constants IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_- COLOR_READ_TYPE, respectively. The implementation-chosen format may vary depending on the format of the currently bound rendering surface. Daniel On 2010-11-01, at 1:47 PM, Gregg Tavares (wrk) wrote: > OpenGL ES 2.0 specifically only allows readpixels to work with 2 formats. > > 1: RGBA / UNSIGNED_BYTE > 2: Implementation defined RGB or RGBA format > > I'm just guessing but the only reason for the second format is it's the "no conversion" path. In other words, if the hardware is rendering to 4_4_4_4 the second format on that implementation will be RGBA / UNSIGNED_SHORT_4_4_4_4 since no conversion = no memory needed + fast. > > WebGL on the other hand is currently speced as requiring the second format to be RGB / UNSIGNED_SHORT_5_6_5 so that the second format is consistent across browsers. > > The question I have is why even support a second format in WebGL? If the only reason for the existence of a second format is to avoid conversion and get speed then requiring a specific format in WebGL defeats that goal. A WebGL implementation will have to query if 5_6_5 is supported and if not do the conversion removing all the speed and memory benefits. > > With that benefit removed why not just change the WebGL spec only support RGBA / UNSIGNED_BYTE as a readpixels format? --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Mon Nov 1 12:33:35 2010 From: bja...@ (Benoit Jacob) Date: Mon, 1 Nov 2010 12:33:35 -0700 (PDT) Subject: [Public WebGL] Android In-Reply-To: Message-ID: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> If you want a nightly of Firefox for Android, I guess this should be the right place: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-11-01-04-mozilla-central-android-r7/ Benoit ----- Original Message ----- > Is there a nightly build for webgl on android? > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From jda...@ Mon Nov 1 12:46:35 2010 From: jda...@ (John Davis) Date: Mon, 1 Nov 2010 14:46:35 -0500 Subject: [Public WebGL] Re: Android In-Reply-To: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> References: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> Message-ID: What about the android default browser? On Monday, November 1, 2010, Benoit Jacob wrote: > If you want a nightly of Firefox for Android, I guess this should be the right place: > > http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-11-01-04-mozilla-central-android-r7/ > > Benoit > > ----- Original Message ----- >> Is there a nightly build for webgl on android? >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Mon Nov 1 12:50:02 2010 From: kbr...@ (Kenneth Russell) Date: Mon, 1 Nov 2010 12:50:02 -0700 Subject: [Public WebGL] Re: Android In-Reply-To: References: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Not currently. -Ken On Mon, Nov 1, 2010 at 12:46 PM, John Davis wrote: > What about the android default browser? > > On Monday, November 1, 2010, Benoit Jacob wrote: >> If you want a nightly of Firefox for Android, I guess this should be the right place: >> >> http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-11-01-04-mozilla-central-android-r7/ >> >> Benoit >> >> ----- Original Message ----- >>> Is there a nightly build for webgl on android? >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> >> >> > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Mon Nov 1 12:54:14 2010 From: kbr...@ (Kenneth Russell) Date: Mon, 1 Nov 2010 12:54:14 -0700 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: <9F2A8AFA-6B7C-492D-9157-49737A42B6A7@transgaming.com> References: <9F2A8AFA-6B7C-492D-9157-49737A42B6A7@transgaming.com> Message-ID: I wasn't particularly happy with the decision at the last WebGL F2F to specify the implementation color read format and type. Daniel's point about it being legal to change depending on what precise framebuffer is bound is a good one. I propose removing the text from the WebGL spec hardcoding the implementation read format and type. -Ken On Mon, Nov 1, 2010 at 12:04 PM, Daniel Koch wrote: > Not that this exactly answers your question, but it is worth noting that the > GLES2 implementation-defined format is actually framebuffer-dependent, and > thus may not always be the same. > Quoting from page 103 of the ES 2.0 spec: > The values of format and type for this format may be determined by calling > GetIntegerv with the symbolic constants IMPLEMENTATION_COLOR_READ_FORMAT and > IMPLEMENTATION_- COLOR_READ_TYPE, respectively. The implementation-chosen > format may vary depending on the format of the currently bound rendering > surface. > Daniel > On 2010-11-01, at 1:47 PM, Gregg Tavares (wrk) wrote: > > OpenGL ES 2.0 specifically only allows readpixels to work with 2 formats. > 1: RGBA / UNSIGNED_BYTE > 2: Implementation defined RGB or RGBA format > I'm just guessing but the only reason for the second format is it's the "no > conversion" path. In other words, if the hardware is rendering to 4_4_4_4 > the second format on that implementation will be RGBA / > UNSIGNED_SHORT_4_4_4_4 since no conversion = no memory needed + fast. > WebGL on the other hand is currently speced as requiring the second format > to be RGB / UNSIGNED_SHORT_5_6_5 so that the second format is consistent > across browsers. > The question I have is why even support a second format in WebGL? If the > only reason for the existence of a second format is to avoid conversion and > get speed then requiring a specific format in WebGL defeats that goal. A > WebGL implementation will have to query if 5_6_5 is supported and if not do > the conversion removing all the speed and memory benefits. > With that benefit removed why not just change the WebGL spec only support > RGBA / UNSIGNED_BYTE as a readpixels format? > > --- > ?? ? ? ? ? ? ? ? ? ? ? ?Daniel Koch -+-?daniel...@ > Senior Graphics Architect?-+-?TransGaming Inc. ?-+-?www.transgaming.com > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Nov 1 13:09:31 2010 From: vla...@ (Vladimir Vukicevic) Date: Mon, 1 Nov 2010 13:09:31 -0700 (PDT) Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: Message-ID: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> Ah, I didn't realize that it could vary based on the bound framebuffer. It was suggested that we fix the type because it was an odd implementation-specific variance that wasn't covered by an extension that could be queried. But that made sense when we weren't thinking of it as framebuffer-specific; since it does vary, then I agree that it doesn't make sense to fix it (since most everything with fbos is implementation-dependant anyway!). Happy to change them back. - Vlad ----- Original Message ----- > I wasn't particularly happy with the decision at the last WebGL F2F to > specify the implementation color read format and type. Daniel's point > about it being legal to change depending on what precise framebuffer > is bound is a good one. I propose removing the text from the WebGL > spec hardcoding the implementation read format and type. > > -Ken > > On Mon, Nov 1, 2010 at 12:04 PM, Daniel Koch > wrote: > > Not that this exactly answers your question, but it is worth noting > > that the > > GLES2 implementation-defined format is actually > > framebuffer-dependent, and > > thus may not always be the same. > > Quoting from page 103 of the ES 2.0 spec: > > The values of format and type for this format may be determined by > > calling > > GetIntegerv with the symbolic constants > > IMPLEMENTATION_COLOR_READ_FORMAT and > > IMPLEMENTATION_- COLOR_READ_TYPE, respectively. The > > implementation-chosen > > format may vary depending on the format of the currently bound > > rendering > > surface. > > Daniel > > On 2010-11-01, at 1:47 PM, Gregg Tavares (wrk) wrote: > > > > OpenGL ES 2.0 specifically only allows readpixels to work with 2 > > formats. > > 1: RGBA / UNSIGNED_BYTE > > 2: Implementation defined RGB or RGBA format > > I'm just guessing but the only reason for the second format is it's > > the "no > > conversion" path. In other words, if the hardware is rendering to > > 4_4_4_4 > > the second format on that implementation will be RGBA / > > UNSIGNED_SHORT_4_4_4_4 since no conversion = no memory needed + > > fast. > > WebGL on the other hand is currently speced as requiring the second > > format > > to be RGB / UNSIGNED_SHORT_5_6_5 so that the second format is > > consistent > > across browsers. > > The question I have is why even support a second format in WebGL? If > > the > > only reason for the existence of a second format is to avoid > > conversion and > > get speed then requiring a specific format in WebGL defeats that > > goal. A > > WebGL implementation will have to query if 5_6_5 is supported and if > > not do > > the conversion removing all the speed and memory benefits. > > With that benefit removed why not just change the WebGL spec only > > support > > RGBA / UNSIGNED_BYTE as a readpixels format? > > > > --- > > ?? ? ? ? ? ? ? ? ? ? ? ?Daniel Koch -+- daniel...@ > > Senior Graphics Architect -+- TransGaming Inc. -+- > > www.transgaming.com > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Nov 1 13:09:58 2010 From: vla...@ (Vladimir Vukicevic) Date: Mon, 1 Nov 2010 13:09:58 -0700 (PDT) Subject: [Public WebGL] Android In-Reply-To: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <96170877.245225.1288642198027.JavaMail.root@cm-mail03.mozilla.org> Note that this doesn't support WebGL yet. - Vlad ----- Original Message ----- > If you want a nightly of Firefox for Android, I guess this should be > the right place: > > http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-11-01-04-mozilla-central-android-r7/ > > Benoit > > ----- Original Message ----- > > Is there a nightly build for webgl on android? > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From jda...@ Mon Nov 1 13:33:58 2010 From: jda...@ (John Davis) Date: Mon, 1 Nov 2010 15:33:58 -0500 Subject: [Public WebGL] Re: Android In-Reply-To: References: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Please tell me this is in the oven. With the java lawsuits, it's a good way out. On Monday, November 1, 2010, Kenneth Russell wrote: > Not currently. > > -Ken > > On Mon, Nov 1, 2010 at 12:46 PM, John Davis wrote: >> What about the android default browser? >> >> On Monday, November 1, 2010, Benoit Jacob wrote: >>> If you want a nightly of Firefox for Android, I guess this should be the right place: >>> >>> http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-11-01-04-mozilla-central-android-r7/ >>> >>> Benoit >>> >>> ----- Original Message ----- >>>> Is there a nightly build for webgl on android? >>>> ----------------------------------------------------------- >>>> You are currently subscribed to public_webgl...@ >>>> To unsubscribe, send an email to majordomo...@ with >>>> the following command in the body of your email: >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> >>> >>> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Mon Nov 1 13:38:27 2010 From: ste...@ (ste...@) Date: Mon, 1 Nov 2010 13:38:27 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> Message-ID: <7df3d409b6afe670b65c0114d7414f55.squirrel@webmail.sjbaker.org> No problem! You'd be amazed at how lazy I am about keeping my website tidy! It's a fairly safe bet that it'll still be there many years from now! I'm just amazed at how such a seemingly tiny problem (my particle systems look a bit darker in one browser than the other) has ballooned out into so many different bugs! * My own code was (originally) letting getContext default to destination alpha when I didn't want it. * Chrome gives me destination alpha all the time under ANGLE. * Minefield gives me destination alpha all the time (this is a known bug). * Chrome and Minefield disagree about how dest-alpha should be blended into the underlying image. (Although I'm still not sure which one has the bug)...which was the ultimate cause of my particle system problems. * Both browsers incorrectly AlphaTest out pixels where alpha==0.0 Note to developers: Test your code on checkerboard backgrounds! -- Steve > Thx for helping identify the issue and providing a nice test case > (please don't delete it. At least keep it for a few days, as I used > the link in my bug report). > > Mo > > On Mon, Nov 1, 2010 at 11:16 AM, wrote: >> Yep - it looks fine in the Canary build under Windows with >> --use-gl=desktop. >> >> Presumably that's the difference though. ?Under Linux, Chrome is forced >> to >> use OpenGL because it's the only game in town. ?If there is no >> destination-alpha bug in Chrome/OpenGL then that explains what I'm >> seeing. >> >> You're not seeing my problem with ANGLE right now because it's broken >> and >> you don't see anything at all (neither do I since it auto-upgraded >> sometime yesterday). ?The older Windows build I have been using (sorry - >> I >> don't have the version number to hand right now) runs ANGLE OK - and >> there >> the background-leakage bug is more or less the same as in >> Minefield...but >> I don't think there is a common cause because Minefield under Linux uses >> OpenGL and it's also broken. >> >> I'd guess that ANGLE is ignoring "alpha:false" in getCompositor and >> returning me a destination-alpha canvas come-what-may - but OpenGL is >> doing the right thing. >> >> ?-- Steve >> >>> I tried your test case with top-of-tree Chrome on Mac and Windows. >>> Both do not have the background leaking issue you saw here. ?Can you >>> try the same build and confirm? >>> >>> For the Windows build, you need to pass in --use-gl=desktop flag. >>> Apparently there is a bug in ANGLE, so without the flag you won't see >>> the WebGL canvas at all - at least that's the case on my machine. >>> >>> Mo >>> >>> On Sun, Oct 31, 2010 at 2:02 PM, Steve Baker wrote: >>>> OK - I finally have a reasonably simple test case at: >>>> >>>> ? ?http://www.sjbaker.org/test/index.php >>>> >>>> ...I apologize if some of the code doesn't look exactly pretty - it's >>>> been brutally ripped out of a 5000 line application. ?The checkerboard >>>> background helps you see the blending issues clearly - but it's a bit >>>> hard on the eyes! >>>> >>>> We should see a dark brown canvas on a checkerboard background - with >>>> a >>>> chair and a grey translucent 'smoke puff' slicing through it. >>>> >>>> * The only setup that I've found seems to display it "correctly" (ie >>>> without dest-alpha) is Chrome under Linux/64bit...but I don't have a >>>> Mac >>>> to test on so we'll give Safari the benefit of the doubt right now. >>>> >>>> * Minefield lets the background 'leak' through the image (presumably >>>> because we can't shut off destination-alpha because of bug 539771. >>>> (That's a **REALLY** serious bug!) >>>> >>>> * Chrome under Windows7/32bit also lets the background leak through - >>>> but does a weird compositing job. >>>> >>>> * None of the browsers are getting the alpha=0 thing right. >>>> >>>> * If you remove the "alpha:false" from the getContext call - you can >>>> also see that Chrome and Minefield composite the resulting dest-alpha >>>> canvas differently. >>>> >>>>> If you go to about:config and set >>>>> ? ?layers.accelerate-all=false >>>>> ? ?layers.accelerate-none=true >>>>> Does that make a difference? >>>> >>>> No...no difference at all. >>>> >>>>> If yes, you have found a bug in our accelerated compositing code. >>>>> If no, we can't conclude anything. >>>> >>>> Oh. ? :-( >>>> >>>> ?-- Steve >> >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From bja...@ Mon Nov 1 13:44:55 2010 From: bja...@ (Benoit Jacob) Date: Mon, 1 Nov 2010 13:44:55 -0700 (PDT) Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <7df3d409b6afe670b65c0114d7414f55.squirrel@webmail.sjbaker.org> Message-ID: <780789151.246002.1288644295362.JavaMail.root@cm-mail03.mozilla.org> > * Both browsers incorrectly AlphaTest out pixels where alpha==0.0 Sorry, I missed this part and can't find back where you explained it. What are we doing wrong specifically on pixels where alpha==0 ? Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Mon Nov 1 13:54:09 2010 From: kbr...@ (Kenneth Russell) Date: Mon, 1 Nov 2010 13:54:09 -0700 Subject: [Public WebGL] Re: Android In-Reply-To: References: <1756347522.244896.1288640015417.JavaMail.root@cm-mail03.mozilla.org> Message-ID: We'll send news as soon as some is available. -Ken On Mon, Nov 1, 2010 at 1:33 PM, John Davis wrote: > Please tell me this is in the oven. ?With the java lawsuits, it's a > good way out. > > On Monday, November 1, 2010, Kenneth Russell wrote: >> Not currently. >> >> -Ken >> >> On Mon, Nov 1, 2010 at 12:46 PM, John Davis wrote: >>> What about the android default browser? >>> >>> On Monday, November 1, 2010, Benoit Jacob wrote: >>>> If you want a nightly of Firefox for Android, I guess this should be the right place: >>>> >>>> http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2010-11-01-04-mozilla-central-android-r7/ >>>> >>>> Benoit >>>> >>>> ----- Original Message ----- >>>>> Is there a nightly build for webgl on android? >>>>> ----------------------------------------------------------- >>>>> You are currently subscribed to public_webgl...@ >>>>> To unsubscribe, send an email to majordomo...@ with >>>>> the following command in the body of your email: >>>> ----------------------------------------------------------- >>>> You are currently subscribed to public_webgl...@ >>>> To unsubscribe, send an email to majordomo...@ with >>>> the following command in the body of your email: >>>> >>>> >>>> >>> ----------------------------------------------------------- >>> You are currently subscribed to public_webgl...@ >>> To unsubscribe, send an email to majordomo...@ with >>> the following command in the body of your email: >>> >>> >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Mon Nov 1 18:16:15 2010 From: ste...@ (Steve Baker) Date: Mon, 01 Nov 2010 20:16:15 -0500 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <780789151.246002.1288644295362.JavaMail.root@cm-mail03.mozilla.org> References: <780789151.246002.1288644295362.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <4CCF665F.9070804@sjbaker.org> According to the spec, (forgive me if I misread it) - WebGL doesn't support the glAlphaFunc feature from OpenGL. (I think that's because it's not implemented in OpenGL ES 2.0) So if you want something like the OpenGL alpha test feature, you have to implement it yourself in your shader using: if ( alpha < alphaRef ) discard ; Well, my example program doesn't do that - hence, pixels with alpha==0.0 *SHOULD* be rendered just like pixels with (say) alpha==0.1 are. Right? So - look at my little test program: The smoke puff is a pair of triangles with a texture that has alpha==1.0 in the middle and alpha==0.0 at the edges. So when destination alpha is enabled (either deliberately or buggily) we should see a rectangular hole in the canvas - not a smoke-cloud-shaped hole. Even if destination-alpha were disabled, this behavior would cause unexpected issues with Z-buffering of completely transparent surfaces. The behavior I'm seeing is as if alpha testing were enabled with alphaRef set to some very small value. It should be an easy fix - just call glDisable(GL_ALPHA_TEST) someplace. What's weird is that should be the OpenGL default - so something somewhere is actively calling glEnable(GL_ALPHA_TEST)...and it shouldn't. AFAICT, neither Minefield nor Chrome is getting that right - not in OpenGL or ANGLE - Linux or Windows. The way things are right now, if someone actually WANTED to cut a perfectly transparent shape out of their destination-alpha canvas, they'd be unable to do so by writing alpha==0 pixels. -- Steve On 11/01/2010 03:44 PM, Benoit Jacob wrote: >> * Both browsers incorrectly AlphaTest out pixels where alpha==0.0 >> > Sorry, I missed this part and can't find back where you explained it. What are we doing wrong specifically on pixels where alpha==0 ? > > Benoit > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Mon Nov 1 18:49:17 2010 From: cal...@ (Mark Callow) Date: Tue, 02 Nov 2010 10:49:17 +0900 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <1899691075.238623.1288610849995.JavaMail.root@cm-mail03.mozilla.org> References: <1899691075.238623.1288610849995.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <4CCF6E1D.5050001@hicorp.co.jp> I think you should print at least one message like you describe. Regards -Mark On 01/11/2010 20:27, Benoit Jacob wrote: >>> Do you have webgl.verbose=true ? >> When was this added? I'm running FF 4.0 beta 6 and there is no such >> property in about:config . > Yes, this was added after beta6. The reasons were that webgl messages were potentially too verbose, in some cases even slowing webgl demos down. > > I am still wondering whether we can rely on people to spontaneously find out about that, or if we should print at least one message "There are WebGL warnings in this page, go to about:config and set webgl.verbose to see them". > > Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From jda...@ Mon Nov 1 19:09:41 2010 From: jda...@ (John Davis) Date: Mon, 1 Nov 2010 21:09:41 -0500 Subject: [Public WebGL] Apple WebGL In-Reply-To: References: <8139E249-AEA2-4A6D-9C38-2A57B7919DBB@apple.com> Message-ID: Thanks Chris, we're all looking forward to the first build ;) On Mon, Nov 1, 2010 at 1:55 PM, Chris Marrin wrote: > > On Oct 29, 2010, at 7:14 PM, John Davis wrote: > > > I'm sure it's speculation, assuming it's Safari on the Apple TV. > > But just to be clear, Apple has made no announcements about the > availability of Safari or any other web browsing solution on Apple TV. > > > > > On Fri, Oct 29, 2010 at 11:49 AM, Chris Marrin > wrote: > > > > On Oct 28, 2010, at 4:36 PM, John Davis wrote: > > > > > Chris Marrin, will the upcoming web browser for gen2 Apple TV support > WebGL just like Google TV? > > > > > > > I can never comment on upcoming products. But what upcoming web browser > are you talking about? > > > > ----- > > ~Chris > > cmarrin...@ > > > > > > > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > > > > > > > ----- > ~Chris > cmarrin...@ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Mon Nov 1 19:56:35 2010 From: ste...@ (Steve Baker) Date: Mon, 01 Nov 2010 21:56:35 -0500 Subject: [Public WebGL] Apple WebGL In-Reply-To: References: <8139E249-AEA2-4A6D-9C38-2A57B7919DBB@apple.com> Message-ID: <4CCF7DE3.2020106@sjbaker.org> I'm starting the rumor that Chris says it'll be running Erwise on WinPhone7. :-) -- Steve On 11/01/2010 09:09 PM, John Davis wrote: > Thanks Chris, we're all looking forward to the first build ;) > > On Mon, Nov 1, 2010 at 1:55 PM, Chris Marrin > wrote: > > > On Oct 29, 2010, at 7:14 PM, John Davis wrote: > > > I'm sure it's speculation, assuming it's Safari on the Apple TV. > > But just to be clear, Apple has made no announcements about the > availability of Safari or any other web browsing solution on Apple TV. > > > > > On Fri, Oct 29, 2010 at 11:49 AM, Chris Marrin > > wrote: > > > > On Oct 28, 2010, at 4:36 PM, John Davis wrote: > > > > > Chris Marrin, will the upcoming web browser for gen2 Apple TV > support WebGL just like Google TV? > > > > > > > I can never comment on upcoming products. But what upcoming web > browser are you talking about? > > > > ----- > > ~Chris > > cmarrin...@ > > > > > > > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > . > > To unsubscribe, send an email to majordomo...@ > with > > the following command in the body of your email: > > > > > > > > ----- > ~Chris > cmarrin...@ > > > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From tim...@ Tue Nov 2 01:52:18 2010 From: tim...@ (Tim Johansson) Date: Tue, 02 Nov 2010 09:52:18 +0100 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> References: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <4CCFD142.7070802@opera.com> On 2010-11-01 21:09, Vladimir Vukicevic wrote: > Ah, I didn't realize that it could vary based on the bound framebuffer. > > It was suggested that we fix the type because it was an odd implementation-specific variance that wasn't covered by an extension that could be queried. But that made sense when we weren't thinking of it as framebuffer-specific; since it does vary, then I agree that it doesn't make sense to fix it (since most everything with fbos is implementation-dependant anyway!). Happy to change them back. > If we want to change it I would prefer dropping implementation dependent read format and either only support RGBA8888 or require software conversion to support any format. If there is a implementation defined format I'm afraid we will not just ask the underlying GL what the format is and return that. If we do that we might end up not running all content since not all browsers/devices support the same format. What I fear we will instead end up doing for compatibility reasons is to reverse engineer what the most commonly supported read format is in other implementations and always report that (using software conversion if needed). What makes this issue different from most others IMO is that desktop does not have an implementation read format, so on desktop the WebGL implementations must choose one format it wants to support and the spec does not say anything about how you should choose that format (if we remove the hard coded 565). I really don't like reverse engineering other implementations in order to make an implementation that works with all content, and writing the spec so you might have to do that is IMO not good. //Tim > - Vlad > > ----- Original Message ----- >> I wasn't particularly happy with the decision at the last WebGL F2F to >> specify the implementation color read format and type. Daniel's point >> about it being legal to change depending on what precise framebuffer >> is bound is a good one. I propose removing the text from the WebGL >> spec hardcoding the implementation read format and type. >> >> -Ken >> >> On Mon, Nov 1, 2010 at 12:04 PM, Daniel Koch >> wrote: >>> Not that this exactly answers your question, but it is worth noting >>> that the >>> GLES2 implementation-defined format is actually >>> framebuffer-dependent, and >>> thus may not always be the same. >>> Quoting from page 103 of the ES 2.0 spec: >>> The values of format and type for this format may be determined by >>> calling >>> GetIntegerv with the symbolic constants >>> IMPLEMENTATION_COLOR_READ_FORMAT and >>> IMPLEMENTATION_- COLOR_READ_TYPE, respectively. The >>> implementation-chosen >>> format may vary depending on the format of the currently bound >>> rendering >>> surface. >>> Daniel >>> On 2010-11-01, at 1:47 PM, Gregg Tavares (wrk) wrote: >>> >>> OpenGL ES 2.0 specifically only allows readpixels to work with 2 >>> formats. >>> 1: RGBA / UNSIGNED_BYTE >>> 2: Implementation defined RGB or RGBA format >>> I'm just guessing but the only reason for the second format is it's >>> the "no >>> conversion" path. In other words, if the hardware is rendering to >>> 4_4_4_4 >>> the second format on that implementation will be RGBA / >>> UNSIGNED_SHORT_4_4_4_4 since no conversion = no memory needed + >>> fast. >>> WebGL on the other hand is currently speced as requiring the second >>> format >>> to be RGB / UNSIGNED_SHORT_5_6_5 so that the second format is >>> consistent >>> across browsers. >>> The question I have is why even support a second format in WebGL? If >>> the >>> only reason for the existence of a second format is to avoid >>> conversion and >>> get speed then requiring a specific format in WebGL defeats that >>> goal. A >>> WebGL implementation will have to query if 5_6_5 is supported and if >>> not do >>> the conversion removing all the speed and memory benefits. >>> With that benefit removed why not just change the WebGL spec only >>> support >>> RGBA / UNSIGNED_BYTE as a readpixels format? >>> >>> --- >>> Daniel Koch -+- daniel...@ >>> Senior Graphics Architect -+- TransGaming Inc. -+- >>> www.transgaming.com >>> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Tue Nov 2 02:29:04 2010 From: cal...@ (Mark Callow) Date: Tue, 02 Nov 2010 18:29:04 +0900 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: <4CCFD142.7070802@opera.com> References: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> <4CCFD142.7070802@opera.com> Message-ID: <4CCFD9E0.2070904@hicorp.co.jp> I agree with Tim. FWIW the most common implementation read format, when reading from the default framebuffer, is RGB565, which is why it was chosen for WebGL. When reading from FBOs it is probably whatever format the renderbuffer is, i.e. it will be dependent on both application and implementation. Regards -Mark On 02/11/2010 17:52, Tim Johansson wrote: > On 2010-11-01 21:09, Vladimir Vukicevic wrote: >> Ah, I didn't realize that it could vary based on the bound framebuffer. >> >> It was suggested that we fix the type because it was an odd >> implementation-specific variance that wasn't covered by an extension >> that could be queried. But that made sense when we weren't thinking >> of it as framebuffer-specific; since it does vary, then I agree that >> it doesn't make sense to fix it (since most everything with fbos is >> implementation-dependant anyway!). Happy to change them back. >> > If we want to change it I would prefer dropping implementation > dependent read format and either only support RGBA8888 or require > software conversion to support any format. > > our email: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From kbr...@ Tue Nov 2 11:29:05 2010 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Nov 2010 11:29:05 -0700 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: <4CCFD9E0.2070904@hicorp.co.jp> References: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> <4CCFD142.7070802@opera.com> <4CCFD9E0.2070904@hicorp.co.jp> Message-ID: I doubt that any serious incompatibilities would be introduced by leaving in the support for the implementation color read format and type, or even having different browsers return different values on the desktop. Existing OpenGL ES 2.0 apps on mobile devices seem to achieve good portability. That having been said, upon more thought it seems fine to remove it since RGBA8888 must be supported, and in the spirit of moving the spec toward completion I think we should do so. Any objections? -Ken On Tue, Nov 2, 2010 at 2:29 AM, Mark Callow wrote: > I agree with Tim. > > FWIW the most common implementation read format, when reading from the > default framebuffer, is RGB565, which is why it was chosen for WebGL. When > reading from FBOs it is probably whatever format the renderbuffer is, i.e. > it will be dependent on both application and implementation. > > Regards > > -Mark > > On 02/11/2010 17:52, Tim Johansson wrote: > > On 2010-11-01 21:09, Vladimir Vukicevic wrote: > > Ah, I didn't realize that it could vary based on the bound framebuffer. > > It was suggested that we fix the type because it was an odd > implementation-specific variance that wasn't covered by an extension that > could be queried.? But that made sense when we weren't thinking of it as > framebuffer-specific; since it does vary, then I agree that it doesn't make > sense to fix it (since most everything with fbos is implementation-dependant > anyway!).? Happy to change them back. > > If we want to change it I would prefer dropping implementation dependent > read format and either only support RGBA8888 or require software conversion > to support any format. > > our email: > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Tue Nov 2 11:37:33 2010 From: vla...@ (Vladimir Vukicevic) Date: Tue, 2 Nov 2010 11:37:33 -0700 (PDT) Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: Message-ID: <1122416180.254764.1288723053072.JavaMail.root@cm-mail03.mozilla.org> To removing it outright, and leaving RGBA8888 as the only readpixels format? Not from me. I can't think of a situation where 565 readback would be a performance win (for feeding to anything else on the Web API side). - Vlad ----- Original Message ----- > I doubt that any serious incompatibilities would be introduced by > leaving in the support for the implementation color read format and > type, or even having different browsers return different values on the > desktop. Existing OpenGL ES 2.0 apps on mobile devices seem to achieve > good portability. > > That having been said, upon more thought it seems fine to remove it > since RGBA8888 must be supported, and in the spirit of moving the spec > toward completion I think we should do so. Any objections? > > -Ken > > On Tue, Nov 2, 2010 at 2:29 AM, Mark Callow > wrote: > > I agree with Tim. > > > > FWIW the most common implementation read format, when reading from > > the > > default framebuffer, is RGB565, which is why it was chosen for > > WebGL. When > > reading from FBOs it is probably whatever format the renderbuffer > > is, i.e. > > it will be dependent on both application and implementation. > > > > Regards > > > > -Mark > > > > On 02/11/2010 17:52, Tim Johansson wrote: > > > > On 2010-11-01 21:09, Vladimir Vukicevic wrote: > > > > Ah, I didn't realize that it could vary based on the bound > > framebuffer. > > > > It was suggested that we fix the type because it was an odd > > implementation-specific variance that wasn't covered by an extension > > that > > could be queried. But that made sense when we weren't thinking of it > > as > > framebuffer-specific; since it does vary, then I agree that it > > doesn't make > > sense to fix it (since most everything with fbos is > > implementation-dependant > > anyway!). Happy to change them back. > > > > If we want to change it I would prefer dropping implementation > > dependent > > read format and either only support RGBA8888 or require software > > conversion > > to support any format. > > > > our email: > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Tue Nov 2 12:04:59 2010 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Nov 2010 12:04:59 -0700 Subject: [Public WebGL] Proposed clarification in spec section 6.3 Framebuffer Object Attachments In-Reply-To: References: <1601993758.223153.1288377299877.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Thanks for the feedback. Section has been updated; please send any comments to the list. -Ken On Mon, Nov 1, 2010 at 6:59 AM, Mo, Zhenyao wrote: > Add two more: copyTexImage2D and copyTexSubImage2D. > > Mo > > On Fri, Oct 29, 2010 at 11:34 AM, Benoit Jacob wrote: >> Hi, >> >> In section 6.3 we say that in case of conflicting attachments, "Calls which modify the framebuffer such as clear and drawArrays must generate an INVALID_FRAMEBUFFER_OPERATION error, and leave the contents of the framebuffer untouched." >> >> I suggest to replace "which modify" by "which access" and to list explicitly all four (I believe) such functions: >> ?clear() >> ?drawArrays() >> ?drawElements() >> ?readPixels() >> >> Indeed, in OpenGL, glReadPixels is generating INVALID_FRAMEBUFFER_OPERATION on incomplete framebuffers, so I guess that this should be no different. >> >> Cheers, >> Benoit >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Tue Nov 2 15:49:14 2010 From: ste...@ (Steve Baker) Date: Tue, 02 Nov 2010 17:49:14 -0500 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: References: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> <4CCFD142.7070802@opera.com> <4CCFD9E0.2070904@hicorp.co.jp> Message-ID: <4CD0956A.9000809@sjbaker.org> I think it would be better to ship with just a single format in the first release of WebGL - we can extend that later - rather than further delay the 1.0 specification. But if we ARE going to ship just one format - it had better be 8/8/8/8 because we don't want to force the API to throw away good data on desktop platforms that support 8/8/8/8 natively. Could we also specify what is put into the low order bits when the format is padded? All Zeroes? Zeroes in RGB and ones in A? The high order bits replicated into the low order bits? (So 0000 => 00000000 and 1111 => 11111111). It definitely makes a difference...and for application developers, not knowing is the biggest problem! -- Steve On 11/02/2010 01:29 PM, Kenneth Russell wrote: > I doubt that any serious incompatibilities would be introduced by > leaving in the support for the implementation color read format and > type, or even having different browsers return different values on the > desktop. Existing OpenGL ES 2.0 apps on mobile devices seem to achieve > good portability. > > That having been said, upon more thought it seems fine to remove it > since RGBA8888 must be supported, and in the spirit of moving the spec > toward completion I think we should do so. Any objections? > > -Ken > > On Tue, Nov 2, 2010 at 2:29 AM, Mark Callow wrote: > >> I agree with Tim. >> >> FWIW the most common implementation read format, when reading from the >> default framebuffer, is RGB565, which is why it was chosen for WebGL. When >> reading from FBOs it is probably whatever format the renderbuffer is, i.e. >> it will be dependent on both application and implementation. >> >> Regards >> >> -Mark >> >> On 02/11/2010 17:52, Tim Johansson wrote: >> >> On 2010-11-01 21:09, Vladimir Vukicevic wrote: >> >> Ah, I didn't realize that it could vary based on the bound framebuffer. >> >> It was suggested that we fix the type because it was an odd >> implementation-specific variance that wasn't covered by an extension that >> could be queried. But that made sense when we weren't thinking of it as >> framebuffer-specific; since it does vary, then I agree that it doesn't make >> sense to fix it (since most everything with fbos is implementation-dependant >> anyway!). Happy to change them back. >> >> If we want to change it I would prefer dropping implementation dependent >> read format and either only support RGBA8888 or require software conversion >> to support any format. >> >> our email: >> >> > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ced...@ Tue Nov 2 17:41:33 2010 From: ced...@ (Cedric Vivier) Date: Wed, 3 Nov 2010 08:41:33 +0800 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: <4CD0956A.9000809@sjbaker.org> References: <1200561564.245220.1288642171735.JavaMail.root@cm-mail03.mozilla.org> <4CCFD142.7070802@opera.com> <4CCFD9E0.2070904@hicorp.co.jp> <4CD0956A.9000809@sjbaker.org> Message-ID: On Wed, Nov 3, 2010 at 06:49, Steve Baker wrote: > I think it would be better to ship with just a single format in the > first release of WebGL - we can extend that later - rather than further > delay the 1.0 specification. > But if we ARE going to ship just one format - it had better be 8/8/8/8 > because we don't want to force the API to throw away good data on > desktop platforms that support 8/8/8/8 natively. +1. Also I don't buy the argument that the current behavior with implementation color read format and type will not introduce unnecessary incompatibilities, we did not include in 1.0 more useful/interesting features for the exact same reasons, we should try to keep consistent about this for a rock-solid 1.0 release. > Could we also specify what is put into the low order bits when the > format is padded? ?All Zeroes? ?Zeroes in RGB and ones in A? ?The high > order bits replicated into the low order bits? (So 0000 => 00000000 and > 1111 => 11111111). ?It definitely makes a difference...and for > application developers, not knowing is the biggest problem! This is already fully defined by ES 2.0 spec (section 4.3). Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Wed Nov 3 11:34:45 2010 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Nov 2010 11:34:45 -0700 Subject: [Public WebGL] Why have readpixels support 5_6_5? In-Reply-To: <1122416180.254764.1288723053072.JavaMail.root@cm-mail03.mozilla.org> References: <1122416180.254764.1288723053072.JavaMail.root@cm-mail03.mozilla.org> Message-ID: IMPLEMENTATION_COLOR_READ_FORMAT and IMPLEMENTATION_COLOR_READ_TYPE have been removed from the WebGL spec and IDL, and the section on differences from OpenGL ES 2.0 updated. -Ken On Tue, Nov 2, 2010 at 11:37 AM, Vladimir Vukicevic wrote: > To removing it outright, and leaving RGBA8888 as the only readpixels format? ?Not from me. ?I can't think of a situation where 565 readback would be a performance win (for feeding to anything else on the Web API side). > > ? ?- Vlad > > ----- Original Message ----- >> I doubt that any serious incompatibilities would be introduced by >> leaving in the support for the implementation color read format and >> type, or even having different browsers return different values on the >> desktop. Existing OpenGL ES 2.0 apps on mobile devices seem to achieve >> good portability. >> >> That having been said, upon more thought it seems fine to remove it >> since RGBA8888 must be supported, and in the spirit of moving the spec >> toward completion I think we should do so. Any objections? >> >> -Ken >> >> On Tue, Nov 2, 2010 at 2:29 AM, Mark Callow >> wrote: >> > I agree with Tim. >> > >> > FWIW the most common implementation read format, when reading from >> > the >> > default framebuffer, is RGB565, which is why it was chosen for >> > WebGL. When >> > reading from FBOs it is probably whatever format the renderbuffer >> > is, i.e. >> > it will be dependent on both application and implementation. >> > >> > Regards >> > >> > -Mark >> > >> > On 02/11/2010 17:52, Tim Johansson wrote: >> > >> > On 2010-11-01 21:09, Vladimir Vukicevic wrote: >> > >> > Ah, I didn't realize that it could vary based on the bound >> > framebuffer. >> > >> > It was suggested that we fix the type because it was an odd >> > implementation-specific variance that wasn't covered by an extension >> > that >> > could be queried. But that made sense when we weren't thinking of it >> > as >> > framebuffer-specific; since it does vary, then I agree that it >> > doesn't make >> > sense to fix it (since most everything with fbos is >> > implementation-dependant >> > anyway!). Happy to change them back. >> > >> > If we want to change it I would prefer dropping implementation >> > dependent >> > read format and either only support RGBA8888 or require software >> > conversion >> > to support any format. >> > >> > our email: >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Wed Nov 3 15:51:45 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Wed, 3 Nov 2010 15:51:45 -0700 Subject: [Public WebGL] WebGL Aquarium demo on Liquid Galaxy Message-ID: You might find this interesting http://www.youtube.com/watch?v=64TcBiqmVko It's the WebGL Aquarium demo running across 8 machines. That particular installation is using Chrome but any browser that supports WebGL and WebWorkers should work. More info here http://webglsamples.googlecode.com/hg/aquarium/README.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Nov 3 16:39:30 2010 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Nov 2010 16:39:30 -0700 Subject: [Public WebGL] stencilFuncSeparate and stencilMaskSeparate Message-ID: The WebGL-specific limitations imposed on stencilFuncSeparate and stencilMaskSeparate in https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#6.5 imply that these entry points are now useless. If it isn't possible to change the front or back reference or mask value to something different than the other, then these entry points can't be used to change those values for either face. Doing so must generate INVALID_OPERATION. stencilFunc and stencilMask must be used instead. Rather than adding useless logic to WebGL implementations (see https://bugs.webkit.org/show_bug.cgi?id=48669), should we just remove these entry points for the time being? -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: From kbr...@ Wed Nov 3 16:41:32 2010 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Nov 2010 16:41:32 -0700 Subject: [Public WebGL] Re: stencilFuncSeparate and stencilMaskSeparate In-Reply-To: References: Message-ID: On Wed, Nov 3, 2010 at 4:39 PM, Kenneth Russell wrote: > The WebGL-specific limitations imposed on stencilFuncSeparate and > stencilMaskSeparate in > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#6.5 > imply that these entry points are now useless. If it isn't possible to > change the front or back reference or mask value to something > different than the other, then these entry points can't be used to > change those values for either face. Doing so must generate > INVALID_OPERATION. stencilFunc and stencilMask must be used instead. > > Rather than adding useless logic to WebGL implementations (see > https://bugs.webkit.org/show_bug.cgi?id=48669), should we just remove > these entry points for the time being? Zhenyao Mo pointed out separately that the func can be different, so it's only stencilMaskSeparate that's completely useless. In that case I suppose we should leave in all of the entry points for symmetry. -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: From vla...@ Wed Nov 3 16:44:38 2010 From: vla...@ (Vladimir Vukicevic) Date: Wed, 3 Nov 2010 16:44:38 -0700 (PDT) Subject: [Public WebGL] stencilFuncSeparate and stencilMaskSeparate In-Reply-To: Message-ID: <111845223.267322.1288827878126.JavaMail.root@cm-mail03.mozilla.org> Hmm, I'd rather keep them in, in case extensions end up layering back some of the removed functionality. We've generally left API entry points alone (e.g. hint()), no? - Vlad ----- Original Message ----- > The WebGL-specific limitations imposed on stencilFuncSeparate and > stencilMaskSeparate in > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#6.5 > imply that these entry points are now useless. If it isn't possible to > change the front or back reference or mask value to something > different than the other, then these entry points can't be used to > change those values for either face. Doing so must generate > INVALID_OPERATION. stencilFunc and stencilMask must be used instead. > > Rather than adding useless logic to WebGL implementations (see > https://bugs.webkit.org/show_bug.cgi?id=48669), should we just remove > these entry points for the time being? > > -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: ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Wed Nov 3 16:53:37 2010 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Nov 2010 16:53:37 -0700 Subject: [Public WebGL] stencilFuncSeparate and stencilMaskSeparate In-Reply-To: <111845223.267322.1288827878126.JavaMail.root@cm-mail03.mozilla.org> References: <111845223.267322.1288827878126.JavaMail.root@cm-mail03.mozilla.org> Message-ID: We just removed (enums) IMPLEMENTATION_COLOR_READ_FORMAT and TYPE, but per my other email I realize that only one of the three entry points is currently useless, so never mind. -Ken On Wed, Nov 3, 2010 at 4:44 PM, Vladimir Vukicevic wrote: > Hmm, I'd rather keep them in, in case extensions end up layering back some of the removed functionality. ?We've generally left API entry points alone (e.g. hint()), no? > > ? ?- Vlad > > ----- Original Message ----- >> The WebGL-specific limitations imposed on stencilFuncSeparate and >> stencilMaskSeparate in >> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html#6.5 >> imply that these entry points are now useless. If it isn't possible to >> change the front or back reference or mask value to something >> different than the other, then these entry points can't be used to >> change those values for either face. Doing so must generate >> INVALID_OPERATION. stencilFunc and stencilMask must be used instead. >> >> Rather than adding useless logic to WebGL implementations (see >> https://bugs.webkit.org/show_bug.cgi?id=48669), should we just remove >> these entry points for the time being? >> >> -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: > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Wed Nov 3 19:11:19 2010 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Nov 2010 19:11:19 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CA50820.8070303@sjbaker.org> References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker wrote: > Gregg Tavares (wrk) wrote: >> >> >> On Wed, Sep 29, 2010 at 5:50 PM, Chris Marrin > > wrote: >> >> >> ? ? On Sep 29, 2010, at 2:37 PM, Gregg Tavares (wrk) wrote: >> >> ? ? > >> ? ? > >> ? ? > ...And I assume that when that's done an implicit transform is >> ? ? applied to make it look to the user like the canvas is the >> ? ? requested size? That's what I suggested in the first place, but it >> ? ? was pointed out that hiding the actual size from the author like >> ? ? that is not really possible. Canvas 2D doesn't have concepts like >> ? ? viewport, which are not affected by transforms. And WebGL doesn't >> ? ? have an overarching transform that is applied to everything. I >> ? ? don't see how you can have a drawing buffer that is not the >> ? ? requested size without the rendering coming out all wrong. If so, >> ? ? you're not helping the author by doing things behind his back. >> ? ? > >> ? ? > For 99% of WebGL apps they should be using canvas.clientWidth >> ? ? and canvas.clientHeight as the dimensions for computing rendering >> ? ? aspect. Those will always be correct regardless of the backbuffer >> ? ? size. >> >> ? ? I don't understand what you mean. clientHeight and clientWidth are >> ? ? the size in pixels of the canvas image on the page, which has >> ? ? nothing to do with the size of the drawing buffer. I believe there >> ? ? will be many uses for WebGL where the drawing buffer size is >> ? ? different from the client size for performance, etc. >> >> >> Most WebGL apps call a function modeled after gluPerspective >> to >> compute a perspective projection matrix and set the aspect ratio such >> that their images show up with the correct aspect. The correct aspect >> ratio to pass in is canvas.clientWidth / canvas.clientHeight. ?It is >> NOT canvas.width / canvas.height. The aspect ratio that needs to be >> passed in is the size at which the result will be displayed, not the >> size it's rendered. The size that it's rendered is rarely relevant to >> anything in a WebGL app except for rendering quality. > There are some very specific algorithms (like screen-space ambient > occlusion, for example) that really require you to know the true screen > resolution. ?I don't think it matters that you don't get the resolution > you asked for so long as you can always find out what the resolution you > have is. > > Traditional fixed-function pipeline OpenGL applications do indeed use a > projection matrix - which you could possibly intercept and modify if > that helped - but with the advent of vertex shaders, all bets are off > and applications can send whatever matrices they like however they like > - so there is no longer a single place to change that. ?But the viewport > and scissor commands are the ones you'd need to be careful with. > > I'd still prefer a system where we explicitly say that the context > dimensions you ask for are merely suggestions from the application (just > like the stencil and depth buffer precisions) - which the browser may > choose to ignore, making the actual resolution either larger or smaller > - and hence, applications should ALWAYS query the system to find out > what resolution they actually have. Apologies for the delay getting back to this, but the WebGL working group strongly wants to resolve this issue. As I understand it the viable options when setting the canvas's width or height to a value unsupportable by the underlying OpenGL implementation appear to be: 1. Make the largest supported backing store, and stretch it to fit the canvas's area on the web page. Add an API to WebGLRenderingContext, "long[] getDrawingBufferSize()", returning the actual width and height of the backing store. 2. Set a synchronous error condition on the canvas which can be checked via a new API such as "boolean isDrawingBufferValid()". Draw calls either raise an error or are ignored. 3. Raise a WebGL context lost event when the canvas is resized too large, and a context restored event when it is shrunk back to a supported size. At this point I continue to believe that (1) is the best option for web developers. Naive developers will get mostly correct results, which based on discussion with Tab Atkins are better than no results. I would no longer advocate (3) as it is too complex to handle. Raising an exception from the setting of canvas.width or canvas.height does not seem to be a viable option as it changes the semantics of these attributes. I propose that we update the spec to indicate that WebGL implementations do (1). Please send any comments to the list. -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: From ste...@ Wed Nov 3 22:00:14 2010 From: ste...@ (Steve Baker) Date: Thu, 04 Nov 2010 00:00:14 -0500 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: <4CD23DDE.5030203@sjbaker.org> On 11/03/2010 09:11 PM, Kenneth Russell wrote: > 1. Make the largest supported backing store, and stretch it to fit the > canvas's area on the web page. Add an API to WebGLRenderingContext, > "long[] getDrawingBufferSize()", returning the actual width and height > of the backing store. > > 2. Set a synchronous error condition on the canvas which can be > checked via a new API such as "boolean isDrawingBufferValid()". Draw > calls either raise an error or are ignored. > > 3. Raise a WebGL context lost event when the canvas is resized too > large, and a context restored event when it is shrunk back to a > supported size. > > At this point I continue to believe that (1) is the best option for > web developers. Naive developers will get mostly correct results, > which based on discussion with Tab Atkins are better than no results. > I would no longer advocate (3) as it is too complex to handle. Raising > an exception from the setting of canvas.width or canvas.height does > not seem to be a viable option as it changes the semantics of these > attributes. > > I propose that we update the spec to indicate that WebGL > implementations do (1). Please send any comments to the list. > Excellent! I agree. This way, you are rendering to a smaller surface than you asked for (and you can query the dimensions that you actually got) - and the resulting image will be stretched as necessary (presumably by the compositing software) to make it cover the area you actually asked for. But please, let's not try to automatically compensate with viewport dimensions and such. It should be up to the application to get that right by using the numbers returned by getDrawingBufferSize() Also, can the specification provide a guarantee that the aspect ratio of the reduced surface will be (to within reasonable hardware limits) the same as the application asked for? Some algorithms behave badly with non-square pixels. eg: If I asked for 512k pixels as a 1024x512 rendering buffer - but there were only 320k pixels of storage available - then I should reasonably expect to get back an 800x400 buffer rather than a 640x512 or a 1024x320. -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Wed Nov 3 22:06:47 2010 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Nov 2010 22:06:47 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CD23DDE.5030203@sjbaker.org> References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> <4CD23DDE.5030203@sjbaker.org> Message-ID: On Wed, Nov 3, 2010 at 10:00 PM, Steve Baker wrote: > On 11/03/2010 09:11 PM, Kenneth Russell wrote: >> 1. Make the largest supported backing store, and stretch it to fit the >> canvas's area on the web page. Add an API to WebGLRenderingContext, >> "long[] getDrawingBufferSize()", returning the actual width and height >> of the backing store. >> >> 2. Set a synchronous error condition on the canvas which can be >> checked via a new API such as "boolean isDrawingBufferValid()". Draw >> calls either raise an error or are ignored. >> >> 3. Raise a WebGL context lost event when the canvas is resized too >> large, and a context restored event when it is shrunk back to a >> supported size. >> >> At this point I continue to believe that (1) is the best option for >> web developers. Naive developers will get mostly correct results, >> which based on discussion with Tab Atkins are better than no results. >> I would no longer advocate (3) as it is too complex to handle. Raising >> an exception from the setting of canvas.width or canvas.height does >> not seem to be a viable option as it changes the semantics of these >> attributes. >> >> I propose that we update the spec to indicate that WebGL >> implementations do (1). Please send any comments to the list. >> > Excellent! ? I agree. > > This way, you are rendering to a smaller surface than you asked for (and > you can query the dimensions that you actually got) - and the resulting > image will be stretched as necessary (presumably by the compositing > software) to make it cover the area you actually asked for. ?But please, > let's not try to automatically compensate with viewport dimensions and > such. ?It should be up to the application to get that right by using the > numbers returned by getDrawingBufferSize() > > Also, can the specification provide a guarantee that the aspect ratio of > the reduced surface will be (to within reasonable hardware limits) the > same as the application asked for? ?Some algorithms behave badly with > non-square pixels. > > eg: If I asked for 512k pixels as a 1024x512 rendering buffer - but > there were only 320k pixels of storage available - then I should > reasonably expect to get back an 800x400 buffer rather than a 640x512 or > a 1024x320. How would you define "reasonable hardware limits"? Having one dimension be off by no more than one or two pixels from the ideal, potentially fractional, value when preserving the aspect ratio? Off by no more than a certain percentage? What about pathological cases of very wide or very tall canvases? I think we should keep it simple. No guarantees about preservation of aspect ratio. If the app wants to do the right thing, the app should query both getDrawingBufferSize and canvas.clientWidth/clientHeight depending on the values needed. -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: From ced...@ Wed Nov 3 23:17:40 2010 From: ced...@ (Cedric Vivier) Date: Thu, 4 Nov 2010 14:17:40 +0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: On Thu, Nov 4, 2010 at 10:11, Kenneth Russell wrote: > On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker wrote: > 1. Make the largest supported backing store, and stretch it to fit the > canvas's area on the web page. Add an API to WebGLRenderingContext, > "long[] getDrawingBufferSize()", returning the actual width and height > of the backing store. I'm not sure I like this approach, this is a bit too implicit imho. Setting or manipulating any variables/arguments related to drawing buffer dimensions (viewport, scissor, readPixels) would then need to use the values returned by this new function to give correct behavior in all cases. However it is highly unlikely imho that most developers would use it this new function everywhere it would be need for consistent behavior in case of downsizing. Indeed, canvas.width and canvas.height are the most intuitive/easiest/straightforward/canvas2d-like way to do it and not using this new function would never show any issue except in the rare(?) cases when the WebGL implementation has to downsize the backing store. IMHO backing store resizing should be an implementation detail that the developer does not have to think about, I propose another option : 4) At context creation, the WebGL implementation might setup a drawing buffer with different dimensions than the canvas, *provided that the dimensions have the same aspect ratio than the canvas*. Internally, the scale ratio (1.0 by default) is used to "correct" width/height input arguments given to viewport, scissor, and readPixels. We might provide a "float getDrawingBufferScale()" API to expose that information, could be useful to load lower resolution textures for instance, however this is not necessary for correct and consistent behavior whether or not the buffer has been scaled... in fact we probably should not expose this information at all. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Thu Nov 4 02:05:19 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 4 Nov 2010 02:05:19 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: On Wed, Nov 3, 2010 at 11:17 PM, Cedric Vivier wrote: > On Thu, Nov 4, 2010 at 10:11, Kenneth Russell wrote: > > On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker wrote: > > 1. Make the largest supported backing store, and stretch it to fit the > > canvas's area on the web page. Add an API to WebGLRenderingContext, > > "long[] getDrawingBufferSize()", returning the actual width and height > > of the backing store. > > I'm not sure I like this approach, this is a bit too implicit imho. > Setting or manipulating any variables/arguments related to drawing > buffer dimensions (viewport, scissor, readPixels) would then need to > use the values returned by this new function to give correct behavior > in all cases. > However it is highly unlikely imho that most developers would use it > this new function everywhere it would be need for consistent behavior > in case of downsizing. Indeed, canvas.width and canvas.height are the > most intuitive/easiest/straightforward/canvas2d-like way to do it and > not using this new function would never show any issue except in the > rare(?) cases when the WebGL implementation has to downsize the > backing store. > > IMHO backing store resizing should be an implementation detail that > the developer does not have to think about, I propose another option : > > 4) At context creation, the WebGL implementation might setup a drawing > buffer with different dimensions than the canvas, *provided that the > dimensions have the same aspect ratio than the canvas*. > Internally, the scale ratio (1.0 by default) is used to "correct" > width/height input arguments given to viewport, scissor, and > readPixels. > If I have a 9 monitor setup and I stretch the window across all 9 1280x1024 monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer? That doesn't seem like the result I want. Most of the time I want the largest resolution I can get. If your app needs a 1.0 scale ratio then query the max backbuffer size and then set the size of the canvas appropriately. Only about 4 of the last 60 3d apps I've written would have needed this. Most of my apps in WebGL pick a fixed backbuffer size and let the canvas scale automatically. It seems like it's better to do the best thing for the majority of apps. Those few apps that need a 1.0 scale ratio can do what they need to force it. > > We might provide a "float getDrawingBufferScale()" API to expose that > information, could be useful to load lower resolution textures for > instance, however this is not necessary for correct and consistent > behavior whether or not the buffer has been scaled... in fact we > probably should not expose this information at all. > > Regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Thu Nov 4 04:31:22 2010 From: jda...@ (John Davis) Date: Thu, 4 Nov 2010 06:31:22 -0500 Subject: [Public WebGL] Chrome WebGL Message-ID: Is there a hard coded limit on the frame rate? Or is it simply a function of the timer frequency in the web page and the underlying GPU? If there is a hard coded limit, can we pleeze make it something like 60-80fps? 30 fps is quite choppy, and doesn't look much better than 3D in a .Net WPF XBAP. Granted, we have shaders, but 30 fps still doesn't look good. Also, are there mailing lists for the specific integrations of WebGL (ie Chrome, Safari, Firefox)? Thanks, JD -------------- next part -------------- An HTML attachment was scrubbed... URL: From rac...@ Thu Nov 4 07:38:02 2010 From: rac...@ (Rachid El Guerrab) Date: Thu, 4 Nov 2010 07:38:02 -0700 Subject: [Public WebGL] Chrome WebGL In-Reply-To: References: Message-ID: John, AFAIK there is no fixed limit on frame-rate. So, as you suggested, It's usually fixed by the rate at which you setup your update events and what's getting rendered. This was true for chrome, webkit nightly and minefield. - Rachid HuE On Nov 4, 2010, at 4:31 AM, John Davis wrote: > Is there a hard coded limit on the frame rate? Or is it simply a function of the timer frequency in the web page and the underlying GPU? If there is a hard coded limit, can we pleeze make it something like 60-80fps? 30 fps is quite choppy, and doesn't look much better than 3D in a .Net WPF XBAP. Granted, we have shaders, but 30 fps still doesn't look good. > > Also, are there mailing lists for the specific integrations of WebGL (ie Chrome, Safari, Firefox)? > > Thanks, > JD > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Thu Nov 4 09:25:14 2010 From: ste...@ (ste...@) Date: Thu, 4 Nov 2010 09:25:14 -0700 Subject: [Public WebGL] Chrome WebGL In-Reply-To: References: Message-ID: <008a04d19cb30e56f7e4d0af04a22998.squirrel@webmail.sjbaker.org> I've certainly had WebGL apps running at close to 60Hz. There may be an issue with getting the frame rate up above that if the browser ties the buffer swap to the vertical retrace signal and your monitor is running at 60Hz. There was also a bug in at least one flavor of JavaScript that limited the minimum amount of time that the 'setTimeout' would operate on - which essentially limited the frame rate. Sadly, I'm a little sketchy on the details - I don't recall which browser it was, what the minimum delay was or whether it ever got fixed. -- Steve > John, > > AFAIK there is no fixed limit on frame-rate. > > So, as you suggested, It's usually fixed by the rate at which you setup > your update events and what's getting rendered. > > This was true for chrome, webkit nightly and minefield. > > - Rachid > HuE > > On Nov 4, 2010, at 4:31 AM, John Davis wrote: > >> Is there a hard coded limit on the frame rate? Or is it simply a >> function of the timer frequency in the web page and the underlying GPU? >> If there is a hard coded limit, can we pleeze make it something like >> 60-80fps? 30 fps is quite choppy, and doesn't look much better than 3D >> in a .Net WPF XBAP. Granted, we have shaders, but 30 fps still doesn't >> look good. >> >> Also, are there mailing lists for the specific integrations of WebGL (ie >> Chrome, Safari, Firefox)? >> >> Thanks, >> JD >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Thu Nov 4 09:50:54 2010 From: ste...@ (ste...@) Date: Thu, 4 Nov 2010 09:50:54 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> <4CD23DDE.5030203@sjbaker.org> Message-ID: <28a3d8874b38fd84274438accebef7c6.squirrel@webmail.sjbaker.org> > On Wed, Nov 3, 2010 at 10:00 PM, Steve Baker wrote: >> On 11/03/2010 09:11 PM, Kenneth Russell wrote: >>> 1. Make the largest supported backing store, and stretch it to fit the >>> canvas's area on the web page. Add an API to WebGLRenderingContext, >>> "long[] getDrawingBufferSize()", returning the actual width and height >>> of the backing store. >>> >>> 2. Set a synchronous error condition on the canvas which can be >>> checked via a new API such as "boolean isDrawingBufferValid()". Draw >>> calls either raise an error or are ignored. >>> >>> 3. Raise a WebGL context lost event when the canvas is resized too >>> large, and a context restored event when it is shrunk back to a >>> supported size. >>> >>> At this point I continue to believe that (1) is the best option for >>> web developers. Naive developers will get mostly correct results, >>> which based on discussion with Tab Atkins are better than no results. >>> I would no longer advocate (3) as it is too complex to handle. Raising >>> an exception from the setting of canvas.width or canvas.height does >>> not seem to be a viable option as it changes the semantics of these >>> attributes. >>> >>> I propose that we update the spec to indicate that WebGL >>> implementations do (1). Please send any comments to the list. >>> >> Excellent! ? I agree. >> >> This way, you are rendering to a smaller surface than you asked for (and >> you can query the dimensions that you actually got) - and the resulting >> image will be stretched as necessary (presumably by the compositing >> software) to make it cover the area you actually asked for. ?But please, >> let's not try to automatically compensate with viewport dimensions and >> such. ?It should be up to the application to get that right by using the >> numbers returned by getDrawingBufferSize() >> >> Also, can the specification provide a guarantee that the aspect ratio of >> the reduced surface will be (to within reasonable hardware limits) the >> same as the application asked for? ?Some algorithms behave badly with >> non-square pixels. >> >> eg: If I asked for 512k pixels as a 1024x512 rendering buffer - but >> there were only 320k pixels of storage available - then I should >> reasonably expect to get back an 800x400 buffer rather than a 640x512 or >> a 1024x320. > > How would you define "reasonable hardware limits"? Having one > dimension be off by no more than one or two pixels from the ideal, > potentially fractional, value when preserving the aspect ratio? Off by > no more than a certain percentage? What about pathological cases of > very wide or very tall canvases? Well, I thought about saying "accurate to the nearest pixel" - but then I wondered whether some hardware might have trouble with (say) windows that are not a multiple of 4 pixels wide. But what I want is "accurate to the nearest pixel" - and I'd be happy to have the spec say that. > I think we should keep it simple. No guarantees about preservation of > aspect ratio. If the app wants to do the right thing, the app should > query both getDrawingBufferSize and canvas.clientWidth/clientHeight > depending on the values needed. But then, we leave ourselves open to bad drivers that when asked for a 1024x512 return you a 1024x32 and stretch it to fill the canvas. Since we can't tolerate that case, all applications are forced to repeatedly try to create canvases of god-knows-what random sizes in an effort to get back something they can live with that won't stretch or squash their data to an unbearable degree. The specification absolutely has to specify some sort of rule as to what the system will do when there isn't enough memory - and since it's going to rescale the render buffer to fit the canvas, preserving the aspect ratio is the rational choice. -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Thu Nov 4 10:09:47 2010 From: ste...@ (ste...@) Date: Thu, 4 Nov 2010 10:09:47 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: > On Wed, Nov 3, 2010 at 11:17 PM, Cedric Vivier wrote: > If I have a 9 monitor setup and I stretch the window across all 9 > 1280x1024 > monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer? > That doesn't seem like the result I want. Most of the time I want the > largest resolution I can get. Well, I guess it depends on WHY the underlying system can't do what you ask. Generally it's because it's out of memory - not because there is some underlying coordinate system limitation preventing the width being more than some number of pixels. That being the case, if (let's say) the system only has 1.2M pixels of backbuffer storage available and you ask for a 11,520 x 1024 - your choices are a 1280x1024 (your preference) or something like a 3840x341 which preserves your aspect ratio. Your way will produce perfectly sharp vertical detail and ungodly horrible 9 pixel long horizontal blurring. My way would produce something a 3x3 isotropic blurring. My result will definitely look better GIVEN THAT the system rescales the backbuffer to fit the canvas, as proposed. If the system would NOT rescale the back buffer to fit the canvas - then maybe I'd agree with you - but that's not what is proposed here. > If your app needs a 1.0 scale ratio then query the max backbuffer size and > then set the size of the canvas appropriately. Only about 4 of the last 60 > 3d apps I've written would have needed this. Most of my apps in WebGL pick > a fixed backbuffer size and let the canvas scale automatically. If you don't get back what you ask for - and if the WebGL specification says nothing about the aspect ratio of what you get back - then I can't imagine any way for an application that wants to minimise the blurring artifacts to guess what to ask for in order to get what it needs. > It seems like it's better to do the best thing for the majority of apps. > Those few apps that need a 1.0 scale ratio can do what they need to force > it. I don't think there are many apps that would prefer a horizontal blur and vertical sharpness (or vice-versa) over a scheme that spreads the blur in both directions equally. In terms of picture quality, it's absolutely no contest! ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Thu Nov 4 10:26:25 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 4 Nov 2010 10:26:25 -0700 Subject: [Public WebGL] Chrome WebGL In-Reply-To: References: Message-ID: I haven't had any problem getting 60hz. There are issues though. Some browsers don't use GPU based compositing. To composite the WebGL image on the page they have to do a glReadPixels to get the image and then use the CPU to composite. Those browsers are generally limited to 20-30hz. Chrome supports GPU based compositing with the switch "--enable-accelerated-compositing". It's still a dev only feature. WebKit on OSX supports GPU compositing. I believe all the other browsers also have work in progress in this direction as well. -g -------------- next part -------------- An HTML attachment was scrubbed... URL: From oli...@ Thu Nov 4 10:43:52 2010 From: oli...@ (Oliver Hunt) Date: Thu, 4 Nov 2010 10:43:52 -0700 Subject: [Public WebGL] Chrome WebGL In-Reply-To: <008a04d19cb30e56f7e4d0af04a22998.squirrel@webmail.sjbaker.org> References: <008a04d19cb30e56f7e4d0af04a22998.squirrel@webmail.sjbaker.org> Message-ID: That "bug" was a deliberate feature of all older browsers, in which they clamped requests to 10ms to prevent websites from clobbering the cpu with 0-delay timeouts. --Oliver On Nov 4, 2010, at 9:25 AM, steve...@ wrote: > I've certainly had WebGL apps running at close to 60Hz. There may be an > issue with getting the frame rate up above that if the browser ties the > buffer swap to the vertical retrace signal and your monitor is running at > 60Hz. > > There was also a bug in at least one flavor of JavaScript that limited the > minimum amount of time that the 'setTimeout' would operate on - which > essentially limited the frame rate. Sadly, I'm a little sketchy on the > details - I don't recall which browser it was, what the minimum delay was > or whether it ever got fixed. > > -- Steve > >> John, >> >> AFAIK there is no fixed limit on frame-rate. >> >> So, as you suggested, It's usually fixed by the rate at which you setup >> your update events and what's getting rendered. >> >> This was true for chrome, webkit nightly and minefield. >> >> - Rachid >> HuE >> >> On Nov 4, 2010, at 4:31 AM, John Davis wrote: >> >>> Is there a hard coded limit on the frame rate? Or is it simply a >>> function of the timer frequency in the web page and the underlying GPU? >>> If there is a hard coded limit, can we pleeze make it something like >>> 60-80fps? 30 fps is quite choppy, and doesn't look much better than 3D >>> in a .Net WPF XBAP. Granted, we have shaders, but 30 fps still doesn't >>> look good. >>> >>> Also, are there mailing lists for the specific integrations of WebGL (ie >>> Chrome, Safari, Firefox)? >>> >>> Thanks, >>> JD >>> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> >> > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Thu Nov 4 10:46:43 2010 From: cma...@ (Chris Marrin) Date: Thu, 04 Nov 2010 10:46:43 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <28a3d8874b38fd84274438accebef7c6.squirrel@webmail.sjbaker.org> References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> <4CD23DDE.5030203@sjbaker.org> Message-ID: On Nov 4, 2010, at 9:50 AM, steve...@ wrote: >> On Wed, Nov 3, 2010 at 10:00 PM, Steve Baker wrote: >>> On 11/03/2010 09:11 PM, Kenneth Russell wrote: >>>> 1. Make the largest supported backing store, and stretch it to fit the >>>> canvas's area on the web page. Add an API to WebGLRenderingContext, >>>> "long[] getDrawingBufferSize()", returning the actual width and height >>>> of the backing store. >>>> >>>> 2. Set a synchronous error condition on the canvas which can be >>>> checked via a new API such as "boolean isDrawingBufferValid()". Draw >>>> calls either raise an error or are ignored. >>>> >>>> 3. Raise a WebGL context lost event when the canvas is resized too >>>> large, and a context restored event when it is shrunk back to a >>>> supported size. >>>> >>>> At this point I continue to believe that (1) is the best option for >>>> web developers. Naive developers will get mostly correct results, >>>> which based on discussion with Tab Atkins are better than no results. >>>> I would no longer advocate (3) as it is too complex to handle. Raising >>>> an exception from the setting of canvas.width or canvas.height does >>>> not seem to be a viable option as it changes the semantics of these >>>> attributes. >>>> >>>> I propose that we update the spec to indicate that WebGL >>>> implementations do (1). Please send any comments to the list. >>>> >>> Excellent! I agree. >>> >>> This way, you are rendering to a smaller surface than you asked for (and >>> you can query the dimensions that you actually got) - and the resulting >>> image will be stretched as necessary (presumably by the compositing >>> software) to make it cover the area you actually asked for. But please, >>> let's not try to automatically compensate with viewport dimensions and >>> such. It should be up to the application to get that right by using the >>> numbers returned by getDrawingBufferSize() >>> >>> Also, can the specification provide a guarantee that the aspect ratio of >>> the reduced surface will be (to within reasonable hardware limits) the >>> same as the application asked for? Some algorithms behave badly with >>> non-square pixels. >>> >>> eg: If I asked for 512k pixels as a 1024x512 rendering buffer - but >>> there were only 320k pixels of storage available - then I should >>> reasonably expect to get back an 800x400 buffer rather than a 640x512 or >>> a 1024x320. >> >> How would you define "reasonable hardware limits"? Having one >> dimension be off by no more than one or two pixels from the ideal, >> potentially fractional, value when preserving the aspect ratio? Off by >> no more than a certain percentage? What about pathological cases of >> very wide or very tall canvases? > > Well, I thought about saying "accurate to the nearest pixel" - but then I > wondered whether some hardware might have trouble with (say) windows that > are not a multiple of 4 pixels wide. But what I want is "accurate to the > nearest pixel" - and I'd be happy to have the spec say that. > >> I think we should keep it simple. No guarantees about preservation of >> aspect ratio. If the app wants to do the right thing, the app should >> query both getDrawingBufferSize and canvas.clientWidth/clientHeight >> depending on the values needed. > > But then, we leave ourselves open to bad drivers that when asked for a > 1024x512 return you a 1024x32 and stretch it to fill the canvas. Since we > can't tolerate that case, all applications are forced to repeatedly try to > create canvases of god-knows-what random sizes in an effort to get back > something they can live with that won't stretch or squash their data to an > unbearable degree. Every graphics library I've used simply lets you select a canvas size and then returns an error if it can't handle that size. You can then ask for it's maximums (which are usually an absolute max width and height) and the resize your canvas as you desire. So it should be pretty easy to state that a canvas that is resized to fit within the maximums must maintain aspect ratio. > > The specification absolutely has to specify some sort of rule as to what > the system will do when there isn't enough memory - and since it's going > to rescale the render buffer to fit the canvas, preserving the aspect > ratio is the rational choice. > > -- Steve > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Thu Nov 4 10:48:57 2010 From: cma...@ (Chris Marrin) Date: Thu, 04 Nov 2010 10:48:57 -0700 Subject: [Public WebGL] Chrome WebGL In-Reply-To: References: Message-ID: <742E6E0C-0FA5-4E47-BACF-F51011E60276@apple.com> On Nov 4, 2010, at 10:26 AM, Gregg Tavares (wrk) wrote: > I haven't had any problem getting 60hz. > > There are issues though. Some browsers don't use GPU based compositing. To composite the WebGL image on the page they have to do a glReadPixels to get the image and then use the CPU to composite. Those browsers are generally limited to 20-30hz. Chrome supports GPU based compositing with the switch "--enable-accelerated-compositing". It's still a dev only feature. WebKit on OSX supports GPU compositing. I believe all the other browsers also have work in progress in this direction as well. WebKit does hardware compositing on Windows as well. Of course WebGL is not there yet, but when it is, it will composite the WebGL canvas. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From bja...@ Thu Nov 4 11:16:02 2010 From: bja...@ (Benoit Jacob) Date: Thu, 4 Nov 2010 11:16:02 -0700 (PDT) Subject: [Public WebGL] Chrome WebGL In-Reply-To: <742E6E0C-0FA5-4E47-BACF-F51011E60276@apple.com> Message-ID: <1921236922.273706.1288894562138.JavaMail.root@cm-mail03.mozilla.org> Minefield does accelerated compositing on all platforms, however: - on Windows, since it's still using OpenGL for WebGL, this doesn't interoperate with the D3D-based compositing. The solution is to use ANGLE instead of OpenGL for WebGL rendering (like Chromium does). - on linux, it's still not on by default, you have to go to about:config and set layers.accelerate-all Benoit ----- Original Message ----- > On Nov 4, 2010, at 10:26 AM, Gregg Tavares (wrk) wrote: > > > I haven't had any problem getting 60hz. > > > > There are issues though. Some browsers don't use GPU based > > compositing. To composite the WebGL image on the page they have to > > do a glReadPixels to get the image and then use the CPU to > > composite. Those browsers are generally limited to 20-30hz. Chrome > > supports GPU based compositing with the switch > > "--enable-accelerated-compositing". It's still a dev only feature. > > WebKit on OSX supports GPU compositing. I believe all the other > > browsers also have work in progress in this direction as well. > > WebKit does hardware compositing on Windows as well. Of course WebGL > is not there yet, but when it is, it will composite the WebGL canvas. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Thu Nov 4 17:13:47 2010 From: kbr...@ (Kenneth Russell) Date: Thu, 4 Nov 2010 17:13:47 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: On Thu, Nov 4, 2010 at 2:05 AM, Gregg Tavares (wrk) wrote: > > > On Wed, Nov 3, 2010 at 11:17 PM, Cedric Vivier wrote: >> >> On Thu, Nov 4, 2010 at 10:11, Kenneth Russell wrote: >> > On Thu, Sep 30, 2010 at 2:58 PM, Steve Baker wrote: >> > 1. Make the largest supported backing store, and stretch it to fit the >> > canvas's area on the web page. Add an API to WebGLRenderingContext, >> > "long[] getDrawingBufferSize()", returning the actual width and height >> > of the backing store. >> >> I'm not sure I like this approach, this is a bit too implicit imho. >> Setting or manipulating any variables/arguments related to drawing >> buffer dimensions (viewport, scissor, readPixels) would then need to >> use the values returned by this new function to give correct behavior >> in all cases. >> However it is highly unlikely imho that most developers would use it >> this new function everywhere it would be need for consistent behavior >> in case of downsizing. Indeed, canvas.width and canvas.height are the >> most intuitive/easiest/straightforward/canvas2d-like way to do it and >> not using this new function would never show any issue except in the >> rare(?) cases when the WebGL implementation has to downsize the >> backing store. >> >> IMHO backing store resizing should be an implementation detail that >> the developer does not have to think about, I propose another option : >> >> 4) At context creation, the WebGL implementation might setup a drawing >> buffer with different dimensions than the canvas, *provided that the >> dimensions have the same aspect ratio than the canvas*. >> Internally, the scale ratio (1.0 by default) is used to "correct" >> width/height input arguments given to viewport, scissor, and >> readPixels. > > If I have a 9 monitor setup and I stretch the window across all 9 1280x1024 > monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer? > That doesn't seem like the result I want. Most of the time I want the > largest resolution I can get. > If your app needs a 1.0 scale ratio then query the max backbuffer size and > then set the size of the canvas appropriately. Only about 4 of the last 60 > 3d apps I've written would have needed this. Most of my apps in WebGL pick a > fixed backbuffer size and let the canvas scale automatically. > It seems like it's better to do the best thing for the majority of apps. > Those few apps that need a 1.0 scale ratio can do what they need to force > it. I agree. The majority of the 3D applications and demos I've written handled resizing the window to arbitrary sizes, and adjusted the projection matrix as necessary. Requiring that the aspect ratio of the canvas's width and height be preserved goes against the OpenGL philosophy that the APIs have as little mechanism behind them as possible. We've adhered to this philosophy in other areas such as not automatically adjusting the viewport when the canvas is resized. >> We might provide a "float getDrawingBufferScale()" API to expose that >> information, could be useful to load lower resolution textures for >> instance, however ?this is not necessary for correct and consistent >> behavior whether or not the buffer has been scaled... in fact we >> probably should not expose this information at all. It is absolutely necessary for certain applications to understand the precise dimensions of the back buffer, for example so they can make correct glViewport calls. -Ken > > >> >> Regards, > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Thu Nov 4 19:41:06 2010 From: cal...@ (Mark Callow) Date: Fri, 05 Nov 2010 11:41:06 +0900 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> Message-ID: <4CD36EC2.10506@hicorp.co.jp> I think this test case or derivations of it should be added to the official test suite. It is generally good practice to add tests which have uncovered previously unseen bugs. Regards -Mark > Thx for helping identify the issue and providing a nice test case > (please don't delete it. At least keep it for a few days, as I used > the link in my bug report). > > Mo > > On Mon, Nov 1, 2010 at 11:16 AM, wrote: >> Yep - it looks fine in the Canary build under Windows with --use-gl=desktop. >> >> Presumably that's the difference though. Under Linux, Chrome is forced to >> use OpenGL because it's the only game in town. If there is no >> destination-alpha bug in Chrome/OpenGL then that explains what I'm seeing. >> >> ... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From ste...@ Thu Nov 4 20:25:11 2010 From: ste...@ (Steve Baker) Date: Thu, 04 Nov 2010 22:25:11 -0500 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CD36EC2.10506@hicorp.co.jp> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> Message-ID: <4CD37917.8060607@sjbaker.org> I should probably simplify it some more first - there is a lot of left-over junk in there...but you're certainly welcome to have it. -- Steve On 11/04/2010 09:41 PM, Mark Callow wrote: > > I think this test case or derivations of it should be added to the > official test suite. It is generally good practice to add tests which > have uncovered previously unseen bugs. > > Regards > > -Mark > > >> Thx for helping identify the issue and providing a nice test case >> (please don't delete it. At least keep it for a few days, as I used >> the link in my bug report). >> >> Mo >> >> On Mon, Nov 1, 2010 at 11:16 AM, wrote: >> >>> Yep - it looks fine in the Canary build under Windows with --use-gl=desktop. >>> >>> Presumably that's the difference though. Under Linux, Chrome is forced to >>> use OpenGL because it's the only game in town. If there is no >>> destination-alpha bug in Chrome/OpenGL then that explains what I'm seeing. >>> >>> ... ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Thu Nov 4 22:34:22 2010 From: cal...@ (Mark Callow) Date: Fri, 05 Nov 2010 14:34:22 +0900 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CD37917.8060607@sjbaker.org> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> Message-ID: <4CD3975E.6040604@hicorp.co.jp> Please. If you can simplify into the form of a test that can drop into the test suite at https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/ that would be even better. Regards -Mark > I should probably simplify it some more first - there is a lot of > left-over junk in there...but you're certainly welcome to have it. > > -- Steve > > > On 11/04/2010 09:41 PM, Mark Callow wrote: >> I think this test case or derivations of it should be added to the >> official test suite. It is generally good practice to add tests which >> have uncovered previously unseen bugs. >> >> Regards >> >> -Mark >> >> >>> Thx for helping identify the issue and providing a nice test case >>> (please don't delete it. At least keep it for a few days, as I used >>> the link in my bug report). >>> >>> Mo >>> >>> On Mon, Nov 1, 2010 at 11:16 AM, wrote: >>> >>>> Yep - it looks fine in the Canary build under Windows with --use-gl=desktop. >>>> >>>> Presumably that's the difference though. Under Linux, Chrome is forced to >>>> use OpenGL because it's the only game in town. If there is no >>>> destination-alpha bug in Chrome/OpenGL then that explains what I'm seeing. >>>> >>>> ... > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From gma...@ Thu Nov 4 23:43:30 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 4 Nov 2010 23:43:30 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CD3975E.6040604@hicorp.co.jp> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> <4CD3975E.6040604@hicorp.co.jp> Message-ID: There is already a test that checks alpha issues with images. https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/gl-teximage.html It can be adapted to run with an RGB backbuffer. That's probably easier than making a new test. I'll do that asap. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Fri Nov 5 03:34:38 2010 From: cal...@ (Mark Callow) Date: Fri, 05 Nov 2010 19:34:38 +0900 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> <4CD3975E.6040604@hicorp.co.jp> Message-ID: <4CD3DDBE.6040206@hicorp.co.jp> But the problem isn't alpha issues with images. It is issues with alpha in compositing with the HTML page which would probably also happen with vertex colors having alpha < 1.0. Regards -Mark > There is already a test that checks alpha issues with images. > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/gl-teximage.html > > It can be adapted to run with an RGB backbuffer. > > That's probably easier than making a new test. > > I'll do that asap. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From ste...@ Fri Nov 5 05:26:40 2010 From: ste...@ (ste...@) Date: Fri, 5 Nov 2010 05:26:40 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CD3DDBE.6040206@hicorp.co.jp> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> <4CD3975E.6040604@hicorp.co.jp> <4CD3DDBE.6040206@hicorp.co.jp> Message-ID: <812d7d3a91f351040741233f36bfc200.squirrel@webmail.sjbaker.org> > But the problem isn't alpha issues with images. It is issues with alpha > in compositing with the HTML page which would probably also happen with > vertex colors having alpha < 1.0. I agree - this has nothing to do with alpha issues in textures or 2D canvasses. It's all to do with destination-alpha rendering contexts and fragment shaders that write alpha<1.0...for whatever reason...not necessarily from texture. There are actually multiple problems that this test is currently highlighting: 1) When you ask for a rendering context WITHOUT destination alpha - do you actually get what you're asking for? (Not currently in Minefield - and the last time I could test it, not in Chrome when it's using ANGLE under Windows. Chrome does seem to get this right for OpenGL rendering contexts.) 2) Does the compositor correctly composite destination-alpha rendering contexts into the HTML page? (Currently, Minefield and Chrome disagree on how this is done for partially transparent pixels - I don't know which of them is correct - I suspect that whether a destination-alpha buffer constitutes a pre-multiplied-alpha canvas is the bone of contention here). 3) When you write an alpha==0.0 pixel from your shader, will the pixel be unconditionally culled (as both Chrome and Minefield do right now) - or will the pixel's Z value be written to the depth buffer and a zero written into the destination alpha plane (as the OpenGL ES 2.0 spec implies - since it doesn't support glAlphaFunc)? -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Fri Nov 5 05:42:29 2010 From: ste...@ (ste...@) Date: Fri, 5 Nov 2010 05:42:29 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CD3975E.6040604@hicorp.co.jp> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> <4CD3975E.6040604@hicorp.co.jp> Message-ID: Sadly, I'm in crunch right now - I don't have a lot of time for at least the next month. But if you're not in a whole lot of hurry, I'd be happy to help. IMHO, it would probably be faster for someone familiar with the test framework to modify one of the existing tests rather than trying to fit my test code into the framework. 1) Change the HTML background to a black/white checkerboard...plain backgrounds make these three bugs hard to spot. 2) Create two rendering contexts - one with destination alpha, the other without. 3) Into each, render a quad with a frag shader that writes 100% red and three distinct regions with alpha=1, alpha=0.5 and alpha=0.0. -- Steve > Please. If you can simplify into the form of a test that can drop into > the test suite at > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/ > > that would be even better. > > Regards > > -Mark > > >> I should probably simplify it some more first - there is a lot of >> left-over junk in there...but you're certainly welcome to have it. >> >> -- Steve >> >> >> On 11/04/2010 09:41 PM, Mark Callow wrote: >>> I think this test case or derivations of it should be added to the >>> official test suite. It is generally good practice to add tests which >>> have uncovered previously unseen bugs. >>> >>> Regards >>> >>> -Mark >>> >>> >>>> Thx for helping identify the issue and providing a nice test case >>>> (ple ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Fri Nov 5 09:28:57 2010 From: cma...@ (Chris Marrin) Date: Fri, 05 Nov 2010 09:28:57 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: <61DA5A47-6A72-48CF-B4F5-D3277BE22D79@apple.com> On Nov 4, 2010, at 5:13 PM, Kenneth Russell wrote: >> ... >> If I have a 9 monitor setup and I stretch the window across all 9 1280x1024 >> monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer? >> That doesn't seem like the result I want. Most of the time I want the >> largest resolution I can get. >> If your app needs a 1.0 scale ratio then query the max backbuffer size and >> then set the size of the canvas appropriately. Only about 4 of the last 60 >> 3d apps I've written would have needed this. Most of my apps in WebGL pick a >> fixed backbuffer size and let the canvas scale automatically. >> It seems like it's better to do the best thing for the majority of apps. >> Those few apps that need a 1.0 scale ratio can do what they need to force >> it. > > I agree. The majority of the 3D applications and demos I've written > handled resizing the window to arbitrary sizes, and adjusted the > projection matrix as necessary. So you're saying you'd have to rewrite every one of those apps using getDrawingBufferScale() to get the correct results, right? I still have not seen a proposal expressed in a clear and concise way. I think we all agree that we can't do this in a way that is completely transparent to the user. Does that mean we want to give the author no automatic behavior? I think giving the author partial help (e.g., "fixing" glViewport params) is worse than giving no help at all. And if we are to do non-square aspect ration changes to the drawing buffer, the we can't have a getDrawingBufferScale() call. So I'll make a simple proposal that upon creation of the drawing buffer we automatically resize dimensions that are too large to the maximum allowable width and height. For instance, a request for a 10,000 x 500 canvas on a machine that has a 2048 pixel dimension limit, we resize to 2048x500. I also propose that we don't change the viewport() call or any other call, we simply provide getCurrentWidth() and getCurrentHeight() calls, or the equivalent. The last question is whether or not there is a call that will tell the author the maximum dimensions of the drawing buffer. There is MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't think there is any guarantee that the window system maximums are reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this value will always give the right answer or create a new call to give the max dimensions. I think the above is sufficient. Most modern graphics cards have a 2k x 2k limit and it will not be very common that a browser user will size their window that big. When they do, the displayed image will not fill the canvas. But that's not a fatal problem. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Fri Nov 5 09:31:15 2010 From: cma...@ (Chris Marrin) Date: Fri, 05 Nov 2010 09:31:15 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <812d7d3a91f351040741233f36bfc200.squirrel@webmail.sjbaker.org> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> <4CD3975E.6040604@hicorp.co.jp> <4CD3DDBE.6040206@hicorp.co.jp> <812d7d3a91f351040741233f36bfc200.squirrel@webmail.sjbaker.org> Message-ID: On Nov 5, 2010, at 5:26 AM, steve...@ wrote: >> But the problem isn't alpha issues with images. It is issues with alpha >> in compositing with the HTML page which would probably also happen with >> vertex colors having alpha < 1.0. > > I agree - this has nothing to do with alpha issues in textures or 2D > canvasses. It's all to do with destination-alpha rendering contexts and > fragment shaders that write alpha<1.0...for whatever reason...not > necessarily from texture. Right, so we may want your test case integrated, or one of the image alpha test modified to test the error you've uncovered, or some combination. But I agree that we don't have such a test right now and we need one. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Fri Nov 5 11:33:22 2010 From: kbr...@ (Kenneth Russell) Date: Fri, 5 Nov 2010 11:33:22 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <61DA5A47-6A72-48CF-B4F5-D3277BE22D79@apple.com> References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> <61DA5A47-6A72-48CF-B4F5-D3277BE22D79@apple.com> Message-ID: On Fri, Nov 5, 2010 at 9:28 AM, Chris Marrin wrote: > > On Nov 4, 2010, at 5:13 PM, Kenneth Russell wrote: > >>> ... >>> If I have a 9 monitor setup and I stretch the window across all 9 1280x1024 >>> monitors and my max back buffer is 2048 then I get a 2048x128 backbuffer? >>> That doesn't seem like the result I want. Most of the time I want the >>> largest resolution I can get. >>> If your app needs a 1.0 scale ratio then query the max backbuffer size and >>> then set the size of the canvas appropriately. Only about 4 of the last 60 >>> 3d apps I've written would have needed this. Most of my apps in WebGL pick a >>> fixed backbuffer size and let the canvas scale automatically. >>> It seems like it's better to do the best thing for the majority of apps. >>> Those few apps that need a 1.0 scale ratio can do what they need to force >>> it. >> >> I agree. The majority of the 3D applications and demos I've written >> handled resizing the window to arbitrary sizes, and adjusted the >> projection matrix as necessary. > > So you're saying you'd have to rewrite every one of those apps using getDrawingBufferScale() to get the correct results, right? Actually, no -- for these apps I'd only need to use canvas.clientWidth / clientHeight. Non-square pixels wouldn't affect the behavior of the app. > I still have not seen a proposal expressed in a clear and concise way. I think we all agree that we can't do this in a way that is completely transparent to the user. Does that mean we want to give the author no automatic behavior? I think giving the author partial help (e.g., "fixing" glViewport params) is worse than giving no help at all. And if we are to do non-square aspect ration changes to the drawing buffer, the we can't have a getDrawingBufferScale() call. > > So I'll make a simple proposal that upon creation of the drawing buffer we automatically resize dimensions that are too large to the maximum allowable width and height. For instance, a request for a 10,000 x 500 canvas on a machine that has a 2048 pixel dimension limit, we resize to 2048x500. I also propose that we don't change the viewport() call or any other call, we simply provide getCurrentWidth() and getCurrentHeight() calls, or the equivalent. Agreed on all counts. > The last question is whether or not there is a call that will tell the author the maximum dimensions of the drawing buffer. There is MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't think there is any guarantee that the window system maximums are reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this value will always give the right answer or create a new call to give the max dimensions. I don't think this is feasible. In certain low memory situations I could imagine that a WebGL implementation might not be able to allocate a backing store texture of the maximum dimensions, or in fact even know what the largest allocatable texture is at the moment without actually trying the allocation since OpenGL ES doesn't have proxy textures. Instead I think the spec should simply state that the dimensions of the back buffer may be clamped to implementation dependent maximums. The getDrawingBufferSize() API may be used to query the allocated size of the drawing buffer. -Ken > I think the above is sufficient. Most modern graphics cards have a 2k x 2k limit and it will not be very common that a browser user will size their window that big. When they do, the displayed image will not fill the canvas. But that's not a fatal problem. > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From tom...@ Fri Nov 5 15:12:45 2010 From: tom...@ (tom...@) Date: Fri, 5 Nov 2010 23:12:45 +0100 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? Message-ID: <1288995165.8512.2.camel@Nokia-N900-02-2> FWIW, I think I'd want canvas resizing to throw an exception if it fails. If there's no explicit error, it'll be easy to think that everything is fine, then later bump into some weird artifacts with no obvious cause. If we let implementations clamp the canvas arbitrarily, then what if the app is trying to create a texture that's too large - would it be OK to clamp that, too? (Sure, that's about creating a new object vs. resizing an existing one, but it's a reasonable analogy nonetheless.) Tomi (via Nokia N900) > On Fri, Nov 5, 2010 at 9:28 AM, Chris Marrin wrote: > > > > On Nov 4, 2010, at 5:13 PM, Kenneth Russell wrote: > > > > > > ... > > > > If I have a 9 monitor setup and I stretch the window across all 9 > 1280x1024 > > > > monitors and my max back buffer is 2048 then I get a 2048x128 > backbuffer? > > > > That doesn't seem like the result I want. Most of the time I want > the > > > > largest resolution I can get. > > > > If your app needs a 1.0 scale ratio then query the max backbuffer > size and > > > > then set the size of the canvas appropriately. Only about 4 of the > last 60 > > > > 3d apps I've written would have needed this. Most of my apps in > WebGL pick a > > > > fixed backbuffer size and let the canvas scale automatically. > > > > It seems like it's better to do the best thing for the majority of > apps. > > > > Those few apps that need a 1.0 scale ratio can do what they need to > force > > > > it. > > > > > > I agree. The majority of the 3D applications and demos I've written > > > handled resizing the window to arbitrary sizes, and adjusted the > > > projection matrix as necessary. > > > > So you're saying you'd have to rewrite every one of those apps using > getDrawingBufferScale() to get the correct results, right? > > Actually, no -- for these apps I'd only need to use canvas.clientWidth > / clientHeight. Non-square pixels wouldn't affect the behavior of the > app. > > > I still have not seen a proposal expressed in a clear and concise way. > I think we all agree that we can't do this in a way that is completely > transparent to the user. Does that mean we want to give the author no > automatic behavior? I think giving the author partial help (e.g., > "fixing" glViewport params) is worse than giving no help at all. And if > we are to do non-square aspect ration changes to the drawing buffer, the > we can't have a getDrawingBufferScale() call. > > > > So I'll make a simple proposal that upon creation of the drawing > buffer we automatically resize dimensions that are too large to the > maximum allowable width and height. For instance, a request for a 10,000 > x 500 canvas on a machine that has a 2048 pixel dimension limit, we > resize to 2048x500. I also propose that we don't change the viewport() > call or any other call, we simply provide getCurrentWidth() and > getCurrentHeight() calls, or the equivalent. > > Agreed on all counts. > > > The last question is whether or not there is a call that will tell the > author the maximum dimensions of the drawing buffer. There is > MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't > think there is any guarantee that the window system maximums are > reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this > value will always give the right answer or create a new call to give the > max dimensions. > > I don't think this is feasible. In certain low memory situations I > could imagine that a WebGL implementation might not be able to > allocate a backing store texture of the maximum dimensions, or in fact > even know what the largest allocatable texture is at the moment > without actually trying the allocation since OpenGL ES doesn't have > proxy textures. > > Instead I think the spec should simply state that the dimensions of > the back buffer may be clamped to implementation dependent maximums. > The getDrawingBufferSize() API may be used to query the allocated size > of the drawing buffer. > > -Ken > > > I think the above is sufficient. Most modern graphics cards have a 2k > x 2k limit and it will not be very common that a browser user will size > their window that big. When they do, the displayed image will not fill > the canvas. But that's not a fatal problem. > > > > ----- > > ~Chris > > cmarrin...@ > > > > > > > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Fri Nov 5 15:30:12 2010 From: kbr...@ (Kenneth Russell) Date: Fri, 5 Nov 2010 15:30:12 -0700 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <1288995165.8512.2.camel@Nokia-N900-02-2> References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: On Fri, Nov 5, 2010 at 3:12 PM, wrote: > FWIW, I think I'd want canvas resizing to throw an exception if it fails. If there's no explicit error, it'll be easy to think that everything is fine, then later bump into some weird artifacts with no obvious cause. As already discussed this option is sub-optimal because then setting of the canvas's width or height attributes would need to throw an exception. For web developers graceful failure seems better than complete failure. > If we let implementations clamp the canvas arbitrarily, then what if the app is trying to create a texture that's too large - would it be OK to clamp that, too? (Sure, that's about creating a new object vs. resizing an existing one, but it's a reasonable analogy nonetheless.) No. The app can retry the texture allocation with a smaller size. There are already some differences in behavior of the default WebGL back buffer compared to user-allocated FBOs -- for example, using multisampling, which can't currently be done for user-allocated FBOs. I don't think having this additional corner case behavior for the default back buffer warrants opening the barn doors to other behavioral changes in the spec. -Ken > ?Tomi (via Nokia N900) > >> On Fri, Nov 5, 2010 at 9:28 AM, Chris Marrin wrote: >> > >> > On Nov 4, 2010, at 5:13 PM, Kenneth Russell wrote: >> > >> > > > ... >> > > > If I have a 9 monitor setup and I stretch the window across all 9 >> 1280x1024 >> > > > monitors and my max back buffer is 2048 then I get a 2048x128 >> backbuffer? >> > > > That doesn't seem like the result I want. Most of the time I want >> the >> > > > largest resolution I can get. >> > > > If your app needs a 1.0 scale ratio then query the max backbuffer >> size and >> > > > then set the size of the canvas appropriately. Only about 4 of the >> last 60 >> > > > 3d apps I've written would have needed this. Most of my apps in >> WebGL pick a >> > > > fixed backbuffer size and let the canvas scale automatically. >> > > > It seems like it's better to do the best thing for the majority of >> apps. >> > > > Those few apps that need a 1.0 scale ratio can do what they need to >> force >> > > > it. >> > > >> > > I agree. The majority of the 3D applications and demos I've written >> > > handled resizing the window to arbitrary sizes, and adjusted the >> > > projection matrix as necessary. >> > >> > So you're saying you'd have to rewrite every one of those apps using >> getDrawingBufferScale() to get the correct results, right? >> >> Actually, no -- for these apps I'd only need to use canvas.clientWidth >> / clientHeight. Non-square pixels wouldn't affect the behavior of the >> app. >> >> > I still have not seen a proposal expressed in a clear and concise way. >> I think we all agree that we can't do this in a way that is completely >> transparent to the user. Does that mean we want to give the author no >> automatic behavior? I think giving the author partial help (e.g., >> "fixing" glViewport params) is worse than giving no help at all. And if >> we are to do non-square aspect ration changes to the drawing buffer, the >> we can't have a getDrawingBufferScale() call. >> > >> > So I'll make a simple proposal that upon creation of the drawing >> buffer we automatically resize dimensions that are too large to the >> maximum allowable width and height. For instance, a request for a 10,000 >> x 500 canvas on a machine that has a 2048 pixel dimension limit, we >> resize to 2048x500. I also propose that we don't change the viewport() >> call or any other call, we simply provide getCurrentWidth() and >> getCurrentHeight() calls, or the equivalent. >> >> Agreed on all counts. >> >> > The last question is whether or not there is a call that will tell the >> author the maximum dimensions of the drawing buffer. There is >> MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't >> think there is any guarantee that the window system maximums are >> reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this >> value will always give the right answer or create a new call to give the >> max dimensions. >> >> I don't think this is feasible. In certain low memory situations I >> could imagine that a WebGL implementation might not be able to >> allocate a backing store texture of the maximum dimensions, or in fact >> even know what the largest allocatable texture is at the moment >> without actually trying the allocation since OpenGL ES doesn't have >> proxy textures. >> >> Instead I think the spec should simply state that the dimensions of >> the back buffer may be clamped to implementation dependent maximums. >> The getDrawingBufferSize() API may be used to query the allocated size >> of the drawing buffer. >> >> -Ken >> >> > I think the above is sufficient. Most modern graphics cards have a 2k >> x 2k limit and it will not be very common that a browser user will size >> their window that big. When they do, the displayed image will not fill >> the canvas. But that's not a fatal problem. >> > >> > ----- >> > ~Chris >> > cmarrin...@ >> > >> > >> > >> > >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Sat Nov 6 00:38:08 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Sat, 6 Nov 2010 00:38:08 -0700 Subject: [Public WebGL] Weird alpha issue. In-Reply-To: <4CD3DDBE.6040206@hicorp.co.jp> References: <1891782920.235028.1288551072750.JavaMail.root@cm-mail03.mozilla.org> <4CCDD960.9070205@sjbaker.org> <98ba53f17926798a82d5d99b687cf8d2.squirrel@webmail.sjbaker.org> <4CD36EC2.10506@hicorp.co.jp> <4CD37917.8060607@sjbaker.org> <4CD3975E.6040604@hicorp.co.jp> <4CD3DDBE.6040206@hicorp.co.jp> Message-ID: On Fri, Nov 5, 2010 at 3:34 AM, Mark Callow wrote: > But the problem isn't alpha issues with images. It is issues with alpha > in compositing with the HTML page which would probably also happen with > vertex colors having alpha < 1.0. > I understand that. the only thing I can do in the test is draw the webgl canvas to a 2d canvas with the right globalCompositingOperation and see that the results are as expected. Of course that's not the same path is just compositing layers in HTML but there's no programmatic way I can check that layering results are correct in a cross browser, cross OS way. So, I will make a test that tests RGB backbuffer pre-multipled RGB backbuffer not-pre-multiplied RGBA backbuffer pre-multiplied RGBA backbuffer not-pre-multiplied using vertex alpha sounds fine. My only point in referencing the gl-teximage.html test is it already has non 0 and non 1 alpha drawing in it so adding drawing the result to a 2d canvas would be easy to add. > Regards > > -Mark > > > There is already a test that checks alpha issues with images. > > > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/gl-teximage.html > > It can be adapted to run with an RGB backbuffer. > > That's probably easier than making a new test. > > I'll do that asap. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ced...@ Sun Nov 7 18:43:09 2010 From: ced...@ (Cedric Vivier) Date: Mon, 8 Nov 2010 10:43:09 +0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <1288995165.8512.2.camel@Nokia-N900-02-2> References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: On Sat, Nov 6, 2010 at 06:12, wrote: > FWIW, I think I'd want canvas resizing to throw an exception if it fails. If there's no explicit error, it'll be easy to think that everything is fine, then later bump into some weird artifacts with no obvious cause. > > If we let implementations clamp the canvas arbitrarily, then what if the app is trying to create a texture that's too large - would it be OK to clamp that, too? (Sure, that's about creating a new object vs. resizing an existing one, but it's a reasonable analogy nonetheless.) If I understood correctly, the proposal is to also resize the back buffer at new context creation (provided the host canvas is large enough), which makes it a very reasonable analogy indeed. I'm not sure how silently resizing a requested 10,000x500 canvas into a 2048x500 will help in most cases, the rendering could be look very different than what it was intended to be, nonwithstanding plenty of other issues that may arise with some calculations, especially in highly interactive WebGL content, because developer likely won't test such aspect ratios. For instance, outside of pure WebGL related issues, such a resize may significantly change how mouse controls work if not taken into account ... typically relative mouse motion/position is given related to canvas dimensions [manually or by libraries such as jQuery]. Even so, handling it might make the application unusable anyways because of the great loss in horizontal precision in rendering. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Mon Nov 8 07:22:15 2010 From: cma...@ (Chris Marrin) Date: Mon, 08 Nov 2010 07:22:15 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1561074246.1142.1285141436615.JavaMail.root@cm-mail03.mozilla.org> <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> Message-ID: <23948CFC-D4FC-4390-9F40-4B2B502A8F20@apple.com> On Nov 5, 2010, at 11:33 AM, Kenneth Russell wrote: >> ...The last question is whether or not there is a call that will tell the author the maximum dimensions of the drawing buffer. There is MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't think there is any guarantee that the window system maximums are reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this value will always give the right answer or create a new call to give the max dimensions. > > I don't think this is feasible. In certain low memory situations I > could imagine that a WebGL implementation might not be able to > allocate a backing store texture of the maximum dimensions, or in fact > even know what the largest allocatable texture is at the moment > without actually trying the allocation since OpenGL ES doesn't have > proxy textures. > > Instead I think the spec should simply state that the dimensions of > the back buffer may be clamped to implementation dependent maximums. > The getDrawingBufferSize() API may be used to query the allocated size > of the drawing buffer. Ok, so an author who wants to have fine control over the drawing buffer size would have to request the desired size and then see that a smaller drawing buffer was allocated. If that size is not good enough, the author can make another attempt at sizing the buffer, hopefully using the returned size as a metric. This could happen over and over as the author tries to find a reasonable buffer size. And the heuristics used might work well on one platform and not on another. I suppose the above scenario is not too bad. But it would be very nice if we could give the author some clue about the buffer size constraints. ----- ~Chris cmarrin...@ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Nov 8 07:24:17 2010 From: cma...@ (Chris Marrin) Date: Mon, 08 Nov 2010 07:24:17 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: On Nov 7, 2010, at 6:43 PM, Cedric Vivier wrote: > On Sat, Nov 6, 2010 at 06:12, wrote: >> FWIW, I think I'd want canvas resizing to throw an exception if it fails. If there's no explicit error, it'll be easy to think that everything is fine, then later bump into some weird artifacts with no obvious cause. >> >> If we let implementations clamp the canvas arbitrarily, then what if the app is trying to create a texture that's too large - would it be OK to clamp that, too? (Sure, that's about creating a new object vs. resizing an existing one, but it's a reasonable analogy nonetheless.) > > If I understood correctly, the proposal is to also resize the back > buffer at new context creation (provided the host canvas is large > enough), which makes it a very reasonable analogy indeed. > > I'm not sure how silently resizing a requested 10,000x500 canvas into > a 2048x500 will help in most cases, the rendering could be look very > different than what it was intended to be, nonwithstanding plenty of > other issues that may arise with some calculations, especially in > highly interactive WebGL content, because developer likely won't test > such aspect ratios. > For instance, outside of pure WebGL related issues, such a resize may > significantly change how mouse controls work if not taken into account > ... typically relative mouse motion/position is given related to > canvas dimensions [manually or by libraries such as jQuery]. Even so, > handling it might make the application unusable anyways because of the > great loss in horizontal precision in rendering. Such a scenario would require the author to realize that the buffer is not the requested size and adapt the code accordingly. I don't think that's a bad scenario. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ced...@ Mon Nov 8 16:52:53 2010 From: ced...@ (Cedric Vivier) Date: Tue, 9 Nov 2010 08:52:53 +0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: On Mon, Nov 8, 2010 at 23:24, Chris Marrin wrote: >> For instance, outside of pure WebGL related issues, such a resize may >> significantly change how mouse controls work if not taken into account >> ... typically relative mouse motion/position is given related to >> canvas dimensions [manually or by libraries such as jQuery]. Even so, >> handling it might make the application unusable anyways because of the >> great loss in horizontal precision in rendering. > > Such a scenario would require the author to realize that the buffer is not the requested size and adapt the code accordingly. I don't think that's a bad scenario. In theory, yes. However I don't find realistic to expect all (or even most) WebGL authors and general-purpose Javascript libraries to complicate their control handling (among other more WebGL-ish concerns) for the unlikely and non-obvious event of back buffer resizing. Even if they try to do so, it might be impossible for some apps to deal in a user-friendly way with such arbitrary loss of precision in only one dimension (eg. a FPS game). I fear that instead of improving user experience, prioritizing "display something at all costs" over "display as developer intended" will give many inconsistent/undesirable results and add burden on all WebGL developers for something that could be better handled on a case-per-case basis as they see fit (including, of course, by WebGL libraries). At worst, this automatic backbuffer downsizing feature should relate to a new member in WebGLContextAttribute so that it can be disabled and overridden by other mechanisms. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Mon Nov 8 17:14:13 2010 From: kbr...@ (Kenneth Russell) Date: Mon, 8 Nov 2010 17:14:13 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: On Mon, Nov 8, 2010 at 4:52 PM, Cedric Vivier wrote: > On Mon, Nov 8, 2010 at 23:24, Chris Marrin wrote: >>> For instance, outside of pure WebGL related issues, such a resize may >>> significantly change how mouse controls work if not taken into account >>> ... typically relative mouse motion/position is given related to >>> canvas dimensions [manually or by libraries such as jQuery]. Even so, >>> handling it might make the application unusable anyways because of the >>> great loss in horizontal precision in rendering. >> >> Such a scenario would require the author to realize that the buffer is not the requested size and adapt the code accordingly. I don't think that's a bad scenario. > > In theory, yes. However I don't find realistic to expect all (or even > most) WebGL authors and general-purpose Javascript libraries to > complicate their control handling (among other more WebGL-ish > concerns) for the unlikely and non-obvious event of back buffer > resizing. Even if they try to do so, it might be impossible for some > apps to deal in a user-friendly way with such arbitrary loss of > precision in only one dimension (eg. a FPS game). > > I fear that instead of improving user experience, prioritizing > "display something at all costs" over "display as developer intended" > will give many inconsistent/undesirable results and add burden on all > WebGL developers for something that could be better handled on a > case-per-case basis as they see fit (including, of course, by WebGL > libraries). > > At worst, this automatic backbuffer downsizing feature should relate > to a new member in WebGLContextAttribute so that it can be disabled > and overridden by other mechanisms. Cedric, We are talking about an error condition here, where the WebGL implementation simply can not honor the requested size that was requested by the developer. Providing an option to change the behavior in this error condition between being handled automatically and being a synchronous error condition is far worse than choosing one of those two behaviors and being consistent. Your earlier assertion that we should handle this condition automatically but preserve the aspect ratio of the canvas is inconsistent with your assertion that the behavior should optionally synchronously generate an error condition. I continue to agree with Tab Atkins, who works on the Canvas spec and has extensive experience developing Web APIs, that it is better to display some content than no content. I also believe that in this error condition the implementation should perform the semantically simplest adjustment to the back buffer size possible: clamping to implementation-defined maximums. We need to resolve this issue quickly to get the spec to version 1.0. I hope that you will agree with me that the behavior I've outlined above is acceptable. -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: From cal...@ Mon Nov 8 20:01:01 2010 From: cal...@ (Mark Callow) Date: Tue, 09 Nov 2010 13:01:01 +0900 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <61DA5A47-6A72-48CF-B4F5-D3277BE22D79@apple.com> References: <27872E4C-B753-4DAC-8353-BFC3D74739D2@apple.com> <4C9D395A.50200@sjbaker.org> <7ED78BBF-6DD3-45B1-978E-0FFDA5856695@apple.com> <29C16266-C657-4CB6-9B01-CFD9B2DD8A61@apple.com> <34C909B2-D7A1-4983-A79F-99D322F2AC17@apple.com> <4CA50820.8070303@sjbaker.org> <61DA5A47-6A72-48CF-B4F5-D3277BE22D79@apple.com> Message-ID: <4CD8C77D.5020208@hicorp.co.jp> On 06/11/2010 01:28, Chris Marrin wrote: > > > The last question is whether or not there is a call that will tell the author the maximum dimensions of the drawing buffer. There is MAX_VIEWPORT_DIMS which will probably give the right answer. But I don't think there is any guarantee that the window system maximums are reflected in MAX_VIEWPORT_DIMS. So we should either clarify that this value will always give the right answer or create a new call to give the max dimensions. The OpenGL ES 2.0 spec. says "The maximum viewport dimensions must be greater than or equal to the visible dimensions of the display being rendered to." so the window system maximums are supposed to be reflected in this MAX_VIEWPORT_DIMS. However it does not seem relevant in this case as the browsers are not using window surfaces. They are using FBOs. If the browser is rendering into a renderbuffer, then MAX_RENDERBUFFER_SIZE will govern. The minimum requirement is only 1x1. If its rendering to a texture then MAX_TEXTURE_SIZE will govern. It's minimum requirement is 64x64. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From cal...@ Mon Nov 8 20:17:28 2010 From: cal...@ (Mark Callow) Date: Tue, 09 Nov 2010 13:17:28 +0900 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: <4CD8CB58.8070108@hicorp.co.jp> I, for one, am not prepared to sign off on something like this based on what feels like a very sketchy description and no explanation of how an application is supposed to handle this situation. Furthermore I share Cedric's concern that most authors will not handle it. In native GL app's I let my resize event handler deal with resizing things to whatever size the window system or user has permitted. If I understand correctly, in the WebGL case the resize events are based on the canvas size, therefore special handling is needed for this error condition. How exactly does the application handle the condition. I am already having a hard time achieving what I'd like to do regarding canvas size due to having to specify the size in pixels - an insane idea given the wide variety of displays we have to deal with. Regards -Mark On 09/11/2010 10:14, Kenneth Russell wrote: > We need to resolve this issue quickly to get the spec to version 1.0. > I hope that you will agree with me that the behavior I've outlined > above is acceptable. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From gma...@ Mon Nov 8 22:18:00 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 8 Nov 2010 22:18:00 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CD8CB58.8070108@hicorp.co.jp> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> Message-ID: On Mon, Nov 8, 2010 at 8:17 PM, Mark Callow wrote: > I, for one, am not prepared to sign off on something like this based on > what feels like a very sketchy description and no explanation of how an > application is supposed to handle this situation. Furthermore I share > Cedric's concern that most authors will not handle it. > I'm not sure what you mean by "not handle it". As opposed to what? They are not handling it now and so when their canvas gets stretched too large their app crashes (throw an exception) They didn't handle it. The only recourse the user has is to resize the window smaller and refresh the webpage. Of course a user won't know to make the window smaller so they'll hit refresh, the app will fail to make a canvas at all the app will most likely not handle that case either and print "WebGL not supported" Vs our suggestion. The app continues to function. Sure there might be some rendering issues but at least it hasn't crashed. Most likely the user can save their work/game whatever and then complain to the author later that their app needs work. So right now we have 2 options on the table. 1) Leave it as is. App gets an exception or lost context or something along those lines. Most apps won't handle this and will effectively stop functioning until the page is refreshed and even then, only if the user resizes the page small enough 2) Make it as large as possible and stretch. Most apps won't handle this case either but at least they won't stop functioning. The debate here seems to be whether they should shoot for the same aspect ratio as originally requested or not. I'm on the "not" side. Are you suggesting some 3rd alternative? > In native GL app's I let my resize event handler deal with resizing > things to whatever size the window system or user has permitted. If I > understand correctly, in the WebGL case the resize events are based on the > canvas size, therefore special handling is needed for this error condition. > How exactly does the application handle the condition. > I am already having a hard time achieving what I'd like to do regarding > canvas size due to having to specify the size in pixels - an insane idea > given the wide variety of displays we have to deal with. > > Regards > > -Mark > > > > > > On 09/11/2010 10:14, Kenneth Russell wrote: > > We need to resolve this issue quickly to get the spec to version 1.0. > I hope that you will agree with me that the behavior I've outlined > above is acceptable. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ced...@ Tue Nov 9 01:38:57 2010 From: ced...@ (Cedric Vivier) Date: Tue, 9 Nov 2010 17:38:57 +0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> Message-ID: On Tue, Nov 9, 2010 at 14:18, Gregg Tavares (wrk) wrote: > 1) Leave it as is. App gets an exception or lost context or something along > those lines. Most apps won't handle this and will effectively stop > functioning until the page is refreshed and even then, only if the user > resizes the page small enough A lost context looks good enough to me, especially for 1.0, exactly like we aren't trying to restore context automatically at all cost just for the sake of displaying something. This is a good way to reduce the number of "failure paths", which ultimately helps testability and will increase reliability of WebGL apps in general. > 2) Make it as large as possible and stretch. Most apps won't handle this > case either but at least they won't stop functioning. If you define "functioning" as displaying something that is possibly garbage (eg. Steve's example), then yes. If we define "functioning" as displaying something that looks more or less closely to what was intended AND that can be manipulated (changing aspect ratio and backbuffer dimension does also impact mouse control and/or object picking - not only rendering!), then no, definitely not. > The debate here seems > to be whether they should shoot for the same aspect ratio as originally > requested or not. I'm on the "not" side. Preserving aspect ratio is probably a much safer bet to make this feature more useful than harmful imho (though it still can cause non-rendering related issues). Maybe we should make a test build hardcoded to randomly downsize the backbuffer to arbitrary non aspect-ratio preserving dimensions and see whether or not it breaks current public WebGL content in many non-obvious ways? Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From m.s...@ Tue Nov 9 05:22:41 2010 From: m.s...@ (M.Sirin) Date: Tue, 9 Nov 2010 14:22:41 +0100 Subject: [Public WebGL] Re: Strange behaviour in Firefox In-Reply-To: References: Message-ID: Hi, I think I found the solution: Webgl is obviously having troubles with stuff like vLightWeighting = vec3(0.4,0.4,0.4); or calculation based on these in shader defined values: vLightWeighting = vec3(0.4,0.4,0.4) * otherValues but when I transfer 0.4,0.4,0.4 via an uniform-variable it works fine. So if the values are coming from outside/an uniform there is no problem: vLightWeighting =myVec3UniformShaderValue* otherValues. I don't know why it is like that..maybe it is a common phenomenon that I haven't noticed? 2010/10/30 M.Sirin > Helllo! > > WebGL is trying to draw something via: > > > > > > This is working for Firefox 4.0b6, Minefield 4.0b8pre and Chromium > 9.0.564.0 (63713). But the appearence of the objects is different between > Chromium and Firefox, so i tried to change some lightening calculations like > something simple like this: vLightWeighting = vec3(0.4,0.4,0.4); //just > removed the additional term. Or just doing stuff like > vec3 lightDirection=directionalVector; > > But this is weirdly leading all Firefox versions to that error that I once > had: Nothing is drawn and "UniformMatrix4fv: location: null object passed as > argument" is coming again. Chromium is doing his job properly without such > an error. > > Why the hell such little caculations should cause these ugly stuff? > > I'm going crazy with that... > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ste...@ Tue Nov 9 05:40:47 2010 From: ste...@ (ste...@) Date: Tue, 9 Nov 2010 05:40:47 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> Message-ID: <96d4a3f723de854844ab4f12ef9d3c8b.squirrel@webmail.sjbaker.org> We seem to be arguing between: * Mandatory application-side complexity that's unlikely to be handled correctly by 90% of web sites...or... * Removing application-side flexibility that more advanced applications will need...or... * Adding uncomfortable amounts of complexity into the WebGL specification very late in the game. None of those things are particularly attractive. So maybe the answer here is to keep the spec clean and hide the resulting application-side complexity issues by providing something like the GLUT library for OpenGL. WebGLUT could be small and light-weight and provide inflexible behavior that would be simple to use and understand - and guaranteed "correct". That would achieve the goal of allowing people to use WebGLUT get simple programs up and running that behave reliably and predictably...while letting people with more serious applications have access to harder-to-use-but-more-flexible interfaces at the WebGL level. I know that there are already several 3rd party libraries - but they appear to wrap more than is needed and provide higher level interfaces across the board that most certainly isn't to everyone's tastes. They also don't have the "Khronos seal of approval" thing going for them. If we expect people to use WebGL much like they have historically used OpenGL - then providing a WebGLUT library to handle the ikky stuff makes some kind of sense. If WebGLUT were to be featured in the WebGL programmers' guide (the "Red Book"), then people would be able to get to grips with the more interesting bits of WebGL quickly without having to fight to do the very first step...opening a rendering context. Buried someplace at the back of the book, we could explain the more horrific issues of opening a valid rendering context without using WebGLUT - but if most readers never get that far, then that's OK. -- Steve > On Mon, Nov 8, 2010 at 8:17 PM, Mark Callow > wrote: > >> I, for one, am not prepared to sign off on something like this based on >> what feels like a very sketchy description and no explanation of how an >> application is supposed to handle this situation. Furthermore I share >> Cedric's concern that most authors will not handle it. >> > I'm not sure what you mean by "not handle it". As opposed to what? They > are > not handling it now and so when their canvas gets stretched too large > their > app crashes (throw an exception) They didn't handle it. The only recourse > the user has is to resize the window smaller and refresh the webpage. Of > course a user won't know to make the window smaller so they'll hit > refresh, > the app will fail to make a canvas at all the app will most likely not > handle that case either and print "WebGL not supported" > > Vs our suggestion. The app continues to function. Sure there might be some > rendering issues but at least it hasn't crashed. Most likely the user can > save their work/game whatever and then complain to the author later that > their app needs work. > > So right now we have 2 options on the table. > > 1) Leave it as is. App gets an exception or lost context or something > along > those lines. Most apps won't handle this and will effectively stop > functioning until the page is refreshed and even then, only if the user > resizes the page small enough > > 2) Make it as large as possible and stretch. Most apps won't handle this > case either but at least they won't stop functioning. The debate here > seems > to be whether they should shoot for the same aspect ratio as originally > requested or not. I'm on the "not" side. > > Are you suggesting some 3rd alternative? > > > >> In native GL app's I let my resize event handler deal with resizing >> things to whatever size the window system or user has permitted. If I >> understand correctly, in the WebGL case the resize events are based on >> the >> canvas size, therefore special handling is needed for this error >> condition. >> How exactly does the application handle the condition. >> > I am already having a hard time achieving what I'd like to do regarding >> canvas size due to having to specify the size in pixels - an insane idea >> given the wide variety of displays we have to deal with. >> >> Regards >> >> -Mark >> >> >> >> >> >> On 09/11/2010 10:14, Kenneth Russell wrote: >> >> We need to resolve this issue quickly to get the spec to version 1.0. >> I hope that you will agree with me that the behavior I've outlined >> above is acceptable. >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Tue Nov 9 05:59:32 2010 From: ste...@ (ste...@) Date: Tue, 9 Nov 2010 05:59:32 -0800 Subject: [Public WebGL] Re: Strange behaviour in Firefox In-Reply-To: References: Message-ID: <1b2319ac9ebff71244acfe5daaf19950.squirrel@webmail.sjbaker.org> I don't think your problem can be that simple. I use vector constants like that all the time in literally dozens of shaders, using both Chrome and Firefox - on five different GPU's and under two different OS's, both with and without the validator - and I don't see any problems as a result! If this was really the problem, surely I'd be seeing anomalous results on at least one of those setups...and I'm not. At a guess, I'd say that your JavaScript code for binding and setting the uniforms and/or linking the shader program is broken somehow. Adding more uniforms to replace those constants is re-ordering where the uniforms are bound - and probably shaking up the underlying bug into a different and less obviously harmful pattern. I don't think you've fixed your problem by replacing the vector constants with uniforms...I bet it comes back on some other combination of GPU/OS/browser. -- Steve > Hi, I think I found the solution: > Webgl is obviously having troubles with stuff like > > vLightWeighting = vec3(0.4,0.4,0.4); or calculation based on these in > shader defined values: vLightWeighting = vec3(0.4,0.4,0.4) * otherValues > > but when I transfer 0.4,0.4,0.4 via an uniform-variable it works fine. So > if > the values are coming from outside/an uniform there is no problem: > > vLightWeighting =myVec3UniformShaderValue* otherValues. > > I don't know why it is like that..maybe it is a common phenomenon that I > haven't noticed? > > > > > 2010/10/30 M.Sirin > >> Helllo! >> >> WebGL is trying to draw something via: >> >> >> >> >> >> This is working for Firefox 4.0b6, Minefield 4.0b8pre and Chromium >> 9.0.564.0 (63713). But the appearence of the objects is different >> between >> Chromium and Firefox, so i tried to change some lightening calculations >> like >> something simple like this: vLightWeighting = vec3(0.4,0.4,0.4); //just >> removed the additional term. Or just doing stuff like >> vec3 lightDirection=directionalVector; >> >> But this is weirdly leading all Firefox versions to that error that I >> once >> had: Nothing is drawn and "UniformMatrix4fv: location: null object >> passed as >> argument" is coming again. Chromium is doing his job properly without >> such >> an error. >> >> Why the hell such little caculations should cause these ugly stuff? >> >> I'm going crazy with that... >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ala...@ Tue Nov 9 07:37:58 2010 From: ala...@ (ala...@) Date: Tue, 09 Nov 2010 07:37:58 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> Message-ID: <4CD96AD6.9040700@mechnicality.com> On 11/8/2010 5:14 PM, Kenneth Russell wrote: > > We are talking about an error condition here, where the WebGL > implementation simply can not honor the requested size that was > requested by the developer. > If its an error condition (which I think it probably is) then why not generate an error? Why not make the *specification* require that implementations generate an error condition. If, as policy, the webgl *implementations* try to recover from this by still continuing to display data, resized or scaled as they see fit, that's fine. But maybe that recovery behavior doesn't have to be explicitly defined in the spec. If a developer can't be bothered to ever check and interpret the webgl error status, then they will have an unreliable application. However, the error status is well known, well documented and easy to understand. Regards Alan ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Tue Nov 9 09:23:16 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Tue, 9 Nov 2010 09:23:16 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <96d4a3f723de854844ab4f12ef9d3c8b.squirrel@webmail.sjbaker.org> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> <96d4a3f723de854844ab4f12ef9d3c8b.squirrel@webmail.sjbaker.org> Message-ID: On Tue, Nov 9, 2010 at 5:40 AM, wrote: > We seem to be arguing between: > > * Mandatory application-side complexity that's unlikely to be handled > correctly by 90% of web sites...or... > * Removing application-side flexibility that more advanced applications > will need...or... > No one has suggested removing application side flexibility. > * Adding uncomfortable amounts of complexity into the WebGL specification > very late in the game. > No one has suggested adding uncomfortable amounts of complexity into WebGL > > None of those things are particularly attractive. > > So maybe the answer here is to keep the spec clean and hide the resulting > application-side complexity issues by providing something like the GLUT > library for OpenGL. > > WebGLUT could be small and light-weight and provide inflexible behavior > that would be simple to use and understand - and guaranteed "correct". > That would achieve the goal of allowing people to use WebGLUT get simple > programs up and running that behave reliably and predictably...while > letting people with more serious applications have access to > harder-to-use-but-more-flexible interfaces at the WebGL level. > > I know that there are already several 3rd party libraries - but they > appear to wrap more than is needed and provide higher level interfaces > across the board that most certainly isn't to everyone's tastes. They > also don't have the "Khronos seal of approval" thing going for them. If > we expect people to use WebGL much like they have historically used OpenGL > - then providing a WebGLUT library to handle the ikky stuff makes some > kind of sense. > > If WebGLUT were to be featured in the WebGL programmers' guide (the "Red > Book"), then people would be able to get to grips with the more > interesting bits of WebGL quickly without having to fight to do the very > first step...opening a rendering context. Buried someplace at the back of > the book, we could explain the more horrific issues of opening a valid > rendering context without using WebGLUT - but if most readers never get > that far, then that's OK. > > -- Steve > > > > On Mon, Nov 8, 2010 at 8:17 PM, Mark Callow > > wrote: > > > >> I, for one, am not prepared to sign off on something like this based on > >> what feels like a very sketchy description and no explanation of how an > >> application is supposed to handle this situation. Furthermore I share > >> Cedric's concern that most authors will not handle it. > >> > > I'm not sure what you mean by "not handle it". As opposed to what? They > > are > > not handling it now and so when their canvas gets stretched too large > > their > > app crashes (throw an exception) They didn't handle it. The only recourse > > the user has is to resize the window smaller and refresh the webpage. Of > > course a user won't know to make the window smaller so they'll hit > > refresh, > > the app will fail to make a canvas at all the app will most likely not > > handle that case either and print "WebGL not supported" > > > > Vs our suggestion. The app continues to function. Sure there might be > some > > rendering issues but at least it hasn't crashed. Most likely the user can > > save their work/game whatever and then complain to the author later that > > their app needs work. > > > > So right now we have 2 options on the table. > > > > 1) Leave it as is. App gets an exception or lost context or something > > along > > those lines. Most apps won't handle this and will effectively stop > > functioning until the page is refreshed and even then, only if the user > > resizes the page small enough > > > > 2) Make it as large as possible and stretch. Most apps won't handle this > > case either but at least they won't stop functioning. The debate here > > seems > > to be whether they should shoot for the same aspect ratio as originally > > requested or not. I'm on the "not" side. > > > > Are you suggesting some 3rd alternative? > > > > > > > >> In native GL app's I let my resize event handler deal with resizing > >> things to whatever size the window system or user has permitted. If I > >> understand correctly, in the WebGL case the resize events are based on > >> the > >> canvas size, therefore special handling is needed for this error > >> condition. > >> How exactly does the application handle the condition. > >> > > I am already having a hard time achieving what I'd like to do regarding > >> canvas size due to having to specify the size in pixels - an insane idea > >> given the wide variety of displays we have to deal with. > >> > >> Regards > >> > >> -Mark > >> > >> > >> > >> > >> > >> On 09/11/2010 10:14, Kenneth Russell wrote: > >> > >> We need to resolve this issue quickly to get the spec to version 1.0. > >> I hope that you will agree with me that the behavior I've outlined > >> above is acceptable. > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Nov 9 09:40:36 2010 From: bja...@ (Benoit Jacob) Date: Tue, 9 Nov 2010 09:40:36 -0800 (PST) Subject: [Public WebGL] Re: Strange behaviour in Firefox In-Reply-To: Message-ID: <1275126739.311213.1289324436629.JavaMail.root@cm-mail03.mozilla.org> Hi, Does it make a difference when you go to about:config and set webgl.shader_validator to false? I am thinking that you might be hitting this ANGLE bug (fixed upstream but we havent synced yet): https://bugzilla.mozilla.org/show_bug.cgi?id=594489 In short: if you are using a non-US locale that uses the comma as decimal separator, then ANGLE used to truncate floating point values specified in shaders. The easiest fix would be to replace 0.4 by 4/10. Benoit ----- Original Message ----- Hi, I think I found the solution: Webgl is obviously having troubles with stuff like vLightWeighting = vec3(0.4,0.4,0.4); or calculation based on these in shader defined values: vLightWeighting = vec3(0.4,0.4,0.4) * otherValues but when I transfer 0.4,0.4,0.4 via an uniform-variable it works fine. So if the values are coming from outside/an uniform there is no problem: vLightWeighting =myVec3UniformShaderValue* otherValues. I don't know why it is like that..maybe it is a common phenomenon that I haven't noticed? 2010/10/30 M.Sirin < m.sirin07...@ > Helllo! WebGL is trying to draw something via: This is working for Firefox 4.0b6, Minefield 4.0b8pre and Chromium 9.0.564.0 (63713). But the appearence of the objects is different between Chromium and Firefox, so i tried to change some lightening calculations like something simple like this: vLightWeighting = vec3(0.4,0.4,0.4); //just removed the additional term. Or just doing stuff like vec3 lightDirection=directionalVector; But this is weirdly leading all Firefox versions to that error that I once had: Nothing is drawn and "UniformMatrix4fv: location: null object passed as argument" is coming again. Chromium is doing his job properly without such an error. Why the hell such little caculations should cause these ugly stuff? I'm going crazy with that... -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Tue Nov 9 10:09:44 2010 From: cma...@ (Chris Marrin) Date: Tue, 09 Nov 2010 10:09:44 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <96d4a3f723de854844ab4f12ef9d3c8b.squirrel@webmail.sjbaker.org> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> <96d4a3f723de854844ab4f12ef9d3c8b.squirrel@webmail.sjbaker.org> Message-ID: On Nov 9, 2010, at 5:40 AM, steve...@ wrote: > We seem to be arguing between: > > * Mandatory application-side complexity that's unlikely to be handled > correctly by 90% of web sites...or... > * Removing application-side flexibility that more advanced applications > will need...or... > * Adding uncomfortable amounts of complexity into the WebGL specification > very late in the game. > > None of those things are particularly attractive. > > So maybe the answer here is to keep the spec clean and hide the resulting > application-side complexity issues by providing something like the GLUT > library for OpenGL. > > WebGLUT could be small and light-weight and provide inflexible behavior > that would be simple to use and understand - and guaranteed "correct". > That would achieve the goal of allowing people to use WebGLUT get simple > programs up and running that behave reliably and predictably...while > letting people with more serious applications have access to > harder-to-use-but-more-flexible interfaces at the WebGL level. > > I know that there are already several 3rd party libraries - but they > appear to wrap more than is needed and provide higher level interfaces > across the board that most certainly isn't to everyone's tastes. They > also don't have the "Khronos seal of approval" thing going for them. If > we expect people to use WebGL much like they have historically used OpenGL > - then providing a WebGLUT library to handle the ikky stuff makes some > kind of sense. > > If WebGLUT were to be featured in the WebGL programmers' guide (the "Red > Book"), then people would be able to get to grips with the more > interesting bits of WebGL quickly without having to fight to do the very > first step...opening a rendering context. Buried someplace at the back of > the book, we could explain the more horrific issues of opening a valid > rendering context without using WebGLUT - but if most readers never get That's a fine idea. But we still need to define the exact behavior. You say "keep the spec clean", but what does that mean? What do we do when a request for a too large drawing buffer is made? We have to answer that question to make a "WebGLUT" library, or any library to handle the case is a more clean way. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Tue Nov 9 10:16:10 2010 From: cma...@ (Chris Marrin) Date: Tue, 09 Nov 2010 10:16:10 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> Message-ID: <66EFF98F-C845-4E05-9D64-6A2F8151A721@apple.com> On Nov 9, 2010, at 1:38 AM, Cedric Vivier wrote: > On Tue, Nov 9, 2010 at 14:18, Gregg Tavares (wrk) wrote: >> 1) Leave it as is. App gets an exception or lost context or something along >> those lines. Most apps won't handle this and will effectively stop >> functioning until the page is refreshed and even then, only if the user >> resizes the page small enough > > A lost context looks good enough to me, especially for 1.0, exactly > like we aren't trying to restore context automatically at all cost > just for the sake of displaying something. > This is a good way to reduce the number of "failure paths", which > ultimately helps testability and will increase reliability of WebGL > apps in general. > > >> 2) Make it as large as possible and stretch. Most apps won't handle this >> case either but at least they won't stop functioning. > > If you define "functioning" as displaying something that is possibly > garbage (eg. Steve's example), then yes. > If we define "functioning" as displaying something that looks more or > less closely to what was intended AND that can be manipulated > (changing aspect ratio and backbuffer dimension does also impact mouse > control and/or object picking - not only rendering!), then no, > definitely not. > > >> The debate here seems >> to be whether they should shoot for the same aspect ratio as originally >> requested or not. I'm on the "not" side. > > Preserving aspect ratio is probably a much safer bet to make this > feature more useful than harmful imho (though it still can cause > non-rendering related issues). First of all, let me say that I think the "stretching the window across 9 displays" case is a degenerate case and I don't think we should optimize the solution for it. So the question of preserving aspect ratio or not is a much more minor issue in my mind. Do we agree that attempting to create a drawing buffer that is too large DOES NOT generate an error, but rather creates a drawing buffer that fits within the system constraints, and makes that information known to the author by some sort of getDrawingBufferSize() call? If we can agree on that, we've solved most of the problem. In fact, we could always make the dimensions chosen be platform dependent. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Tue Nov 9 10:34:18 2010 From: cma...@ (Chris Marrin) Date: Tue, 09 Nov 2010 10:34:18 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CD8CB58.8070108@hicorp.co.jp> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> Message-ID: On Nov 8, 2010, at 8:17 PM, Mark Callow wrote: > I, for one, am not prepared to sign off on something like this based on what feels like a very sketchy description and no explanation of how an application is supposed to handle this situation. Furthermore I share Cedric's concern that most authors will not handle it. > > In native GL app's I let my resize event handler deal with resizing things to whatever size the window system or user has permitted. If I understand correctly, in the WebGL case the resize events are based on the canvas size, therefore special handling is needed for this error condition. How exactly does the application handle the condition. There is no resize event for Canvas because sizing it is synchronous. You set the width and height and the canvas is created with those dimensions. For complete handling the author would then have to make the getDrawingBufferDimensions() call and use that for viewport settings, etc. But you bring up a good point. If the author does "canvas.width = 1000; canvas.height = 500;" will the canvas get resized twice? In other words, what are our rules for when the canvas gets resized? Is there a way for us to optimize the sizing? Maybe we could delay resizing the canvas until either the size is queried, or a WebGL call is made. > > I am already having a hard time achieving what I'd like to do regarding canvas size due to having to specify the size in pixels - an insane idea given the wide variety of displays we have to deal with. Huh? This is the way the web works. Mobile devices have had to deal with it from day 1. There are really several choices (from an iOS perspective): 1) The author does nothing and the scaling logic in the web browser kicks in to show the entire page scaled down or zoomed in. In this case you design like you would for a desktop browser and count on the device to scale appropriately. 2) The author specifies the page size in meta tags and writes specifically for the resolution of the device being used. This is less useful nowadays that there are at least 3 screen resolutions of iOS devices. 3) Use media queries and design several layouts in CSS for a variety of sizes. You can also use media queries from JS to change behavior based on various possible layouts. 4) Use window.innerWidth/window.innerHeight to find the current window size. On iOS devices, they are always "full-screen", so this gives you the screen size. It is actually the size inside the chrome. You can get the real screen size with window.outerWidth/window.outerHeight. So there are plenty of tools to deal with the wide variety of mobile devices. Everything but (2) above are also viable design tools for desktop browsers. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Tue Nov 9 11:00:26 2010 From: vla...@ (Vladimir Vukicevic) Date: Tue, 9 Nov 2010 11:00:26 -0800 (PST) Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: Message-ID: <1195112560.312144.1289329226917.JavaMail.root@cm-mail03.mozilla.org> ----- Original Message ----- > On Nov 8, 2010, at 8:17 PM, Mark Callow wrote: > > > I, for one, am not prepared to sign off on something like this based > > on what feels like a very sketchy description and no explanation of > > how an application is supposed to handle this situation. Furthermore > > I share Cedric's concern that most authors will not handle it. > > > > In native GL app's I let my resize event handler deal with resizing > > things to whatever size the window system or user has permitted. If > > I understand correctly, in the WebGL case the resize events are > > based on the canvas size, therefore special handling is needed for > > this error condition. How exactly does the application handle the > > condition. > > There is no resize event for Canvas because sizing it is synchronous. > You set the width and height and the canvas is created with those > dimensions. For complete handling the author would then have to make > the getDrawingBufferDimensions() call and use that for viewport > settings, etc. One common pattern that I can see is: canvas.width = large_value; canvas.height = large_value; cx = canvas.getContext("webgl"); size = cx.getDrawingBufferDimensions(); if (size.width < canvas.width) canvas.width = size.width; if (size.height < canvas.height) canvas.height = size.height; The two .width/.height sets to size.* shouldn't cause a resize (since the backbuffer is already that size), and from that point on the developer can continue to use canvas.width/canvas.height just like they normally would have. (Or just store the right values in local variables, to avoid having to get dom attributes for this!) I think the above is by far the simplest thing to implement, describe, and use. Let's say instead we went with throwing an exception: ok = false; desired_w = large_value; desired_h = large_value; while (!ok) { try { canvas.width = desired_w; canvas.height = desired_h; } catch (e) { // what now? You have no GL context yet, so can't query the viewport dimensions. So.. canvas.width = 1; canvas.height = 1; cx = canvas.getContext("webgl"); new_dim = cx.getParameter(MAX_VIEWPORT_...); if (desired_w == new_dim) { alert("failed"); break; } desired_w = new_dim; desired_h = new_dim; } } That's awful, and has zero advantages that I can see. > But you bring up a good point. If the author does "canvas.width = > 1000; canvas.height = 500;" will the canvas get resized twice? In > other words, what are our rules for when the canvas gets resized? Is > there a way for us to optimize the sizing? Maybe we could delay > resizing the canvas until either the size is queried, or a WebGL call > is made. The canvas unfortunately has to be resized twice. I've sent mail to whatwg that this is really undesirable, and suggested that the canvas element just get a setSize() method that would set both width and height at the same time. One related comment -- I think that we should clamp the canvas back buffer dimensions, *but* for on-screen display we need to scale up to the original requested canvas size, even if it's inefficient. I think this is better than actually changing the physical layout dimensions of the canvas element as well, but I could probably go either way. - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Tue Nov 9 11:46:28 2010 From: cma...@ (Chris Marrin) Date: Tue, 09 Nov 2010 11:46:28 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <1195112560.312144.1289329226917.JavaMail.root@cm-mail03.mozilla.org> References: <1195112560.312144.1289329226917.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <2EF4A6B4-41FF-4571-B6D9-9EA3E544846F@apple.com> On Nov 9, 2010, at 11:00 AM, Vladimir Vukicevic wrote: > > > ----- Original Message ----- >> On Nov 8, 2010, at 8:17 PM, Mark Callow wrote: >> >>> I, for one, am not prepared to sign off on something like this based >>> on what feels like a very sketchy description and no explanation of >>> how an application is supposed to handle this situation. Furthermore >>> I share Cedric's concern that most authors will not handle it. >>> >>> In native GL app's I let my resize event handler deal with resizing >>> things to whatever size the window system or user has permitted. If >>> I understand correctly, in the WebGL case the resize events are >>> based on the canvas size, therefore special handling is needed for >>> this error condition. How exactly does the application handle the >>> condition. >> >> There is no resize event for Canvas because sizing it is synchronous. >> You set the width and height and the canvas is created with those >> dimensions. For complete handling the author would then have to make >> the getDrawingBufferDimensions() call and use that for viewport >> settings, etc. > > One common pattern that I can see is: > > canvas.width = large_value; > canvas.height = large_value; > cx = canvas.getContext("webgl"); > size = cx.getDrawingBufferDimensions(); > if (size.width < canvas.width) > canvas.width = size.width; > if (size.height < canvas.height) > canvas.height = size.height; > > The two .width/.height sets to size.* shouldn't cause a resize (since the backbuffer is already that size), and from that point on the developer can continue to use canvas.width/canvas.height just like they normally would have. (Or just store the right values in local variables, to avoid having to get dom attributes for this!) So, for simplicity it seems like preserving aspect ratio would more often give the author the desired results. I think most authors have a set aspect ratio in mind when they create a canvas. For the above simple sequence to be effective, it should have the same aspect ratio. I don't think that's a requirement, but it would make author code simpler, I think. Otherwise, if the author cares about aspect ratio, he will have to examine the actual sizes and try to come up with a size with the desired aspect ratio that is within the size limits. That might lead to another resizing by the implementation, another examination of the resultant aspect ratio and another attempt at a different size. That is not only complicated, but could lead to an infinite loop if written poorly. >> ...But you bring up a good point. If the author does "canvas.width = >> 1000; canvas.height = 500;" will the canvas get resized twice? In >> other words, what are our rules for when the canvas gets resized? Is >> there a way for us to optimize the sizing? Maybe we could delay >> resizing the canvas until either the size is queried, or a WebGL call >> is made. > > The canvas unfortunately has to be resized twice. I've sent mail to whatwg that this is really undesirable, and suggested that the canvas element just get a setSize() method that would set both width and height at the same time. I would think the implementation could optimize it as I described though, couldn't it? Seems like lazy resizing would not add a lot to each graphics call. Our implementation already has a prefix method on every graphics call to ensure that the GL context is set. Adding a check of a dirty flag seems like a reasonable addition to that logic. > > One related comment -- I think that we should clamp the canvas back buffer dimensions, *but* for on-screen display we need to scale up to the original requested canvas size, even if it's inefficient. I think this is better than actually changing the physical layout dimensions of the canvas element as well, but I could probably go either way. Yes, of course. Gregg's 10000 x 1500 example (or whatever it was) would give the author a drawing buffer that was 2000 x 1500 (or 2000 x 300 if we maintain aspect ratio). But the drawing buffer would be stretched to fit a 10000 x 1500 space on the page. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Tue Nov 9 13:02:39 2010 From: vla...@ (Vladimir Vukicevic) Date: Tue, 9 Nov 2010 13:02:39 -0800 (PST) Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <2EF4A6B4-41FF-4571-B6D9-9EA3E544846F@apple.com> Message-ID: <1326244576.313574.1289336559824.JavaMail.root@cm-mail03.mozilla.org> ----- Original Message ----- > So, for simplicity it seems like preserving aspect ratio would more > often give the author the desired results. I think most authors have a > set aspect ratio in mind when they create a canvas. For the above > simple sequence to be effective, it should have the same aspect ratio. > I don't think that's a requirement, but it would make author code > simpler, I think. Otherwise, if the author cares about aspect ratio, > he will have to examine the actual sizes and try to come up with a > size with the desired aspect ratio that is within the size limits. > That might lead to another resizing by the implementation, another > examination of the resultant aspect ratio and another attempt at a > different size. That is not only complicated, but could lead to an > infinite loop if written poorly. Yeah, they'd have to use getEffectiveDrawingSize()'s width/height as the aspect ratio, not canvas.width/canvas.height -- unless they did the above though, in which case they could use canvas.width/canvas.height. > >> ...But you bring up a good point. If the author does "canvas.width > >> = > >> 1000; canvas.height = 500;" will the canvas get resized twice? In > >> other words, what are our rules for when the canvas gets resized? > >> Is > >> there a way for us to optimize the sizing? Maybe we could delay > >> resizing the canvas until either the size is queried, or a WebGL > >> call > >> is made. > > > > The canvas unfortunately has to be resized twice. I've sent mail to > > whatwg that this is really undesirable, and suggested that the > > canvas element just get a setSize() method that would set both width > > and height at the same time. > > I would think the implementation could optimize it as I described > though, couldn't it? Seems like lazy resizing would not add a lot to > each graphics call. Our implementation already has a prefix method on > every graphics call to ensure that the GL context is set. Adding a > check of a dirty flag seems like a reasonable addition to that logic. Could be -- certainly possible in WebGL, much more easily than with Canvas 2D I think since the state-resetting is more complex for 2D canvas. > > One related comment -- I think that we should clamp the canvas back > > buffer dimensions, *but* for on-screen display we need to scale up > > to the original requested canvas size, even if it's inefficient. I > > think this is better than actually changing the physical layout > > dimensions of the canvas element as well, but I could probably go > > either way. > > Yes, of course. Gregg's 10000 x 1500 example (or whatever it was) > would give the author a drawing buffer that was 2000 x 1500 (or 2000 x > 300 if we maintain aspect ratio). But the drawing buffer would be > stretched to fit a 10000 x 1500 space on the page. This of course makes the aspect ratio computation even slightly more confusing... canvas.width/canvas.height needs to be the drawn aspect ratio, but the viewport must be set in terms of effective drawing size. No really good solution for all of this, but I think the getEffective() etc. is the simplest; now we should just decide about whether to preserve the aspect ratio or not. I don't think there's any reason *not* to, since again if someone has an explicit case they have all the tools to pick a specific exact size. We're just trying to come up with the simplest default, and preserving seems like it.. - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Tue Nov 9 14:07:40 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Tue, 9 Nov 2010 14:07:40 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <2EF4A6B4-41FF-4571-B6D9-9EA3E544846F@apple.com> References: <1195112560.312144.1289329226917.JavaMail.root@cm-mail03.mozilla.org> <2EF4A6B4-41FF-4571-B6D9-9EA3E544846F@apple.com> Message-ID: On Tue, Nov 9, 2010 at 11:46 AM, Chris Marrin wrote: > > On Nov 9, 2010, at 11:00 AM, Vladimir Vukicevic wrote: > > > > > > > ----- Original Message ----- > >> On Nov 8, 2010, at 8:17 PM, Mark Callow wrote: > >> > >>> I, for one, am not prepared to sign off on something like this based > >>> on what feels like a very sketchy description and no explanation of > >>> how an application is supposed to handle this situation. Furthermore > >>> I share Cedric's concern that most authors will not handle it. > >>> > >>> In native GL app's I let my resize event handler deal with resizing > >>> things to whatever size the window system or user has permitted. If > >>> I understand correctly, in the WebGL case the resize events are > >>> based on the canvas size, therefore special handling is needed for > >>> this error condition. How exactly does the application handle the > >>> condition. > >> > >> There is no resize event for Canvas because sizing it is synchronous. > >> You set the width and height and the canvas is created with those > >> dimensions. For complete handling the author would then have to make > >> the getDrawingBufferDimensions() call and use that for viewport > >> settings, etc. > > > > One common pattern that I can see is: > > > > canvas.width = large_value; > > canvas.height = large_value; > > cx = canvas.getContext("webgl"); > > size = cx.getDrawingBufferDimensions(); > > if (size.width < canvas.width) > > canvas.width = size.width; > > if (size.height < canvas.height) > > canvas.height = size.height; > > > > The two .width/.height sets to size.* shouldn't cause a resize (since > the backbuffer is already that size), and from that point on the developer > can continue to use canvas.width/canvas.height just like they normally would > have. (Or just store the right values in local variables, to avoid having > to get dom attributes for this!) > > So, for simplicity it seems like preserving aspect ratio would more often > give the author the desired results. I think most authors have a set aspect > ratio in mind when they create a canvas. I don't think is the case. I think there are 2 most common cases #1) The developer chooses a fixed size canvas. In this case there is likely no problem. It is unlikely a developer is going to choose a fixed size so large that it will be too large and trigger this issue #2) The developer makes the canvas dynamically resize based on the size of the window. In the case the developer has already given up on an aspect ratio since the user gets to choose it. All but 2 of the demos on webglsamples.googlecode.com don't care about pixel aspect ratio nor do they care about canvas aspect ratio. They do the math (aspectRatio = canvas.clientWidth / canvas.clientHeight) to set their projection matrix and it just works. Of the samples at O3D samples at o3d.goolecode.com, the ones that allow canvas resizing always try to set the canvas backbuffer to the display size of the canvas as in document.onresize = function() { canvas.width = canvas.clientWidth; canvas.height = canvas.clientHeight; gl.viewport(0, 0, canvas.clientWidth, canvas.clientHeight); } They also compute their aspect ratio correctly by using the display size. aspectRatio = canvas.clientWidth / canvas.clientHeight; All that would change if the canvas size wasn't guaranteed is this document.onresize = function() { canvas.width = canvas.clientWidth; canvas.height = canvas.clientHeight; var size = canvas.getDrawingSize() gl.viewport(0, 0, size.width, size.height); } > For the above simple sequence to be effective, it should have the same > aspect ratio. I don't think that's a requirement, but it would make author > code simpler, I think. Otherwise, if the author cares about aspect ratio, he > will have to examine the actual sizes and try to come up with a size with > the desired aspect ratio that is within the size limits. That might lead to > another resizing by the implementation, another examination of the resultant > aspect ratio and another attempt at a different size. That is not only > complicated, but could lead to an infinite loop if written poorly. > > >> ...But you bring up a good point. If the author does "canvas.width = > >> 1000; canvas.height = 500;" will the canvas get resized twice? In > >> other words, what are our rules for when the canvas gets resized? Is > >> there a way for us to optimize the sizing? Maybe we could delay > >> resizing the canvas until either the size is queried, or a WebGL call > >> is made. > > > > The canvas unfortunately has to be resized twice. I've sent mail to > whatwg that this is really undesirable, and suggested that the canvas > element just get a setSize() method that would set both width and height at > the same time. > > I would think the implementation could optimize it as I described though, > couldn't it? Seems like lazy resizing would not add a lot to each graphics > call. Our implementation already has a prefix method on every graphics call > to ensure that the GL context is set. Adding a check of a dirty flag seems > like a reasonable addition to that logic. > > > > > One related comment -- I think that we should clamp the canvas back > buffer dimensions, *but* for on-screen display we need to scale up to the > original requested canvas size, even if it's inefficient. I think this is > better than actually changing the physical layout dimensions of the canvas > element as well, but I could probably go either way. > > Yes, of course. Gregg's 10000 x 1500 example (or whatever it was) would > give the author a drawing buffer that was 2000 x 1500 (or 2000 x 300 if we > maintain aspect ratio). But the drawing buffer would be stretched to fit a > 10000 x 1500 space on the page. > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed Nov 10 00:34:47 2010 From: cal...@ (Mark Callow) Date: Wed, 10 Nov 2010 17:34:47 +0900 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> Message-ID: <4CDA5927.9080604@hicorp.co.jp> On 10/11/2010 03:34, Chris Marrin wrote: > But you bring up a good point. If the author does "canvas.width = 1000; canvas.height = 500;" will the canvas get resized twice? In other words, what are our rules for when the canvas gets resized? Is there a way for us to optimize the sizing? Maybe we could delay resizing the canvas until either the size is queried, or a WebGL call is made. I think it would be preferable if the resizes can be coalesced somehow. >> I am already having a hard time achieving what I'd like to do regarding canvas size due to having to specify the size in pixels - an insane idea given the wide variety of displays we have to deal with. > Huh? This is the way the web works. Mobile devices have had to deal with it from day 1. There are really several choices (from an iOS perspective): As far as I recall canvas is the only element where size must be specified in pixels. Others can be specified as percentage, points, picas, mm, etc. > 1) The author does nothing and the scaling logic in the web browser kicks in to show the entire page scaled down or zoomed in. In this case you design like you would for a desktop browser and count on the device to scale appropriately. > > 2) The author specifies the page size in meta tags and writes specifically for the resolution of the device being used. This is less useful nowadays that there are at least 3 screen resolutions of iOS devices. > > 3) Use media queries and design several layouts in CSS for a variety of sizes. You can also use media queries from JS to change behavior based on various possible layouts. > > 4) Use window.innerWidth/window.innerHeight to find the current window size. On iOS devices, they are always "full-screen", so this gives you the screen size. It is actually the size inside the chrome. You can get the real screen size with window.outerWidth/window.outerHeight. > > So there are plenty of tools to deal with the wide variety of mobile devices. Everything but (2) above are also viable design tools for desktop browsers. Indeed. But being able to set sizes as percentages, in particular, is an extremely useful aid to the above techniques. Sadly GWT does not currently have inner{Width,Height} queries so I've had to be a bit more, er.., creative, in order to size my canvas according to the size of the browser window. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From cal...@ Wed Nov 10 00:45:49 2010 From: cal...@ (Mark Callow) Date: Wed, 10 Nov 2010 17:45:49 +0900 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <1195112560.312144.1289329226917.JavaMail.root@cm-mail03.mozilla.org> References: <1195112560.312144.1289329226917.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <4CDA5BBD.9090808@hicorp.co.jp> Regards -Mark On 10/11/2010 04:00, Vladimir Vukicevic wrote: > > ----- Original Message ----- > One common pattern that I can see is: > > canvas.width = large_value; > canvas.height = large_value; > cx = canvas.getContext("webgl"); > size = cx.getDrawingBufferDimensions(); > if (size.width < canvas.width) > canvas.width = size.width; > if (size.height < canvas.height) > canvas.height = size.height; > > The two .width/.height sets to size.* shouldn't cause a resize (since the backbuffer is already that size), and from that point on the developer can continue to use canvas.width/canvas.height just like they normally would have. (Or just store the right values in local variables, to avoid having to get dom attributes for this!) > > I think the above is by far the simplest thing to implement, describe, and use. Let's say instead we went with throwing an exception: > > ok = false; > desired_w = large_value; > desired_h = large_value; > while (!ok) { > try { > canvas.width = desired_w; > canvas.height = desired_h; > } catch (e) { > // what now? You have no GL context yet, so can't query the viewport dimensions. So.. > canvas.width = 1; > canvas.height = 1; > cx = canvas.getContext("webgl"); > new_dim = cx.getParameter(MAX_VIEWPORT_...); > if (desired_w == new_dim) { > alert("failed"); > break; > } > > desired_w = new_dim; > desired_h = new_dim; > } > } > > That's awful, and has zero advantages that I can see. I agree the first looks easier. I think WebGL needs to say something about the minimum required value of MAX_VIEWPORT_DIMENSION. The GL spec. says something like "it must be at least as large as the display". When written, display == device screen. As I pointed out the other day at the native level, you can't rely on this to tell you the maximum size of an FBO renderbuffer or texture render target. So if WebGL simply returns the native value, it is not useful for checking the maximum permissible size of the drawing buffer. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From ala...@ Wed Nov 10 09:30:09 2010 From: ala...@ (ala...@) Date: Wed, 10 Nov 2010 09:30:09 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CDA5927.9080604@hicorp.co.jp> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> <4CDA5927.9080604@hicorp.co.jp> Message-ID: <4CDAD6A1.4020700@mechnicality.com> I've been doing some experiments on detecting resizing in both pure Javascript and using the Google GWT library. Currently I'm getting some horrible artifacts when resizing the canvas inside Chrome. I've filed a bug - http://code.google.com/p/chromium/issues/detail?id=62679 These artifacts don't appear in Firefox. Also please see comments below. Not surprisingly, I've also changed my mind and decided that the Vlad/Chris approach to resizing will work fine. I'm not sure about the aspect ratio thing, though. At first glance it seems a good idea, but really any sensible application is going to have to track the display size for those cases where the browser window is resized to smaller than the viewport, surely? In which case, you must always track the actual window dimensions and recalculate the aspect ratio for use with the perspective matrix. Or am I missing something? On 11/10/2010 12:34 AM, Mark Callow wrote: > Sadly GWT does not currently have inner{Width,Height} queries so I've > had to be a bit more, er.., creative, in order to size my canvas > according to the size of the browser window. > Actually, this isn't quite true. Window inner width and height can easily be determined from an event handler tied to window resize events. I've written some test code for both pure JS and with GWT which uses this to resize the webgl canvas as the browser is resized. Regards Alan ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Wed Nov 10 11:45:13 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Wed, 10 Nov 2010 11:45:13 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CDA5927.9080604@hicorp.co.jp> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> <4CDA5927.9080604@hicorp.co.jp> Message-ID: On Wed, Nov 10, 2010 at 12:34 AM, Mark Callow wrote: > > On 10/11/2010 03:34, Chris Marrin wrote: > > But you bring up a good point. If the author does "canvas.width = 1000; > canvas.height = 500;" will the canvas get resized twice? In other words, > what are our rules for when the canvas gets resized? Is there a way for us > to optimize the sizing? Maybe we could delay resizing the canvas until > either the size is queried, or a WebGL call is made. > I think it would be preferable if the resizes can be coalesced somehow. > > >> I am already having a hard time achieving what I'd like to do regarding > canvas size due to having to specify the size in pixels - an insane idea > given the wide variety of displays we have to deal with. > > Huh? This is the way the web works. Mobile devices have had to deal with > it from day 1. There are really several choices (from an iOS perspective): > As far as I recall canvas is the only element where size must be > specified in pixels. Others can be specified as percentage, points, > picas, mm, etc. > The display size can be specified in any size. canvas.style.width = "30%"; canvas.style.height = "3em"; This is and isn't different from say the Img tag. Although with the image tag you can do img.width = "30%" that has been deprecated. You're supposed to use img.style.width = "30%" . Also, setting img.width="30%" doesn't change the number of pixels in the image. It only changes the display size. > > 1) The author does nothing and the scaling logic in the web browser kicks > in to show the entire page scaled down or zoomed in. In this case you design > like you would for a desktop browser and count on the device to scale > appropriately. > > > > 2) The author specifies the page size in meta tags and writes > specifically for the resolution of the device being used. This is less > useful nowadays that there are at least 3 screen resolutions of iOS devices. > > > > 3) Use media queries and design several layouts in CSS for a variety of > sizes. You can also use media queries from JS to change behavior based on > various possible layouts. > > > > 4) Use window.innerWidth/window.innerHeight to find the current window > size. On iOS devices, they are always "full-screen", so this gives you the > screen size. It is actually the size inside the chrome. You can get the real > screen size with window.outerWidth/window.outerHeight. > > > > So there are plenty of tools to deal with the wide variety of mobile > devices. Everything but (2) above are also viable design tools for desktop > browsers. > Indeed. But being able to set sizes as percentages, in particular, is an > extremely useful aid to the above techniques. > > Sadly GWT does not currently have inner{Width,Height} queries so I've > had to be a bit more, er.., creative, in order to size my canvas > according to the size of the browser window. > > Regards > > -Mark > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.s...@ Wed Nov 10 12:45:37 2010 From: m.s...@ (M.Sirin) Date: Wed, 10 Nov 2010 21:45:37 +0100 Subject: [Public WebGL] Reading out the color value stored in FBO with Chromium Message-ID: Hi, after I defined a framebuffer object and using it for colorpicking, it works without any problems in firefox/minefield. But there must be something wrong, because Chromium 9.0.564.0 (63713) isn't doing anything when trying to read the color value stored in the fbo. This is how I'm defining and using the stuff: 1. FBO: ----------------------------------------------------- fbo=gl.createFramebuffer(); gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); var rbDepth=gl.createRenderbuffer(); gl.bindRenderbuffer(gl.RENDERBUFFER,rbDepth); var rbDepthStorage=gl.renderbufferStorage(gl.RENDERBUFFER,gl.DEPTH_COMPONENT16,canvas.width ,canvas.height); gl.framebufferRenderbuffer(gl.FRAMEBUFFER,gl.DEPTH_ATTACHMENT,gl.RENDERBUFFER,rbDepth); var texture=gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D,texture); gl.texImage2D(gl.TEXTURE_2D,0,gl.RGBA,canvas.width ,canvas.height,0,gl.RGBA,gl.UNSIGNED_BYTE,null); gl.framebufferTexture2D(gl.FRAMEBUFFER,gl.COLOR_ATTACHMENT0,gl.TEXTURE_2D,texture,0); 2. After making a common drawArrays-call: ------------------------------------------------- gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); //send unique color to shader & deactivate all lightening etc. //another drawArrays-call gl.bindFramebuffer(gl.FRAMEBUFFER,null); 3. In case of refreshing the scene: ------------------------------------------------- gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); gl.clearColor(0.0,0.0,0.0,1.0) gl.enable(gl.DEPTH_TEST); gl.bindFramebuffer(gl.FRAMEBUFFER,null); gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); gl.clearColor(0.0,0.0,0.0,1.0) gl.enable(gl.DEPTH_TEST); gl.viewport(0, 0, canvas.clientWidth, canvas.clientHeight); ... 4. Read color that was previously stored in the fbo: ------------------------------------------------- gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); var pix = new Uint8Array(4); gl.readPixels(xCoord-10, canvas.clientHeight-yCoord+37, 1, 1, gl.RGB,gl.UNSIGNED_BYTE,pix); alert(pix[0],pix[1],pix[2]); Output: alert with firefox e.g.: 0 0 9 which is correct alert with Chromium is always 0 0 0 which is of course not correct I guess there is something wrong in the first step, i.e. the definition of the FBO ? regards m.sirin -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhe...@ Wed Nov 10 13:13:05 2010 From: zhe...@ (Mo, Zhenyao) Date: Wed, 10 Nov 2010 13:13:05 -0800 Subject: [Public WebGL] Reading out the color value stored in FBO with Chromium In-Reply-To: References: Message-ID: The problem is in your readPixels function. RGB is no longer valid. For WebGL, only RGBA/UNSIGNED_BYTE are supported. If firefox gives you the pixel data, it's a bug they should fix. An error (INVALID_OPERATION) should be generated instead. Mo On Wed, Nov 10, 2010 at 12:45 PM, M.Sirin wrote: > Hi, > after I defined a framebuffer object and using it for colorpicking, it works > without any problems in firefox/minefield. But there must be something > wrong, because Chromium?9.0.564.0 (63713) isn't doing anything when trying > to read the color value stored in the fbo. > This is how I'm defining and using the stuff: > 1. FBO: > ----------------------------------------------------- > fbo=gl.createFramebuffer(); > gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > var rbDepth=gl.createRenderbuffer(); > gl.bindRenderbuffer(gl.RENDERBUFFER,rbDepth); > var > rbDepthStorage=gl.renderbufferStorage(gl.RENDERBUFFER,gl.DEPTH_COMPONENT16,canvas.width > ,canvas.height); > gl.framebufferRenderbuffer(gl.FRAMEBUFFER,gl.DEPTH_ATTACHMENT,gl.RENDERBUFFER,rbDepth); > var texture=gl.createTexture(); > gl.bindTexture(gl.TEXTURE_2D,texture); > gl.texImage2D(gl.TEXTURE_2D,0,gl.RGBA,canvas.width > ,canvas.height,0,gl.RGBA,gl.UNSIGNED_BYTE,null); > gl.framebufferTexture2D(gl.FRAMEBUFFER,gl.COLOR_ATTACHMENT0,gl.TEXTURE_2D,texture,0); > > 2. After making a common drawArrays-call: > ------------------------------------------------- > gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > //send unique color to shader & deactivate all lightening etc. > //another drawArrays-call > gl.bindFramebuffer(gl.FRAMEBUFFER,null); > > 3. In case of refreshing the scene: > ------------------------------------------------- > ?? gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > ?? gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); > ?? gl.clearColor(0.0,0.0,0.0,1.0) > ?? gl.enable(gl.DEPTH_TEST); > > ?? gl.bindFramebuffer(gl.FRAMEBUFFER,null); > ?? gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); > ?? gl.clearColor(0.0,0.0,0.0,1.0) > ?? gl.enable(gl.DEPTH_TEST); > > ?? gl.viewport(0, 0, canvas.clientWidth, canvas.clientHeight); > ... > 4. Read color that was previously stored in the fbo: > ------------------------------------------------- > ?gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > ??var pix = new Uint8Array(4); > ??gl.readPixels(xCoord-10, canvas.clientHeight-yCoord+37, 1, 1, > gl.RGB,gl.UNSIGNED_BYTE,pix); > ??alert(pix[0],pix[1],pix[2]); > > Output: > ??alert with firefox e.g.: 0 0 9 which is correct > ??alert with Chromium is always 0 0 0 which is of course not correct > > > I guess there is something wrong in the first step, i.e. the definition of > the FBO ? > > regards > m.sirin > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From m.s...@ Wed Nov 10 14:52:38 2010 From: m.s...@ (M.Sirin) Date: Wed, 10 Nov 2010 23:52:38 +0100 Subject: [Public WebGL] Reading out the color value stored in FBO with Chromium In-Reply-To: References: Message-ID: Yep, you're right. Now everything is working as it should be. Thank you! In Firefox or Minefield I don't see any error like the one you mentioned. regards m.sirin 2010/11/10 Mo, Zhenyao > The problem is in your readPixels function. RGB is no longer valid. > For WebGL, only RGBA/UNSIGNED_BYTE are supported. > > If firefox gives you the pixel data, it's a bug they should fix. An > error (INVALID_OPERATION) should be generated instead. > > Mo > > On Wed, Nov 10, 2010 at 12:45 PM, M.Sirin > wrote: > > Hi, > > after I defined a framebuffer object and using it for colorpicking, it > works > > without any problems in firefox/minefield. But there must be something > > wrong, because Chromium 9.0.564.0 (63713) isn't doing anything when > trying > > to read the color value stored in the fbo. > > This is how I'm defining and using the stuff: > > 1. FBO: > > ----------------------------------------------------- > > fbo=gl.createFramebuffer(); > > gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > > var rbDepth=gl.createRenderbuffer(); > > gl.bindRenderbuffer(gl.RENDERBUFFER,rbDepth); > > var > > > rbDepthStorage=gl.renderbufferStorage(gl.RENDERBUFFER,gl.DEPTH_COMPONENT16,canvas.width > > ,canvas.height); > > > gl.framebufferRenderbuffer(gl.FRAMEBUFFER,gl.DEPTH_ATTACHMENT,gl.RENDERBUFFER,rbDepth); > > var texture=gl.createTexture(); > > gl.bindTexture(gl.TEXTURE_2D,texture); > > gl.texImage2D(gl.TEXTURE_2D,0,gl.RGBA,canvas.width > > ,canvas.height,0,gl.RGBA,gl.UNSIGNED_BYTE,null); > > > gl.framebufferTexture2D(gl.FRAMEBUFFER,gl.COLOR_ATTACHMENT0,gl.TEXTURE_2D,texture,0); > > > > 2. After making a common drawArrays-call: > > ------------------------------------------------- > > gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > > //send unique color to shader & deactivate all lightening etc. > > //another drawArrays-call > > gl.bindFramebuffer(gl.FRAMEBUFFER,null); > > > > 3. In case of refreshing the scene: > > ------------------------------------------------- > > gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > > gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); > > gl.clearColor(0.0,0.0,0.0,1.0) > > gl.enable(gl.DEPTH_TEST); > > > > gl.bindFramebuffer(gl.FRAMEBUFFER,null); > > gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT); > > gl.clearColor(0.0,0.0,0.0,1.0) > > gl.enable(gl.DEPTH_TEST); > > > > gl.viewport(0, 0, canvas.clientWidth, canvas.clientHeight); > > ... > > 4. Read color that was previously stored in the fbo: > > ------------------------------------------------- > > gl.bindFramebuffer(gl.FRAMEBUFFER,fbo); > > var pix = new Uint8Array(4); > > gl.readPixels(xCoord-10, canvas.clientHeight-yCoord+37, 1, 1, > > gl.RGB,gl.UNSIGNED_BYTE,pix); > > alert(pix[0],pix[1],pix[2]); > > > > Output: > > alert with firefox e.g.: 0 0 9 which is correct > > alert with Chromium is always 0 0 0 which is of course not correct > > > > > > I guess there is something wrong in the first step, i.e. the definition > of > > the FBO ? > > > > regards > > m.sirin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oli...@ Wed Nov 10 14:55:33 2010 From: oli...@ (Oliver Hunt) Date: Wed, 10 Nov 2010 14:55:33 -0800 Subject: [Public WebGL] Reading out the color value stored in FBO with Chromium In-Reply-To: References: Message-ID: It's a recent spec change so it will no doubt take a wee while to be implemented everywhere. (Recent = last week i think...) --Oliver On Nov 10, 2010, at 2:52 PM, M.Sirin wrote: > Yep, you're right. Now everything is working as it should be. > Thank you! > In Firefox or Minefield I don't see any error like the one you mentioned. > > regards > m.sirin ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Thu Nov 11 00:16:50 2010 From: cal...@ (Mark Callow) Date: Thu, 11 Nov 2010 17:16:50 +0900 Subject: [Public WebGL] Mysterious extra padding below canvas Message-ID: <4CDBA672.8020808@hicorp.co.jp> In my efforts to size a canvas to fill the browser window, I have found the browsers are adding some mysterious padding below the canvas element. I have created the attached simple show-gap.html to illustrate the problem. It encloses the canvas in a
element with a red border so you can clearly see the space. The div's height is set to 100%. All padding and margins and set to 0 as is the canvas border. The result is the same in both Chrome & Firefox 4. Instead of doing the calculation myself, I tried setting the width & height of the canvas to 100% in the canvas's style. In this case the result differs between browsers with both unsatisfactory. Firefox has a large white space below the canvas, much larger than the gap show by the first example, and no vertical scrollbar. Chrome fills the visible window with the canvas and adds a scrollbar so you can scroll this mysterious extra white space into view. The extra white space looks like the same height as that in shown by the first example. After more than an hour perusing css box information, I have failed to find an answer. Can anyone tell me why this white space is there, and how I can determine it's height so I compute my canvas size accordingly. Or, even better, prevent the browsers adding it. It has turned out to be absurdly difficult to fill the browser window with my WebGL canvas. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From gma...@ Thu Nov 11 01:37:27 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 11 Nov 2010 01:37:27 -0800 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <4CDBA672.8020808@hicorp.co.jp> References: <4CDBA672.8020808@hicorp.co.jp> Message-ID: On Thu, Nov 11, 2010 at 12:16 AM, Mark Callow wrote: > In my efforts to size a canvas to fill the browser window, I have found > the browsers are adding some mysterious padding below the canvas element. I > have created the attached simple show-gap.html to illustrate the problem. > It encloses the canvas in a
element with a red border so you can > clearly see the space. The div's height is set to 100%. All padding and > margins and set to 0 as is the canvas border. The result is the same in both > Chrome & Firefox 4. > You need to tell the browser to use modern HTML. Change the first line to And the border issue will go away > Instead of doing the calculation myself, I tried setting the width & height > of the canvas to 100% in the canvas's style. In this case the result differs > between browsers with both unsatisfactory. Firefox has a large white space > below the canvas, much larger than the gap show by the first example, and no > vertical scrollbar. Chrome fills the visible window with the canvas and adds > a scrollbar so you can scroll this mysterious extra white space into view. > The extra white space looks like the same height as that in shown by the > first example. > > After more than an hour perusing css box information, I have failed to find > an answer. Can anyone tell me why this white space is there, and how I can > determine it's height so I compute my canvas size accordingly. Or, even > better, prevent the browsers adding it. > > It has turned out to be absurdly difficult to fill the browser window with > my WebGL canvas. > If you want to fill the browser you need to tell it make the page fill the window. By default the page is as small as it can be made. In other words if all you had is a single line of text then the page is only 1 line high even if the browser window is much larger. So, add this inside style section html, body { width: 100%; height: 100%; border: 0px; padding: 0px; margin: 0px; } Now change your canvas's style from being a fixed size canvas { border: none; width: 100%; height: 100%; } You don't need the gl.viewport call as the viewport defaults to the initial of the canvas. Currently your backbuffer size is set to 500x500 pixels but it will be stretched to the entire page. If you want it always be the same size as it's displayed add document.onresize = function() { var canvas = document.getElementById('cv'); canvas.width = canvas.clientWidth; canvas.height = canvas.clientHeight; gl.viewport(0, 0, canvas.width, canvas.height); } Regards > > -Mark > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From ala...@ Thu Nov 11 02:08:50 2010 From: ala...@ (ala...@) Date: Thu, 11 Nov 2010 02:08:50 -0800 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> Message-ID: <4CDBC0B2.90601@mechnicality.com> From: http://dev.w3.org/html5/spec/Overview.html#doctype-legacy-string > A DOCTYPE must consist of the following characters, in this order: > > 1. A string that is an ASCII case-insensitive > match for the string > "| 2. One or more space characters . > 3. A string that is an ASCII case-insensitive > match for the string > "|html|". > 4. Optionally, a DOCTYPE legacy string > or an obsolete permitted > DOCTYPE string > (defined below). > 5. Zero or more space characters . > 6. A U+003E GREATER-THAN SIGN character (>). > > In other words, ||, case-insensitively. > The doctype you propose below is 4.01 (not even strict) - hardly the 'latest' doctype. On 11/11/2010 1:37 AM, Gregg Tavares (wrk) wrote: > > "http://www.w3.org/TR/html4/loose.dtd"> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ala...@ Thu Nov 11 03:43:36 2010 From: ala...@ (ala...@) Date: Thu, 11 Nov 2010 03:43:36 -0800 Subject: [Public WebGL] Doctype issues Message-ID: <4CDBD6E8.4090500@mechnicality.com> Hi I've started a separate thread on this following on from the backbuffer resizing issues. Using the correct and consistent doctype is important. Mark Callow has pointed out some layout and spacing issues resulting from trying to make the canvas fit when using . Greg Tavares proposed using the 4.01 Transitional doctype to fix these issues. Indeed, they do make the webgl canvas fit better. However, according to the HTML5 spec is the correct doctype to use going forward. I randomly sampled the webgl demos and found that all that I looked at used this doctype. is supposed to be 'standards mode' compliant, and lots of CSS now depends upon using this doctype to get consistent layout results. For example, all the newer GWT widgets only work in standard mode. GWT is not the only web framework, but most of the modern web frameworks now require standards mode compliance for correct rendering. So please would someone confirm that is the recommended doctype for WebGL. If so, then could someone explain how we get around the issues as pointed out by Mark's previous email/example? Using 4.01 Transitional may work when all that is required is to size the canvas to fit, but there will be many cases of the use of webgl where there needs to also be support for the html5 doctype. For example, in one of my applications there is a 'full window' mode which you can switch in and out of in an AJAX app using a keyboard shortcut. Consequently the doctype needs to be the same as for the non-full screen mode and 4.01 Transitional simply doesn't work in that case. I've tried a few experiments with box-sizing: border-box but they don't seem to make any difference (I assume Chrome 9 supports box-sizing, and yes I tried -moz-box-sizing: on FF) I think the problem here is going to be that the webgl canvas will be used in two different types of web application. Many of them will be games, or game-like, where the webgl canvas occupies the full browser window. In this case its probably OK to use the 4.01 Transitional. However, many applications will need to work within a 'strict' standards compliance mode. Designers are not going to be happy when they can't get the canvas to fit into a pre-determined space. Regards Alan ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From oli...@ Thu Nov 11 11:17:26 2010 From: oli...@ (Oliver Hunt) Date: Thu, 11 Nov 2010 11:17:26 -0800 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> Message-ID: <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> On Nov 11, 2010, at 1:37 AM, Gregg Tavares (wrk) wrote: > > > On Thu, Nov 11, 2010 at 12:16 AM, Mark Callow wrote: > In my efforts to size a canvas to fill the browser window, I have found the browsers are adding some mysterious padding below the canvas element. I have created the attached simple show-gap.html to illustrate the problem. It encloses the canvas in a
element with a red border so you can clearly see the space. The div's height is set to 100%. All padding and margins and set to 0 as is the canvas border. The result is the same in both Chrome & Firefox 4. > > > You need to tell the browser to use modern HTML. Change the first line > > This is the correct doctype. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhe...@ Thu Nov 11 11:36:12 2010 From: zhe...@ (Mo, Zhenyao) Date: Thu, 11 Nov 2010 11:36:12 -0800 Subject: [Public WebGL] Re: maximum length of identifiers in WebGL GLSL In-Reply-To: References: Message-ID: Hi all, This limit hasn't been specified in the current WebGL spec yet. Is it OK if we put 256 as max limit for now? Mo On Mon, Aug 2, 2010 at 3:37 PM, Kenneth Russell wrote: > On Mon, Aug 2, 2010 at 2:03 PM, Thatcher Ulrich wrote: >> 2 cents: >> >> * a fixed specified limit is good. >> >> * it should be a generous limit, since some devs will probably >> machine-generate their shaders (think C++ name mangling etc). ?On the >> other hand, a huge limit won't be exercised much. ?How about 256 >> chars? ?That should encompass all human-written shaders, and then >> some. ?For machine-written shaders, it could be exceeded but it's >> plenty of chars to generate a unique ID by hashing down a very long >> id. > > It seems reasonable to specify a maximum identifier length. The only > issue would be if some drivers do not even support the length we > decide to specify. > > I was also going to suggest a 256 character maximum to better handle > autogenerated shaders. We could spec that, implement it in the shader > validator and test on several drivers to see whether it appears to be > widely supportable. > > -Ken > >> -T >> >> On Mon, Aug 2, 2010 at 4:39 PM, Gregg Tavares (wrk) wrote: >>> ping. >>> Anyone have an opinion on this? >>> There are 2 issues. >>> Issue #1: It's possible a GL driver could be exploited by passing it giant >>> identifiers. ?Examples. >>> ctx.bindAttribLocation(program, 4MegIdentifier, location); >>> ctx.shaderSource(shader, shaderWith4MegIdentifiers, ...); >>> Issue #2: Having a Min/Max identifier size of WebGL means programs will be >>> more likely to work across platforms. >>> Right now one platform might have a 64 character limit, another a 128 >>> character limit. If you're developing on the 128 character limit system you >>> won't know your WebGL program is not going to work on some other system. ?If >>> instead the spec says it must support 128 characters to be WebGL conformance >>> than an system who's OpenGL driver does not support 128 character will >>> either need a new driver or the WebGL implementation will need to alias the >>> ids. In either case WebGL becomes more compatible across system. >>> Note that the GLSL translator everyone is currently using already has a 128 >>> character limit but it would be nice if that limit (or some limit) was >>> formalized in the spec. >>> >>> >>> >>> On Thu, Jul 29, 2010 at 3:11 PM, Gregg Tavares (wrk) >>> wrote: >>>> >>>> Do we want to specify a maximum identifier length for WebGL GLSL? >>>> I didn't see one in the GLSL spec. ?I was going to write a test with >>>> really long identifiers (4meg) to see if I could find some drivers that had >>>> problems with them but it might be better to just require WebGL to enforce >>>> some maximum length. ?64 chars? 128 chars? 256 chars which will make shaders >>>> less likely to fail on some drivers. >>>> Thoughts? >>> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Thu Nov 11 11:43:51 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 11 Nov 2010 11:43:51 -0800 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> Message-ID: Ok, my bad. I was going with what's worked in the past. The issue is that is by default an inline element. Inline elements have a baseline. To fix the issue change the style of the canvas to a block canvas { display: block; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From ala...@ Thu Nov 11 11:56:35 2010 From: ala...@ (ala...@) Date: Thu, 11 Nov 2010 11:56:35 -0800 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> Message-ID: <4CDC4A73.5040009@mechnicality.com> Thanks Greg On 11/11/2010 11:43 AM, Gregg Tavares (wrk) wrote: > Ok, my bad. I was going with what's worked in the past. > > The issue is that is by default an inline element. Inline elements have a baseline. > > To fix the issue change the style of the canvas to a block > > canvas { > display: block; > } -- Alan Chaney CTO and Founder, Mechnicality, Inc. www.mechnicality.com ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Thu Nov 11 13:44:47 2010 From: kbr...@ (Kenneth Russell) Date: Thu, 11 Nov 2010 13:44:47 -0800 Subject: [Public WebGL] Clarification to bufferData Message-ID: I've committed a small clarification to the bufferData variants taking ArrayBuffer and ArrayBufferView indicating that they generate an INVALID_VALUE error if null is passed for the buffer or view. This behavior is strongly desired because it is ill defined what happens otherwise. (Does the call become a no-op? Is the buffer object resized to zero size?) Please email the list with any concerns about this change. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Thu Nov 11 13:54:21 2010 From: vla...@ (Vladimir Vukicevic) Date: Thu, 11 Nov 2010 13:54:21 -0800 (PST) Subject: [Public WebGL] Clarification to bufferData In-Reply-To: Message-ID: <740087871.334325.1289512461726.JavaMail.root@cm-mail03.mozilla.org> ----- Original Message ----- > I've committed a small clarification to the bufferData variants taking > ArrayBuffer and ArrayBufferView indicating that they generate an > INVALID_VALUE error if null is passed for the buffer or view. This > behavior is strongly desired because it is ill defined what happens > otherwise. (Does the call become a no-op? Is the buffer object resized > to zero size?) FWIW, for us currently we try to convert the arg to a non-null ArrayBuffer or ArrayBufferView, and if that fails then we do the JS standard "ToInt32()" operation to get a size. For null that'll give us back 0, so we end up treating it as resizing the buffer to 0-size. Not sure if that's any better or worse; I have no problem with the change. - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Thu Nov 11 13:55:47 2010 From: cma...@ (Chris Marrin) Date: Thu, 11 Nov 2010 13:55:47 -0800 Subject: [Public WebGL] Behavior of WebGL canvas when it can't make a backbuffer of the requested size? In-Reply-To: <4CDA5927.9080604@hicorp.co.jp> References: <1288995165.8512.2.camel@Nokia-N900-02-2> <4CD8CB58.8070108@hicorp.co.jp> <4CDA5927.9080604@hicorp.co.jp> Message-ID: <15B706A5-BF66-40AD-9250-FB375FDB528A@apple.com> On Nov 10, 2010, at 12:34 AM, Mark Callow wrote: > > On 10/11/2010 03:34, Chris Marrin wrote: >> But you bring up a good point. If the author does "canvas.width = 1000; canvas.height = 500;" will the canvas get resized twice? In other words, what are our rules for when the canvas gets resized? Is there a way for us to optimize the sizing? Maybe we could delay resizing the canvas until either the size is queried, or a WebGL call is made. > I think it would be preferable if the resizes can be coalesced somehow. > >>> I am already having a hard time achieving what I'd like to do regarding canvas size due to having to specify the size in pixels - an insane idea given the wide variety of displays we have to deal with. >> Huh? This is the way the web works. Mobile devices have had to deal with it from day 1. There are really several choices (from an iOS perspective): > As far as I recall canvas is the only element where size must be > specified in pixels. Others can be specified as percentage, points, > picas, mm, etc. I think you're referring to the canvas.width and canvas.height properties. That's true, they can only be specified in pixels. Other HTML elements can't be specified in point, picas, etc., either. It's just that other elements like can be specified in percentages in addition to pixels. I think that's just a throwback to the days before CSS. >> 1) The author does nothing and the scaling logic in the web browser kicks in to show the entire page scaled down or zoomed in. In this case you design like you would for a desktop browser and count on the device to scale appropriately. >> >> 2) The author specifies the page size in meta tags and writes specifically for the resolution of the device being used. This is less useful nowadays that there are at least 3 screen resolutions of iOS devices. >> >> 3) Use media queries and design several layouts in CSS for a variety of sizes. You can also use media queries from JS to change behavior based on various possible layouts. >> >> 4) Use window.innerWidth/window.innerHeight to find the current window size. On iOS devices, they are always "full-screen", so this gives you the screen size. It is actually the size inside the chrome. You can get the real screen size with window.outerWidth/window.outerHeight. >> >> So there are plenty of tools to deal with the wide variety of mobile devices. Everything but (2) above are also viable design tools for desktop browsers. > Indeed. But being able to set sizes as percentages, in particular, is an > extremely useful aid to the above techniques. I think the reason Canvas doesn't have this is because it is a big deal to change the size of a canvas. It requires re-rendering of the contents and such. So it was decided to make the canvas size change something that can only be changed by the author. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Thu Nov 11 14:00:05 2010 From: cma...@ (Chris Marrin) Date: Thu, 11 Nov 2010 14:00:05 -0800 Subject: [Public WebGL] Re: maximum length of identifiers in WebGL GLSL In-Reply-To: References: Message-ID: On Nov 11, 2010, at 11:36 AM, Mo, Zhenyao wrote: > Hi all, > > This limit hasn't been specified in the current WebGL spec yet. Is it > OK if we put 256 as max limit for now? The limit should be whatever is the smallest limit on hardware in use today. If that's 64 chars, then I have no problem with that. Doesn't the GLSL spec say something about this? ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Thu Nov 11 14:00:18 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 11 Nov 2010 14:00:18 -0800 Subject: [Public WebGL] Clarification to bufferData In-Reply-To: <740087871.334325.1289512461726.JavaMail.root@cm-mail03.mozilla.org> References: <740087871.334325.1289512461726.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Thu, Nov 11, 2010 at 1:54 PM, Vladimir Vukicevic wrote: > > > ----- Original Message ----- > > I've committed a small clarification to the bufferData variants taking > > ArrayBuffer and ArrayBufferView indicating that they generate an > > INVALID_VALUE error if null is passed for the buffer or view. This > > behavior is strongly desired because it is ill defined what happens > > otherwise. (Does the call become a no-op? Is the buffer object resized > > to zero size?) > > FWIW, for us currently we try to convert the arg to a non-null ArrayBuffer > or ArrayBufferView, and if that fails then we do the JS standard "ToInt32()" > operation to get a size. For null that'll give us back 0, so we end up > treating it as resizing the buffer to 0-size. Not sure if that's any better > or worse; I have no problem with the change. > That seems more consistent with WebIDL. Since one variant of bufferData takes a GLsizei you can basically pass anything to it and it should do the standard JS / EMCAScript thing which means passing null or "foo" or undefined etc will all convert to 0. > > - Vlad > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhe...@ Thu Nov 11 14:06:37 2010 From: zhe...@ (Mo, Zhenyao) Date: Thu, 11 Nov 2010 14:06:37 -0800 Subject: [Public WebGL] Re: maximum length of identifiers in WebGL GLSL In-Reply-To: References: Message-ID: There is no limit from GLSL spec. On Thu, Nov 11, 2010 at 2:00 PM, Chris Marrin wrote: > > On Nov 11, 2010, at 11:36 AM, Mo, Zhenyao wrote: > >> Hi all, >> >> This limit hasn't been specified in the current WebGL spec yet. ?Is it >> OK if we put 256 as max limit for now? > > The limit should be whatever is the smallest limit on hardware in use today. If that's 64 chars, then I have no problem with that. Doesn't the GLSL spec say something about this? > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From kbr...@ Thu Nov 11 14:37:12 2010 From: kbr...@ (Kenneth Russell) Date: Thu, 11 Nov 2010 14:37:12 -0800 Subject: [Public WebGL] Clarification to bufferData In-Reply-To: References: <740087871.334325.1289512461726.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Thu, Nov 11, 2010 at 2:00 PM, Gregg Tavares (wrk) wrote: > > > On Thu, Nov 11, 2010 at 1:54 PM, Vladimir Vukicevic > wrote: >> >> >> ----- Original Message ----- >> > I've committed a small clarification to the bufferData variants taking >> > ArrayBuffer and ArrayBufferView indicating that they generate an >> > INVALID_VALUE error if null is passed for the buffer or view. This >> > behavior is strongly desired because it is ill defined what happens >> > otherwise. (Does the call become a no-op? Is the buffer object resized >> > to zero size?) >> >> FWIW, for us currently we try to convert the arg to a non-null ArrayBuffer >> or ArrayBufferView, and if that fails then we do the JS standard "ToInt32()" >> operation to get a size. ?For null that'll give us back 0, so we end up >> treating it as resizing the buffer to 0-size. ?Not sure if that's any better >> or worse; I have no problem with the change. > > That seems more consistent with WebIDL. ?Since one variant of bufferData > takes a GLsizei you can basically pass anything to it and it should do the > standard JS / EMCAScript thing which means passing null or "foo" or > undefined etc will all convert to 0. I'm not sure this analysis is correct. In overloaded constructor invocations in Web IDL, passing null would cause the ArrayBuffer and ArrayBufferView variants to be selected over the GLsizei variant per the following sections: http://dev.w3.org/2006/webapi/WebIDL/Overview.html#idl-overloading http://dev.w3.org/2006/webapi/WebIDL/Overview.html#es-interface-call In particular because null maps to "the object types, all nullable types and all array types" (Section 4.4.1.1 step 3.2.2). I'm not 100% sure how this works in normal overloaded calls but I think the behavior is defined in http://dev.w3.org/2006/webapi/WebIDL/Overview.html#call , which implies that the method selected is ambiguous given that we don't have a preference defined in the WebGL IDL. We'd be able to distinguish this properly in Java or other statically typed languages, so I think it's worth defining the behavior as is in the case that those methods can be selected when null is passed. -Ken >> >> ? ?- Vlad >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Thu Nov 11 19:10:56 2010 From: cal...@ (Mark Callow) Date: Fri, 12 Nov 2010 12:10:56 +0900 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> Message-ID: <4CDCB040.3080503@hicorp.co.jp> Thanks to Oliver & Gregg for solving the issue. I have no got it working as I want in Chrome but there appears to be a bug in CSS scaling bug in Firefox which I'll describe in a new message. Regards -Mark On 12/11/2010 04:43, Gregg Tavares (wrk) wrote: > Ok, my bad. I was going with what's worked in the past. > > The issue is that is by default an inline element. Inline > elements have a baseline. > > To fix the issue change the style of the canvas to a block > > canvas { > display: block; > } -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From cal...@ Thu Nov 11 19:29:42 2010 From: cal...@ (Mark Callow) Date: Fri, 12 Nov 2010 12:29:42 +0900 Subject: [Public WebGL] css size vs. canvas size; Firefox 4 bug? Message-ID: <4CDCB4A6.8010705@hicorp.co.jp> The attached html file has a canvas whose style sets the display type to block and the width & height to 50%. The tag does not specify a width & height. When I run the file in either FF4 or Chrome the canvas is displayed at the expected half of the window size. The actual canvas size (canvas.{width,height}) is reported as the default 300 x 150. So far so good. I then added an resize handler which does canvas.width = canvas.clientWidth; canvas.height = canvas.clientHeight; so as to change the size of the canvas to the displayed size. It works as expected in Chrome. In FF4 beta 7, the displayed height of the canvas is changed to the actual height (150) and this is the value returned by canvas.clientHeight. If I comment out both the lines the displayed size is correct. I have to comment out both lines. It is the act of querying canvas.clientWidth that triggers the bug, and changes the displayed height of the canvas to 150. Very weird. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From oli...@ Thu Nov 11 20:05:30 2010 From: oli...@ (Oliver Hunt) Date: Thu, 11 Nov 2010 20:05:30 -0800 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <4CDCB040.3080503@hicorp.co.jp> References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCB040.3080503@hicorp.co.jp> Message-ID: <30FB450B-C03B-40E2-9789-96D348EE0692@apple.com> Credit where credit is due, that was all Gregg :D --Oliver On Nov 11, 2010, at 7:10 PM, Mark Callow wrote: > Thanks to Oliver & Gregg for solving the issue. I have no got it working as I want in Chrome but there appears to be a bug in CSS scaling bug in Firefox which I'll describe in a new message. > > Regards > > -Mark > > > > > > On 12/11/2010 04:43, Gregg Tavares (wrk) wrote: >> >> Ok, my bad. I was going with what's worked in the past. >> >> The issue is that is by default an inline element. Inline elements have a baseline. >> >> To fix the issue change the style of the canvas to a block >> >> canvas { >> display: block; >> } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Thu Nov 11 21:04:36 2010 From: cal...@ (Mark Callow) Date: Fri, 12 Nov 2010 14:04:36 +0900 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> Message-ID: <4CDCCAE4.4050303@hicorp.co.jp> Even with this change, when I have {width,height} = 100% in the canvas style, I get a big white space below the canvas in FF4 beta 7. Also the space normally occupied by the "Add-on Bar" is not used when the add-on bar is not displayed so the white space becomes even larger. Check out the attached example. This file has the lines to set the actual canvas size commented out in order to avoid the bug I described in the message. "css size vs. canvas size". It looks like another FF bug. Regards -Mark On 12/11/2010 04:43, Gregg Tavares (wrk) wrote: > Ok, my bad. I was going with what's worked in the past. > > The issue is that is by default an inline element. Inline > elements have a baseline. > > To fix the issue change the style of the canvas to a block > > canvas { > display: block; > } -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From cal...@ Fri Nov 12 00:52:31 2010 From: cal...@ (Mark Callow) Date: Fri, 12 Nov 2010 17:52:31 +0900 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <4CDCCAE4.4050303@hicorp.co.jp> References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> Message-ID: <4CDD004F.8060708@hicorp.co.jp> When I have other elements on a page together with a canvas, in order to compute an ideal canvas size, I need to query, or compute, things like the margin, border and padding heights of elements, particularly the body element. I have not so far found any way through the DOM to obtain this information. The queries I've found return (content area + padding) or (content area + padding + border). I have found no query whose result is influenced by the margin nor any to tell me the padding. Style queries return empty strings unless a style is actually set on the element so are useless for elements having default settings. Can anyone suggest a way to determine this information? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From tu...@ Fri Nov 12 01:19:12 2010 From: tu...@ (Thatcher Ulrich) Date: Fri, 12 Nov 2010 10:19:12 +0100 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <4CDD004F.8060708@hicorp.co.jp> References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> <4CDD004F.8060708@hicorp.co.jp> Message-ID: What exactly are you trying to measure? You might be able to get what you want by putting a spacer DIV where you want the canvas area (with block positioning) and let the canvas have absolute positioning in the same spot. The DIV will participate in the page layout, and you can control the canvas layout by querying the DIV and setting the canvas size via Javascript. Though I'm not sure what your goal is. There may be a simpler way to get what you want. -T On Fri, Nov 12, 2010 at 9:52 AM, Mark Callow wrote: > When I have other elements on a page together with a canvas, in order to > compute an ideal canvas size, I need to query, or compute, things like the > margin, border and padding heights of elements, particularly the body > element. I have not so far found any way through the DOM to obtain this > information.? The queries I've found return (content area + padding) or > (content area + padding + border). I have found no query whose result is > influenced by the margin nor any to tell me the padding. > > Style queries return empty strings unless a style is actually set on the > element so are useless for elements having default settings. > > Can anyone suggest a way to determine this information? > > Regards > > -Mark > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Fri Nov 12 01:35:05 2010 From: cal...@ (Mark Callow) Date: Fri, 12 Nov 2010 18:35:05 +0900 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> <4CDD004F.8060708@hicorp.co.jp> Message-ID: <4CDD0A49.5060606@hicorp.co.jp> I have a line of text in a
followed by a block canvas. I want to size the canvas so it fills the rest of the window below the line of text. If I set the canvas's CSS height to 100% the canvas is given a size equal to the window size less the body's margin, border and padding. Therefore the combination of the line of text and the canvas is too big for the window. A scrollbar appears and the bottom part of my canvas is cut off. To size the canvas myself, I need to do something like the following pseudo-code: canvasHeight = window.innerHeight - body margin height * 2 - body padding height * 2 ; canvasHeight -= body border height * 2; canvasHeight -= text label height; (including any margin on the text); clientHeight gives me the content area height + padding. offsetHeight gives me clientHeight + border. So I can see how to get the border height but not how to get margin and padding heights. Regards -Mark On 12/11/2010 18:19, Thatcher Ulrich wrote: > What exactly are you trying to measure? You might be able to get what > you want by putting a spacer DIV where you want the canvas area (with > block positioning) and let the canvas have absolute positioning in the > same spot. The DIV will participate in the page layout, and you can > control the canvas layout by querying the DIV and setting the canvas > size via Javascript. > > Though I'm not sure what your goal is. There may be a simpler way to > get what you want. > > -T > > On Fri, Nov 12, 2010 at 9:52 AM, Mark Callow wrote: >> When I have other elements on a page together with a canvas, in order to >> compute an ideal canvas size, I need to query, or compute, things like the >> margin, border and padding heights of elements, particularly the body >> element. I have not so far found any way through the DOM to obtain this >> information. The queries I've found return (content area + padding) or >> (content area + padding + border). I have found no query whose result is >> influenced by the margin nor any to tell me the padding. >> >> Style queries return empty strings unless a style is actually set on the >> element so are useless for elements having default settings. >> >> Can anyone suggest a way to determine this information? >> >> Regards >> >> -Mark >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From tu...@ Fri Nov 12 02:40:48 2010 From: tu...@ (Thatcher Ulrich) Date: Fri, 12 Nov 2010 11:40:48 +0100 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <4CDD0A49.5060606@hicorp.co.jp> References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> <4CDD004F.8060708@hicorp.co.jp> <4CDD0A49.5060606@hicorp.co.jp> Message-ID: This sort of works for me -- using a 0x0 div to locate the top of the canvas area, and doing body.clientHeight - locator.offsetTop to compute the remaining height. There are some wrinkles having to do with when the body clientHeight/clientWidth is queried, and scrollbars, but you can probably work that out. -T ----

One line of text.

On Fri, Nov 12, 2010 at 10:35 AM, Mark Callow wrote: > I have a line of text in a
followed by a block canvas. I want to size > the canvas so it fills the rest of the window below the line of text. If I > set the canvas's CSS height to 100% the canvas is given a size equal to the > window? size less the body's margin, border and padding. Therefore the > combination of the line of text and the canvas is too big for the window. A > scrollbar appears and the bottom part of my canvas is cut off. > > To size the canvas myself, I need to do something like the following > pseudo-code: > > canvasHeight = window.innerHeight - body margin height * 2 - body padding > height * 2 ; > canvasHeight -= body border height * 2; > canvasHeight -= text label height; (including any margin on the text); > > clientHeight gives me the content area height + padding. offsetHeight gives > me clientHeight + border. So I can see how to get the border height but not > how to get margin and padding heights. > > Regards > > -Mark > > > > On 12/11/2010 18:19, Thatcher Ulrich wrote: > > What exactly are you trying to measure? You might be able to get what > you want by putting a spacer DIV where you want the canvas area (with > block positioning) and let the canvas have absolute positioning in the > same spot. The DIV will participate in the page layout, and you can > control the canvas layout by querying the DIV and setting the canvas > size via Javascript. > > Though I'm not sure what your goal is. There may be a simpler way to > get what you want. > > -T > > On Fri, Nov 12, 2010 at 9:52 AM, Mark Callow > wrote: > > When I have other elements on a page together with a canvas, in order to > compute an ideal canvas size, I need to query, or compute, things like the > margin, border and padding heights of elements, particularly the body > element. I have not so far found any way through the DOM to obtain this > information.? The queries I've found return (content area + padding) or > (content area + padding + border). I have found no query whose result is > influenced by the margin nor any to tell me the padding. > > Style queries return empty strings unless a style is actually set on the > element so are useless for elements having default settings. > > Can anyone suggest a way to determine this information? > > Regards > > -Mark > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From tu...@ Fri Nov 12 02:43:48 2010 From: tu...@ (Thatcher Ulrich) Date: Fri, 12 Nov 2010 11:43:48 +0100 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> <4CDD004F.8060708@hicorp.co.jp> <4CDD0A49.5060606@hicorp.co.jp> Message-ID: Re scrollbars -- on the body element, set "overflow: hidden;" to inhibit scrollbars. -T On Fri, Nov 12, 2010 at 11:40 AM, Thatcher Ulrich wrote: > This sort of works for me -- using a 0x0 div to locate the top of the > canvas area, and doing body.clientHeight - locator.offsetTop to > compute the remaining height. > > There are some wrinkles having to do with when the body > clientHeight/clientWidth is queried, and scrollbars, but you can > probably work that out. > > -T > > ---- > > > ? > ? ? > ? > ? > ? ?

One line of text.

> ? ?

onclick="resize_blue_div()" /> > ? ?

> ? ?
> ? ? ?
> ? ? ?
> ? ?
> ? > > > > On Fri, Nov 12, 2010 at 10:35 AM, Mark Callow wrote: >> I have a line of text in a
followed by a block canvas. I want to size >> the canvas so it fills the rest of the window below the line of text. If I >> set the canvas's CSS height to 100% the canvas is given a size equal to the >> window? size less the body's margin, border and padding. Therefore the >> combination of the line of text and the canvas is too big for the window. A >> scrollbar appears and the bottom part of my canvas is cut off. >> >> To size the canvas myself, I need to do something like the following >> pseudo-code: >> >> canvasHeight = window.innerHeight - body margin height * 2 - body padding >> height * 2 ; >> canvasHeight -= body border height * 2; >> canvasHeight -= text label height; (including any margin on the text); >> >> clientHeight gives me the content area height + padding. offsetHeight gives >> me clientHeight + border. So I can see how to get the border height but not >> how to get margin and padding heights. >> >> Regards >> >> -Mark >> >> >> >> On 12/11/2010 18:19, Thatcher Ulrich wrote: >> >> What exactly are you trying to measure? ?You might be able to get what >> you want by putting a spacer DIV where you want the canvas area (with >> block positioning) and let the canvas have absolute positioning in the >> same spot. ?The DIV will participate in the page layout, and you can >> control the canvas layout by querying the DIV and setting the canvas >> size via Javascript. >> >> Though I'm not sure what your goal is. ?There may be a simpler way to >> get what you want. >> >> -T >> >> On Fri, Nov 12, 2010 at 9:52 AM, Mark Callow >> wrote: >> >> When I have other elements on a page together with a canvas, in order to >> compute an ideal canvas size, I need to query, or compute, things like the >> margin, border and padding heights of elements, particularly the body >> element. I have not so far found any way through the DOM to obtain this >> information.? The queries I've found return (content area + padding) or >> (content area + padding + border). I have found no query whose result is >> influenced by the margin nor any to tell me the padding. >> >> Style queries return empty strings unless a style is actually set on the >> element so are useless for elements having default settings. >> >> Can anyone suggest a way to determine this information? >> >> Regards >> >> -Mark >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Sun Nov 14 05:47:31 2010 From: ste...@ (stephen white) Date: Mon, 15 Nov 2010 00:17:31 +1030 Subject: [Public WebGL] Delay display of WebGL? Message-ID: When I'm clicking through my news feeds, I've noticed that my web browser gets busy and crashes as I reach the WebGL parts. Having a quick look shows that WebGL starts working immediately, so the demo pages are firing off before I've gotten around to looking at them. Flash delays until it becomes the front window, which is how I can open many tabs while not having a problem. Would it be worth doing the same for WebGL, as most WebGL demos tend to be fairly intensive as a way of demonstrating a new feature and how much it can do. Once again, I think my old machine is being a guinea pig as the demos are intended to run on GPU but some of them will run on my CPU instead. However I think the problem is real, and a quick fix now could help improve the initial reaction that people have to WebGL? -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Sun Nov 14 07:42:55 2010 From: ste...@ (Steve Baker) Date: Sun, 14 Nov 2010 09:42:55 -0600 Subject: [Public WebGL] Delay display of WebGL? In-Reply-To: References: Message-ID: <4CE0037F.7060209@sjbaker.org> I'm sure the problem is "real". My WebGL game brings the rest of the system to a crawl on my netbook (the crappy Intel graphics chip runs vertex shaders in CPU software!) - and it's a pain that you can't hide it behind another tab to "pause" it while you get on with something else. I added a "PAUSE" button to the game - but it would certainly be useful to be able to automatically pause execution of the costly graphics bits of a WebGL app when it's in an inactive tab. But since WebGL might be used in a lightweight manner in a page that would expect to continue running when in a hidden tab - I don't think it would be wise for the browser to prevent execution entirely. Suppose the page is running an interactive multiplayer game - stopping the script from running altogether would leave the server in a state where it would be unable to tell whether the player had navigated away altogether (ie "Game Over") or was merely doing some more important task and had parked the game in a tab for a short time. As another example - suppose some really complicated ray-tracing program were using WebGL to show progress. It might render one pixel per second over hours. On a fast machine, you'd certainly want to be able to open other tab and get on with other work, checking back on your ray-tracer's progress once in a while to see how it's getting on. In an AJAX environment, the application might need to grab data that's coming in from the server even when it's in a hidden tab. Since the browser can't distinguish these use-cases, I'd strongly oppose a feature that automatically shut down execution when a WebGL page is hidden. It would have to be something that the app itself does voluntarily. Is there some existing way for JavaScript to detect that the tab is currently hidden? That would be a spectacularly useful thing. Well-written apps could then continue to update only the non-graphical parts of whatever they were doing and skip over the graphical update. You can't fix badly written apps like that - but there should at least be a way for well-behaved apps to "do the right thing". If not, then perhaps there is a case for adding a new timer event that only triggers when the tab is visible. Then application writers could use that event to trigger their draw() calls - and trigger the normal timer event for critical operations that don't generate graphics. As the browser starts to look more and more like a fully-fledged operating system - things like task scheduling between tabs become more and more important. -- Steve On 11/14/2010 07:47 AM, stephen white wrote: > When I'm clicking through my news feeds, I've noticed that my web browser gets busy and crashes as I reach the WebGL parts. Having a quick look shows that WebGL starts working immediately, so the demo pages are firing off before I've gotten around to looking at them. > > Flash delays until it becomes the front window, which is how I can open many tabs while not having a problem. Would it be worth doing the same for WebGL, as most WebGL demos tend to be fairly intensive as a way of demonstrating a new feature and how much it can do. > > Once again, I think my old machine is being a guinea pig as the demos are intended to run on GPU but some of them will run on my CPU instead. However I think the problem is real, and a quick fix now could help improve the initial reaction that people have to WebGL? > > -- > steve...@ > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Sun Nov 14 07:57:44 2010 From: ste...@ (stephen white) Date: Mon, 15 Nov 2010 02:27:44 +1030 Subject: [Public WebGL] Delay display of WebGL? In-Reply-To: <4CE0037F.7060209@sjbaker.org> References: <4CE0037F.7060209@sjbaker.org> Message-ID: <8135F98E-9AED-4946-B1B3-C0CD9A772384@adam.com.au> On 15/11/2010, at 2:12 AM, Steve Baker wrote: > Since the browser can't distinguish these use-cases, I'd strongly oppose > a feature that automatically shut down execution when a WebGL page is > hidden. It would have to be something that the app itself does voluntarily. Flash waits until it is the front window to start working, but it doesn't pause or stop playing once it's gotten started. That seems to be a reasonable compromise that has precedence. -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ced...@ Sun Nov 14 08:08:14 2010 From: ced...@ (Cedric Vivier) Date: Mon, 15 Nov 2010 00:08:14 +0800 Subject: [Public WebGL] Delay display of WebGL? In-Reply-To: <4CE0037F.7060209@sjbaker.org> References: <4CE0037F.7060209@sjbaker.org> Message-ID: On Sun, Nov 14, 2010 at 23:42, Steve Baker wrote: > If not, then perhaps there is a case for adding a new timer event that > only triggers when the tab is visible. ? Then application writers could > use that event to trigger their draw() calls - and trigger the normal > timer event for critical operations that don't generate graphics. Yes, we discussed this at length few months ago : http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00057.html Unfortunately nothing much came out of it iirc (?)... but there is efforts outside of WebGL to add some kind of generic event that triggers before frame rendering (mozOnBeforePaint? Vlad?) IMHO adding another timer is more of a workaround than a long-term solution, as it 'promotes' developing an app for a particular framerate - something hard to do when the content can run on anything from cellphones to high-end desktops.. so some problems would not be fixed by this. An API that promotes framerate-independence on the other hand would solve most if not all the problems you pointed out, eg : http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00068.html (which ultimately should be what a "onBeforePaint" event would do - question is do we need something WebGL-pecific, I guess not) Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Sun Nov 14 08:51:32 2010 From: ste...@ (Steve Baker) Date: Sun, 14 Nov 2010 10:51:32 -0600 Subject: [Public WebGL] Delay display of WebGL? In-Reply-To: <8135F98E-9AED-4946-B1B3-C0CD9A772384@adam.com.au> References: <4CE0037F.7060209@sjbaker.org> <8135F98E-9AED-4946-B1B3-C0CD9A772384@adam.com.au> Message-ID: <4CE01394.9090806@sjbaker.org> On 11/14/2010 09:57 AM, stephen white wrote: > On 15/11/2010, at 2:12 AM, Steve Baker wrote: > >> Since the browser can't distinguish these use-cases, I'd strongly oppose >> a feature that automatically shut down execution when a WebGL page is >> hidden. It would have to be something that the app itself does voluntarily. >> > > Flash waits until it is the front window to start working, but it doesn't pause or stop playing once it's gotten started. That seems to be a reasonable compromise that has precedence. > I see how that helps your particular use pattern - but it doesn't help many other situations. When I'm playing some heavy-duty game - then need to go and check my web-mail or my FaceBook or something - I'd like the thing running in the "background" tab to use as little CPU/GPU time as possible. It can only do that if there is some kind of notification that it's hidden. If we need to add some new mechanism - then it ought to be more general than the flash approach. -- Stev ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Sun Nov 14 09:17:15 2010 From: ste...@ (Steve Baker) Date: Sun, 14 Nov 2010 11:17:15 -0600 Subject: [Public WebGL] Delay display of WebGL? In-Reply-To: References: <4CE0037F.7060209@sjbaker.org> Message-ID: <4CE0199B.7060501@sjbaker.org> On 11/14/2010 10:08 AM, Cedric Vivier wrote: > On Sun, Nov 14, 2010 at 23:42, Steve Baker wrote: > >> If not, then perhaps there is a case for adding a new timer event that >> only triggers when the tab is visible. Then application writers could >> use that event to trigger their draw() calls - and trigger the normal >> timer event for critical operations that don't generate graphics. >> > Yes, we discussed this at length few months ago : > http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00057.html > > Unfortunately nothing much came out of it iirc (?)... but there is > efforts outside of WebGL to add some kind of generic event that > triggers before frame rendering (mozOnBeforePaint? Vlad?) > > IMHO adding another timer is more of a workaround than a long-term > solution, as it 'promotes' developing an app for a particular > framerate - something hard to do when the content can run on anything > from cellphones to high-end desktops.. so some problems would not be > fixed by this. > > An API that promotes framerate-independence on the other hand would > solve most if not all the problems you pointed out, eg : > http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00068.html > > (which ultimately should be what a "onBeforePaint" event would do - > question is do we need something WebGL-pecific, I guess not) > Hmmm - tricky. We also need to look ahead to more powerful machines than we have right now...and correspondingly more sophisticated uses. In many games, the physics software needs to run at a fairly uniform frame rate that may be higher than the graphics rate. Framerate-independent physics is a tough sell - the core mathematics really isn't there yet - and physics is increasingly likely to use the GPU in CUDA-like ways. Networked applications may also place constraints on minimum update rates because of the need to time-out when the user navigates away from the page. There are other ikky issues relating to tabbed browsing: Suppose the app is using the camera and microphone via this new "rainbow" stuff? Can it/should it still be able to do that when the tab is hidden? IMHO, we need to let the app decide what it needs to run on a regular update basis - and what can be slowed down on slow hardware or halted altogether when the system doesn't have the user's attention (eg because it's in a background tab or (perhaps) hidden behind some other window - or because the screen/power-saver has kicked in). At a minimum, it would be nice if there were some query an application could make to ask if it's currently visible or not. Maybe a DOM thing you could read on the ? But I agree that this is not a WebGL issue - any JavaScript application might need this capability. WebGL just makes for much heavier apps that make the need more obvious/urgent. -- Stee ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From joh...@ Sun Nov 14 13:17:48 2010 From: joh...@ (Johannes Plapp) Date: Sun, 14 Nov 2010 22:17:48 +0100 Subject: AW: Re: [Public WebGL] Delay display of WebGL? Message-ID: I think window.onfocus and window.onblur tell you whether the tab is active or not - that should be sufficient for most current situations. Regards Steve Baker hat geschrieben: >On 11/14/2010 10:08 AM, Cedric Vivier wrote: >> On Sun, Nov 14, 2010 at 23:42, Steve Baker wrote: >> >>> If not, then perhaps there is a case for adding a new timer event that >>> only triggers when the tab is visible. Then application writers could >>> use that event to trigger their draw() calls - and trigger the normal >>> timer event for critical operations that don't generate graphics. >>> >> Yes, we discussed this at length few months ago : >> http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00057.html >> >> Unfortunately nothing much came out of it iirc (?)... but there is >> efforts outside of WebGL to add some kind of generic event that >> triggers before frame rendering (mozOnBeforePaint? Vlad?) >> >> IMHO adding another timer is more of a workaround than a long-term >> solution, as it 'promotes' developing an app for a particular >> framerate - something hard to do when the content can run on anything >> from cellphones to high-end desktops.. so some problems would not be >> fixed by this. >> >> An API that promotes framerate-independence on the other hand would >> solve most if not all the problems you pointed out, eg : >> http://www.khronos.org/webgl/public-mailing-list/archives/1004/msg00068.html >> >> (which ultimately should be what a "onBeforePaint" event would do - >> question is do we need something WebGL-pecific, I guess not) >> >Hmmm - tricky. > >We also need to look ahead to more powerful machines than we have right >now...and correspondingly more sophisticated uses. > >In many games, the physics software needs to run at a fairly uniform >frame rate that may be higher than the graphics rate. >Framerate-independent physics is a tough sell - the core mathematics >really isn't there yet - and physics is increasingly likely to use the >GPU in CUDA-like ways. Networked applications may also place >constraints on minimum update rates because of the need to time-out when >the user navigates away from the page. > >There are other ikky issues relating to tabbed browsing: Suppose the >app is using the camera and microphone via this new "rainbow" stuff? >Can it/should it still be able to do that when the tab is hidden? > >IMHO, we need to let the app decide what it needs to run on a regular >update basis - and what can be slowed down on slow hardware or halted >altogether when the system doesn't have the user's attention (eg because >it's in a background tab or (perhaps) hidden behind some other window - >or because the screen/power-saver has kicked in). > >At a minimum, it would be nice if there were some query an application >could make to ask if it's currently visible or not. Maybe a DOM thing >you could read on the ? > >But I agree that this is not a WebGL issue - any JavaScript application >might need this capability. WebGL just makes for much heavier apps >that make the need more obvious/urgent. > > -- Stee > > >----------------------------------------------------------- >You are currently subscribed to public_webgl...@ >To unsubscribe, send an email to majordomo...@ with >the following command in the body of your email: > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Sun Nov 14 19:01:02 2010 From: cal...@ (Mark Callow) Date: Mon, 15 Nov 2010 12:01:02 +0900 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> <4CDD004F.8060708@hicorp.co.jp> <4CDD0A49.5060606@hicorp.co.jp> Message-ID: <4CE0A26E.2070909@hicorp.co.jp> Hi Thatcher, Thank you very much for your kind help. I really liked the idea of the div locator, then I realized that I can achieve the same end by simply querying the getOffsetTop() on my canvas. Unfortunately, your example suffers from the same issue that prompted my posting in the first place: body.clientHeight returns a height that accomodates the elements on the page at their current size. In the case of your example it returns 78, while tl.getOffsetTop() returns 94. It looks like the height only goes to the bottom of the button and does even include padding, border & margin below the button. So I never see the blue div. Because of this, I need to use window.innerHeight and therefore still need to know the heights of the body padding, border and margin so I can subtract them at the bottom. Until I can figure out how to query or calculate these values, I am setting them myself and saving the values for later use in resize. Regards -Mark On 12/11/2010 19:43, Thatcher Ulrich wrote: > Re scrollbars -- on the body element, set "overflow: hidden;" to > inhibit scrollbars. > > -T > > On Fri, Nov 12, 2010 at 11:40 AM, Thatcher Ulrich wrote: >> This sort of works for me -- using a 0x0 div to locate the top of the >> canvas area, and doing body.clientHeight - locator.offsetTop to >> compute the remaining height. >> >> There are some wrinkles having to do with when the body >> clientHeight/clientWidth is queried, and scrollbars, but you can >> probably work that out. >> >> -T >> >> ---- >> >> >> >> >> >> >>

One line of text.

>>

> onclick="resize_blue_div()" /> >>

>>
>>
>>
>>
>> >> >> >> >> On Fri, Nov 12, 2010 at 10:35 AM, Mark Callow wrote: >>> I have a line of text in a
followed by a block canvas. I want to size >>> the canvas so it fills the rest of the window below the line of text. If I >>> set the canvas's CSS height to 100% the canvas is given a size equal to the >>> window size less the body's margin, border and padding. Therefore the >>> combination of the line of text and the canvas is too big for the window. A >>> scrollbar appears and the bottom part of my canvas is cut off. >>> >>> To size the canvas myself, I need to do something like the following >>> pseudo-code: >>> >>> canvasHeight = window.innerHeight - body margin height * 2 - body padding >>> height * 2 ; >>> canvasHeight -= body border height * 2; >>> canvasHeight -= text label height; (including any margin on the text); >>> >>> clientHeight gives me the content area height + padding. offsetHeight gives >>> me clientHeight + border. So I can see how to get the border height but not >>> how to get margin and padding heights. >>> >>> Regards >>> >>> -Mark >>> >>> >>> >>> On 12/11/2010 18:19, Thatcher Ulrich wrote: >>> >>> What exactly are you trying to measure? You might be able to get what >>> you want by putting a spacer DIV where you want the canvas area (with >>> block positioning) and let the canvas have absolute positioning in the >>> same spot. The DIV will participate in the page layout, and you can >>> control the canvas layout by querying the DIV and setting the canvas >>> size via Javascript. >>> >>> Though I'm not sure what your goal is. There may be a simpler way to >>> get what you want. >>> >>> -T >>> >>> On Fri, Nov 12, 2010 at 9:52 AM, Mark Callow >>> wrote: >>> >>> When I have other elements on a page together with a canvas, in order to >>> compute an ideal canvas size, I need to query, or compute, things like the >>> margin, border and padding heights of elements, particularly the body >>> element. I have not so far found any way through the DOM to obtain this >>> information. The queries I've found return (content area + padding) or >>> (content area + padding + border). I have found no query whose result is >>> influenced by the margin nor any to tell me the padding. >>> >>> Style queries return empty strings unless a style is actually set on the >>> element so are useless for elements having default settings. >>> >>> Can anyone suggest a way to determine this information? >>> >>> Regards >>> >>> -Mark >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From cal...@ Sun Nov 14 23:31:48 2010 From: cal...@ (Mark Callow) Date: Mon, 15 Nov 2010 16:31:48 +0900 Subject: [Public WebGL] Getting FF4 to use ANGLE Message-ID: <4CE0E1E4.5090407@hicorp.co.jp> Hi, I'm trying to see if I can get WebGL content to run accelerated on my notebook computer (Panasonic Let's Note with a 1.06GHz Core2 CPU, an on-board Intel GMA 950 graphics chip and DirectX 9). The GL driver for this chip is reputedly not good so I want to try ANGLE. I got the latest Minefield build (4.0b8pre). webgl.mochitest_native_gl is at the default "false" setting. I thought this would mean it would use ANGLE but I haven't had any luck running any of the demos from the wiki. Most indicate inability to obtain a webgl context but at least 1 just gives an empty page. How do I force FF to use ANGLE? P.S. Does the Android version of FF4 support WebGL yet? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From van...@ Sun Nov 14 23:46:21 2010 From: van...@ (Vangelis Kokkevis) Date: Sun, 14 Nov 2010 23:46:21 -0800 Subject: [Public WebGL] Getting FF4 to use ANGLE In-Reply-To: <4CE0E1E4.5090407@hicorp.co.jp> References: <4CE0E1E4.5090407@hicorp.co.jp> Message-ID: Hi Mark, I can't speak for the other browsers but have you tried running Chrome? It uses ANGLE by default on windows. Vangelis On Sun, Nov 14, 2010 at 11:31 PM, Mark Callow wrote: > Hi, > > I'm trying to see if I can get WebGL content to run accelerated on my > notebook computer (Panasonic Let's Note with a 1.06GHz Core2 CPU, an > on-board Intel GMA 950 graphics chip and DirectX 9). The GL driver for this > chip is reputedly not good so I want to try ANGLE. I got the latest > Minefield build (4.0b8pre). webgl.mochitest_native_gl is at the default > "false" setting. I thought this would mean it would use ANGLE but I haven't > had any luck running any of the demos from the wiki. Most indicate inability > to obtain a webgl context but at least 1 just gives an empty page. > > How do I force FF to use ANGLE? > > P.S. Does the Android version of FF4 support WebGL yet? > > Regards > > -Mark > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon Nov 15 01:25:21 2010 From: cal...@ (Mark Callow) Date: Mon, 15 Nov 2010 18:25:21 +0900 Subject: [Public WebGL] Getting FF4 to use ANGLE In-Reply-To: References: <4CE0E1E4.5090407@hicorp.co.jp> Message-ID: <4CE0FC81.8000503@hicorp.co.jp> Funny you should ask that. I have just tried it. It appears the GMA 950's D3D9 driver isn't that great either. Gregg's aquarium demo (http://websamples.googlecode.com/hg/aquarium/aquarium.html) runs but looks terrible. Many triangles aren't textured and which are & aren't changes with each frame causing horrible flashing. I'm running Chrome Canary build 9.0.576.0. When I run it on my NVIDIA-equipped desktop computer, using the continuous build Chrome 9.0.583.0 (66100), without "--use-gl=desktop", the aquarium looks fine so the problem appearsrelated to the Intel graphics driver, but oops, it just froze. Oops. The canary build on my notebook computer just froze too. Attached is a screen shot showing the incorrect rendering. As for the freeze, in both cases, when I restarted Chrome, the demo would run for only a few frames then freeze again. I tried many times. Eventually I rebooted the notebook and the demo is running again. On the desktop side, I reinstituted "-use-gl=desktop" and the demo runs again. Hmm. The demo has now been running on the rebooted notebook for about 10 minutes, looks ugly, but keeps on moving. Meanwhile the desktop machine blue-screened after (1) Chrome 9.0.583.0 (66100) seemed to hang when trying to reload the aquarium demo, (2) I clicked the 'X' button and (3) clicked 'end now' to the dialog telling me the program was unresponsive. What fun. :-( Regards -Mark On 15/11/2010 16:46, Vangelis Kokkevis wrote: > Hi Mark, > I can't speak for the other browsers but have you tried running > Chrome? It uses ANGLE by default on windows. > > Vangelis > > > On Sun, Nov 14, 2010 at 11:31 PM, Mark Callow > > wrote: > > Hi, > > I'm trying to see if I can get WebGL content to run accelerated on > my notebook computer (Panasonic Let's Note with a 1.06GHz Core2 > CPU, an on-board Intel GMA 950 graphics chip and DirectX 9). The > GL driver for this chip is reputedly not good so I want to try > ANGLE. I got the latest Minefield build (4.0b8pre). > webgl.mochitest_native_gl is at the default "false" setting. I > thought this would mean it would use ANGLE but I haven't had any > luck running any of the demos from the wiki. Most indicate > inability to obtain a webgl context but at least 1 just gives an > empty page. > > How do I force FF to use ANGLE? > > P.S. Does the Android version of FF4 support WebGL yet? > > Regards > > -Mark > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: aquarium-bad.jpg Type: image/jpeg Size: 55923 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From ste...@ Mon Nov 15 01:42:50 2010 From: ste...@ (stephen white) Date: Mon, 15 Nov 2010 20:12:50 +1030 Subject: [Public WebGL] Delay display of WebGL? In-Reply-To: <4CE01394.9090806@sjbaker.org> References: <4CE0037F.7060209@sjbaker.org> <8135F98E-9AED-4946-B1B3-C0CD9A772384@adam.com.au> <4CE01394.9090806@sjbaker.org> Message-ID: <72E0452D-6ECA-47E6-9B33-163E69211FC2@adam.com.au> On 15/11/2010, at 3:21 AM, Steve Baker wrote: > I see how that helps your particular use pattern - but it doesn't help > many other situations. When I'm playing some heavy-duty game I agree with your extended discussion, I'm just a bit concerned that we may focus on what could be done to the extent that the "front before display" hack doesn't go in, much like the last time this similar discussion came around. :) "Front before display" is pretty crappy, but it's what Flash does and it does have a good benefit for those of us who open a lot of tabs then read through them. If it can be improved, all the better, but just this alone is worthwhile. -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From ste...@ Mon Nov 15 04:14:01 2010 From: ste...@ (Steve Baker) Date: Mon, 15 Nov 2010 06:14:01 -0600 Subject: [Public WebGL] Getting FF4 to use ANGLE In-Reply-To: References: <4CE0E1E4.5090407@hicorp.co.jp> Message-ID: <4CE12409.8070603@sjbaker.org> My son's netbook has the GMA 950 chip - it runs WebGL in Chrome - but not (so far) in Firefox/Minefield. Intel graphics drivers are definitely not the best of the bunch and the GMA 950 is decidedly borderline for WebGL. The hardware doesn't support vertex shaders - so the driver runs them in the CPU and hence your vertex performance rates are poor by desktop standards (Do you remember the days before hardware transform and lighting?...Think that!). It has hardware fragment shaders - but they are severely limited. I have to use greatly simplified shaders to get them to compile on the GMA 950. The pixel fill rate is abysmal - so you'll want to stick with small windows and simple shaders. The only OpenGL support for that chip is OpenGL1.4 - which is a pre-shader API and therefore doesn't support WebGL at all. ANGLE is the only option for this chip. I really wish Intel would get out of the graphics business! Having said that, it does run my game - albeit at only about 9 frames a second in a small window and 4 frames a second full-screen. -- Steve On 11/15/2010 01:46 AM, Vangelis Kokkevis wrote: > Hi Mark, > I can't speak for the other browsers but have you tried running > Chrome? It uses ANGLE by default on windows. > > Vangelis > > > On Sun, Nov 14, 2010 at 11:31 PM, Mark Callow > > wrote: > > Hi, > > I'm trying to see if I can get WebGL content to run accelerated on > my notebook computer (Panasonic Let's Note with a 1.06GHz Core2 > CPU, an on-board Intel GMA 950 graphics chip and DirectX 9). The > GL driver for this chip is reputedly not good so I want to try > ANGLE. I got the latest Minefield build (4.0b8pre). > webgl.mochitest_native_gl is at the default "false" setting. I > thought this would mean it would use ANGLE but I haven't had any > luck running any of the demos from the wiki. Most indicate > inability to obtain a webgl context but at least 1 just gives an > empty page. > > How do I force FF to use ANGLE? > > P.S. Does the Android version of FF4 support WebGL yet? > > Regards > > -Mark > > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From bja...@ Mon Nov 15 04:50:51 2010 From: bja...@ (Benoit Jacob) Date: Mon, 15 Nov 2010 04:50:51 -0800 (PST) Subject: [Public WebGL] Getting FF4 to use ANGLE In-Reply-To: <4CE0E1E4.5090407@hicorp.co.jp> Message-ID: <150291376.348562.1289825451114.JavaMail.root@cm-mail03.mozilla.org> ----- Original Message ----- > Hi, > > > I'm trying to see if I can get WebGL content to run accelerated on my > notebook computer (Panasonic Let's Note with a 1.06GHz Core2 CPU, an > on-board Intel GMA 950 graphics chip and DirectX 9). The GL driver for > this chip is reputedly not good so I want to try ANGLE. I got the > latest Minefield build (4.0b8pre). webgl.mochitest_native_gl is at the > default "false" setting. I thought this would mean it would use ANGLE > but I haven't had any luck running any of the demos from the wiki. No, webgl.mochitest_native_gl only affects running the mochitest, i.e. the WebGL conformance tests integrated into our test suite. > Most indicate inability to obtain a webgl context but at least 1 just > gives an empty page. > > > How do I force FF to use ANGLE? Currently you can't with plain FF although Vlad might know more (I think he made ANGLE-enabled builds a while ago). > > > P.S. Does the Android version of FF4 support WebGL yet? Letting Vlad answer this one :-) WebGL on android is working but I don't know if it's enabled in standard builds. Benoit > > > Regards > > > > -Mark ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From tu...@ Mon Nov 15 09:02:15 2010 From: tu...@ (Thatcher Ulrich) Date: Mon, 15 Nov 2010 18:02:15 +0100 Subject: [Public WebGL] Mysterious extra padding below canvas In-Reply-To: <4CE0A26E.2070909@hicorp.co.jp> References: <4CDBA672.8020808@hicorp.co.jp> <16FD352C-F6FC-48C4-BFA6-52F4FE51F2B9@apple.com> <4CDCCAE4.4050303@hicorp.co.jp> <4CDD004F.8060708@hicorp.co.jp> <4CDD0A49.5060606@hicorp.co.jp> <4CE0A26E.2070909@hicorp.co.jp> Message-ID: That's odd; my example works for me in Safari, FF and Chrome on OSX. I put it here so you can try it verbatim: http://tulrich.com/tmp/layout.html There could be issues with the timing of the queries, or if our platforms/browsers differ. -T On Mon, Nov 15, 2010 at 4:01 AM, Mark Callow wrote: > Hi Thatcher, > > Thank you very much for your kind help. I really liked the idea of the div > locator, then I realized that I can achieve the same end by simply querying > the getOffsetTop() on my canvas. > > Unfortunately, your example suffers from the same issue that prompted my > posting in the first place: body.clientHeight returns a height that > accomodates the elements on the page at their current size. In the case of > your example it returns 78, while tl.getOffsetTop() returns 94. It looks > like the height only goes to the bottom of the button and does even include > padding, border & margin below the button. So I never see the blue div. > > Because of this, I need to use window.innerHeight and therefore still need > to know the heights of the body padding, border and margin so I can subtract > them at the bottom. Until I can figure out how to query or calculate these > values, I am setting them myself and saving the values for later use in > resize. > > Regards > > -Mark > > > > On 12/11/2010 19:43, Thatcher Ulrich wrote: > > Re scrollbars -- on the body element, set "overflow: hidden;" to > inhibit scrollbars. > > -T > > On Fri, Nov 12, 2010 at 11:40 AM, Thatcher Ulrich wrote: > > This sort of works for me -- using a 0x0 div to locate the top of the > canvas area, and doing body.clientHeight - locator.offsetTop to > compute the remaining height. > > There are some wrinkles having to do with when the body > clientHeight/clientWidth is queried, and scrollbars, but you can > probably work that out. > > -T > > ---- > > > ? > ? ? > ? > ? > ? ?

One line of text.

> ? ?

onclick="resize_blue_div()" /> > ? ?

> ? ?
> ? ? ?
> ? ? ?
> ? ?
> ? > > > > On Fri, Nov 12, 2010 at 10:35 AM, Mark Callow > wrote: > > I have a line of text in a
followed by a block canvas. I want to size > the canvas so it fills the rest of the window below the line of text. If I > set the canvas's CSS height to 100% the canvas is given a size equal to the > window? size less the body's margin, border and padding. Therefore the > combination of the line of text and the canvas is too big for the window. A > scrollbar appears and the bottom part of my canvas is cut off. > > To size the canvas myself, I need to do something like the following > pseudo-code: > > canvasHeight = window.innerHeight - body margin height * 2 - body padding > height * 2 ; > canvasHeight -= body border height * 2; > canvasHeight -= text label height; (including any margin on the text); > > clientHeight gives me the content area height + padding. offsetHeight gives > me clientHeight + border. So I can see how to get the border height but not > how to get margin and padding heights. > > Regards > > -Mark > > > > On 12/11/2010 18:19, Thatcher Ulrich wrote: > > What exactly are you trying to measure? ?You might be able to get what > you want by putting a spacer DIV where you want the canvas area (with > block positioning) and let the canvas have absolute positioning in the > same spot. ?The DIV will participate in the page layout, and you can > control the canvas layout by querying the DIV and setting the canvas > size via Javascript. > > Though I'm not sure what your goal is. ?There may be a simpler way to > get what you want. > > -T > > On Fri, Nov 12, 2010 at 9:52 AM, Mark Callow > wrote: > > When I have other elements on a page together with a canvas, in order to > compute an ideal canvas size, I need to query, or compute, things like the > margin, border and padding heights of elements, particularly the body > element. I have not so far found any way through the DOM to obtain this > information.? The queries I've found return (content area + padding) or > (content area + padding + border). I have found no query whose result is > influenced by the margin nor any to tell me the padding. > > Style queries return empty strings unless a style is actually set on the > element so are useless for elements having default settings. > > Can anyone suggest a way to determine this information? > > Regards > > -Mark > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Nov 15 11:20:49 2010 From: vla...@ (Vladimir Vukicevic) Date: Mon, 15 Nov 2010 11:20:49 -0800 (PST) Subject: [Public WebGL] Getting FF4 to use ANGLE In-Reply-To: <4CE0E1E4.5090407@hicorp.co.jp> Message-ID: <376364760.352134.1289848849192.JavaMail.root@cm-mail03.mozilla.org> You can install an extension for ANGLE (relatively recent angle + some patches for some ANGLE bugs) from http://people.mozilla.com/~vladimir/misc/angleproject.xpi . No restart needed after the install. It should be coming into the core fairly soon. - Vlad ----- Original Message ----- > Hi, > > > I'm trying to see if I can get WebGL content to run accelerated on my > notebook computer (Panasonic Let's Note with a 1.06GHz Core2 CPU, an > on-board Intel GMA 950 graphics chip and DirectX 9). The GL driver for > this chip is reputedly not good so I want to try ANGLE. I got the > latest Minefield build (4.0b8pre). webgl.mochitest_native_gl is at the > default "false" setting. I thought this would mean it would use ANGLE > but I haven't had any luck running any of the demos from the wiki. > Most indicate inability to obtain a webgl context but at least 1 just > gives an empty page. > > > How do I force FF to use ANGLE? > > > P.S. Does the Android version of FF4 support WebGL yet? > > > Regards > > > > -Mark ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Nov 15 13:56:29 2010 From: vla...@ (Vladimir Vukicevic) Date: Mon, 15 Nov 2010 13:56:29 -0800 (PST) Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> One of the major issues that came up during the last f2f was that the current canvas model is not the most efficient for implementing on hardware, especially on mobile hardware. The current model was based on how the 2D canvas works: drawing happens during content JS script, and as soon as control is returned to the browser, it's supposed to be presented for display. Content can also read back the current contents of the displayed image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both via toDataURL). However, most 3D hardware doesn't really want to work like that -- they're optimized for double-buffering, where you draw a scene to the back buffer, and then swap buffers; after a swap, the new back buffer contains garbage. Implementing the current canvas semantics is not a big issue on the desktop, because there is cpu/gpu/bandwidth to spare, but it's a pretty big deal on mobile. We identified a few different options: 1) Do nothing. Leave things as it is. There would be fairly significant overhead that all apps would pay, even if they never want to call readPixels or toDataURL. 2) Add explicit double-buffering to WebGL canvases, and add an explicit present() call. This complicates things for developers, because they need to then actually make this present() call, and can potentially result in higher memory usage due to some implementations needing to keep around both a front and back buffer, where before they could be effectively single-buffered. 3) Add implicit double-buffering to canvas. Follow the same semantics as canvas does currently -- swap happens whenever control is returned to the browser -- but always enforce an uninitialized/cleared back buffer after each swap. 4) Like #2 and #3, by adding a context attribute that allows the author to choose which they would want. 5) Like #1 (do nothing), but add a context attribute for the author to indicate whether readback from the window/canvas buffer will ever be done. If it's set to true, then dimply disallow readPixels/toDataURL when framebuffer 0 is bound (or have them always return all black). We identified a few different use cases that should be considered. Printing and screenshots were two, along with using a WebGL canvas as a texImage2D source, and using a WebGL canvas as a 2D canvas drawImage source. Note that even with implicit double-buffering, it's possible to use a FBO to build up a scene across many events and only draw it to the drawbuffer once (just like you can do today, with #1). Adding context attributes complicates the implementations, potentially significantly, so I'd like to avoid 4 and 5. I'd lean towards #3, but what are the list's thoughts on this? - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From bco...@ Mon Nov 15 14:16:16 2010 From: bco...@ (Brian Cornell) Date: Mon, 15 Nov 2010 14:16:16 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> References: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> Message-ID: Another use case to consider: Option #2 would allow applications to use WebWorkers for mutitheaded work that is used in rendering. Say I want to: a) do some expensive rendering that takes ~10 ms. b) do some expensive computation that takes ~10 ms (but doesn't involve rendering) c) render something based on the computation in b that takes ~2 ms Because receiving a message from a worker requires returning control to the browser, my options currently are: X: a, b, and c sequentially with no workers: ~22 ms Y: start b in a worker, then to a, do c in the event handler for the response from b: ~12 ms but I end up returning control to the browser with a partially rendered scene and potentially having that displayed to the user before the scene is finished Z: Start b in a worker, do A rendered into a texture, in the event handler for the response from b, render the texture to the screen and do c: ~12ms plus the time to copy the texture, but I use more memory and lose support for multisampling the rendering of a. Now if we had option #2 where I could explicitly swap when I'm ready to display, then I could have the best combination: Start b in a worker Draw a to the screen In b's event handler draw c to the screen and swap Total: 12 ms with no downsides (on a multi-core machine) So I would vote for a solution like #2 where one of the context creation attribute specifies whether I want manual double buffering. If I don't set that option or set it to false, the current behavior is maintained, whether double buffering is used in some way or not. If I set it to true, then the WebGL implementation will attempt to use double buffering if possible. If it succeeds in using double buffering (which I can query through a getParameter call), then I manually switch buffers using present() as mentioned above, and nothing will be displayed until I do. This would give both simplicity for apps that don't care, and functionality for performance critical applications. -Brian On Mon, Nov 15, 2010 at 1:56 PM, Vladimir Vukicevic wrote: > > One of the major issues that came up during the last f2f was that the > current canvas model is not the most efficient for implementing on hardware, > especially on mobile hardware. The current model was based on how the 2D > canvas works: drawing happens during content JS script, and as soon as > control is returned to the browser, it's supposed to be presented for > display. Content can also read back the current contents of the displayed > image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both > via toDataURL). > > However, most 3D hardware doesn't really want to work like that -- they're > optimized for double-buffering, where you draw a scene to the back buffer, > and then swap buffers; after a swap, the new back buffer contains garbage. > Implementing the current canvas semantics is not a big issue on the > desktop, because there is cpu/gpu/bandwidth to spare, but it's a pretty big > deal on mobile. > > We identified a few different options: > > 1) Do nothing. Leave things as it is. There would be fairly significant > overhead that all apps would pay, even if they never want to call readPixels > or toDataURL. > > 2) Add explicit double-buffering to WebGL canvases, and add an explicit > present() call. This complicates things for developers, because they need > to then actually make this present() call, and can potentially result in > higher memory usage due to some implementations needing to keep around both > a front and back buffer, where before they could be effectively > single-buffered. > > 3) Add implicit double-buffering to canvas. Follow the same semantics as > canvas does currently -- swap happens whenever control is returned to the > browser -- but always enforce an uninitialized/cleared back buffer after > each swap. > > 4) Like #2 and #3, by adding a context attribute that allows the author to > choose which they would want. > > 5) Like #1 (do nothing), but add a context attribute for the author to > indicate whether readback from the window/canvas buffer will ever be done. > If it's set to true, then dimply disallow readPixels/toDataURL when > framebuffer 0 is bound (or have them always return all black). > > We identified a few different use cases that should be considered. > Printing and screenshots were two, along with using a WebGL canvas as a > texImage2D source, and using a WebGL canvas as a 2D canvas drawImage source. > > Note that even with implicit double-buffering, it's possible to use a FBO > to build up a scene across many events and only draw it to the drawbuffer > once (just like you can do today, with #1). Adding context attributes > complicates the implementations, potentially significantly, so I'd like to > avoid 4 and 5. > > I'd lean towards #3, but what are the list's thoughts on this? > > - Vlad > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Mon Nov 15 14:22:19 2010 From: vla...@ (Vladimir Vukicevic) Date: Mon, 15 Nov 2010 14:22:19 -0800 (PST) Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: Message-ID: <1213274475.354499.1289859739780.JavaMail.root@cm-mail03.mozilla.org> ----- Original Message ----- > Another use case to consider: Option #2 would allow applications to > use WebWorkers for mutitheaded work that is used in rendering. Say I > want to: Well, no, it wouldn't -- there's no way to create a WebGL context in a worker (or any other DOM object), and there's no way to pass a WebGL context to a worker. In the future, assuming a way was added to create a WebGL context on a worker, the way you'd want to do this is with two contexts that share resources, one being a purely offscreen worker context and one being an on-screen main thread context. - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From bco...@ Mon Nov 15 14:25:42 2010 From: bco...@ (Brian Cornell) Date: Mon, 15 Nov 2010 14:25:42 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: <1213274475.354499.1289859739780.JavaMail.root@cm-mail03.mozilla.org> References: <1213274475.354499.1289859739780.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Mon, Nov 15, 2010 at 2:22 PM, Vladimir Vukicevic wrote: > > > ----- Original Message ----- > > Another use case to consider: Option #2 would allow applications to > > use WebWorkers for mutitheaded work that is used in rendering. Say I > > want to: > > Well, no, it wouldn't -- there's no way to create a WebGL context in a > worker (or any other DOM object), and there's no way to pass a WebGL context > to a worker. > That's why I explicitly said no rendering in the worker, just computation. Computation used for rendering could be done in a worker, result sent back as a stringified object like normal, and then rendered on the main thread based on the result of the computation (in the message received event handler for receiving a message from the worker). > In the future, assuming a way was added to create a WebGL context on a > worker, the way you'd want to do this is with two contexts that share > resources, one being a purely offscreen worker context and one being an > on-screen main thread context. > > - Vlad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben...@ Mon Nov 15 14:26:37 2010 From: Ben...@ (Ben Vanik) Date: Mon, 15 Nov 2010 22:26:37 +0000 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: References: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <86A8C2D991159E449E63BD326AAF923D03CB5D6A@tk5ex14mbxc105.redmond.corp.microsoft.com> I also like option 2 - I agree that it does require the application author to be more aware of the end of their activity but with respect to the rest of the complexity of using WebGL to do anything I see that as one of the simplest possible additions. I'd argue against making it an option, though, as it would make it easier for developers to unknowingly opt-out of potential browser optimizations or make bad decisions - 'works fine without double buffering, so why do it?' without thinking of the implications on other platforms. Plus, it mirrors most/all desktop graphics APIs where explicit swaps/presents are required at the end of frames. As an OpenGL/DirectX dev it still feels weird to me to not have anything at the end of my render method :) -- Ben Vanik Live Labs / Seadragon From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Brian Cornell Sent: Monday, November 15, 2010 2:16 PM To: Vladimir Vukicevic Cc: public webgl Subject: Re: [Public WebGL] double-buffering and back buffer preservation Another use case to consider: Option #2 would allow applications to use WebWorkers for mutitheaded work that is used in rendering. Say I want to: a) do some expensive rendering that takes ~10 ms. b) do some expensive computation that takes ~10 ms (but doesn't involve rendering) c) render something based on the computation in b that takes ~2 ms Because receiving a message from a worker requires returning control to the browser, my options currently are: X: a, b, and c sequentially with no workers: ~22 ms Y: start b in a worker, then to a, do c in the event handler for the response from b: ~12 ms but I end up returning control to the browser with a partially rendered scene and potentially having that displayed to the user before the scene is finished Z: Start b in a worker, do A rendered into a texture, in the event handler for the response from b, render the texture to the screen and do c: ~12ms plus the time to copy the texture, but I use more memory and lose support for multisampling the rendering of a. Now if we had option #2 where I could explicitly swap when I'm ready to display, then I could have the best combination: Start b in a worker Draw a to the screen In b's event handler draw c to the screen and swap Total: 12 ms with no downsides (on a multi-core machine) So I would vote for a solution like #2 where one of the context creation attribute specifies whether I want manual double buffering. If I don't set that option or set it to false, the current behavior is maintained, whether double buffering is used in some way or not. If I set it to true, then the WebGL implementation will attempt to use double buffering if possible. If it succeeds in using double buffering (which I can query through a getParameter call), then I manually switch buffers using present() as mentioned above, and nothing will be displayed until I do. This would give both simplicity for apps that don't care, and functionality for performance critical applications. -Brian On Mon, Nov 15, 2010 at 1:56 PM, Vladimir Vukicevic > wrote: One of the major issues that came up during the last f2f was that the current canvas model is not the most efficient for implementing on hardware, especially on mobile hardware. The current model was based on how the 2D canvas works: drawing happens during content JS script, and as soon as control is returned to the browser, it's supposed to be presented for display. Content can also read back the current contents of the displayed image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both via toDataURL). However, most 3D hardware doesn't really want to work like that -- they're optimized for double-buffering, where you draw a scene to the back buffer, and then swap buffers; after a swap, the new back buffer contains garbage. Implementing the current canvas semantics is not a big issue on the desktop, because there is cpu/gpu/bandwidth to spare, but it's a pretty big deal on mobile. We identified a few different options: 1) Do nothing. Leave things as it is. There would be fairly significant overhead that all apps would pay, even if they never want to call readPixels or toDataURL. 2) Add explicit double-buffering to WebGL canvases, and add an explicit present() call. This complicates things for developers, because they need to then actually make this present() call, and can potentially result in higher memory usage due to some implementations needing to keep around both a front and back buffer, where before they could be effectively single-buffered. 3) Add implicit double-buffering to canvas. Follow the same semantics as canvas does currently -- swap happens whenever control is returned to the browser -- but always enforce an uninitialized/cleared back buffer after each swap. 4) Like #2 and #3, by adding a context attribute that allows the author to choose which they would want. 5) Like #1 (do nothing), but add a context attribute for the author to indicate whether readback from the window/canvas buffer will ever be done. If it's set to true, then dimply disallow readPixels/toDataURL when framebuffer 0 is bound (or have them always return all black). We identified a few different use cases that should be considered. Printing and screenshots were two, along with using a WebGL canvas as a texImage2D source, and using a WebGL canvas as a 2D canvas drawImage source. Note that even with implicit double-buffering, it's possible to use a FBO to build up a scene across many events and only draw it to the drawbuffer once (just like you can do today, with #1). Adding context attributes complicates the implementations, potentially significantly, so I'd like to avoid 4 and 5. I'd lean towards #3, but what are the list's thoughts on this? - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@. To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Mon Nov 15 14:34:05 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 15 Nov 2010 14:34:05 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> References: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Mon, Nov 15, 2010 at 1:56 PM, Vladimir Vukicevic wrote: > > One of the major issues that came up during the last f2f was that the > current canvas model is not the most efficient for implementing on hardware, > especially on mobile hardware. The current model was based on how the 2D > canvas works: drawing happens during content JS script, and as soon as > control is returned to the browser, it's supposed to be presented for > display. Content can also read back the current contents of the displayed > image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both > via toDataURL). > > However, most 3D hardware doesn't really want to work like that -- they're > optimized for double-buffering, where you draw a scene to the back buffer, > and then swap buffers; after a swap, the new back buffer contains garbage. > Implementing the current canvas semantics is not a big issue on the > desktop, because there is cpu/gpu/bandwidth to spare, but it's a pretty big > deal on mobile. > > We identified a few different options: > > 1) Do nothing. Leave things as it is. There would be fairly significant > overhead that all apps would pay, even if they never want to call readPixels > or toDataURL. > > 2) Add explicit double-buffering to WebGL canvases, and add an explicit > present() call. This complicates things for developers, because they need > to then actually make this present() call, and can potentially result in > higher memory usage due to some implementations needing to keep around both > a front and back buffer, where before they could be effectively > single-buffered. > > 3) Add implicit double-buffering to canvas. Follow the same semantics as > canvas does currently -- swap happens whenever control is returned to the > browser -- but always enforce an uninitialized/cleared back buffer after > each swap. > > 4) Like #2 and #3, by adding a context attribute that allows the author to > choose which they would want. > > 5) Like #1 (do nothing), but add a context attribute for the author to > indicate whether readback from the window/canvas buffer will ever be done. > If it's set to true, then dimply disallow readPixels/toDataURL when > framebuffer 0 is bound (or have them always return all black). > > We identified a few different use cases that should be considered. > Printing and screenshots were two, along with using a WebGL canvas as a > texImage2D source, and using a WebGL canvas as a 2D canvas drawImage source. > > Note that even with implicit double-buffering, it's possible to use a FBO > to build up a scene across many events and only draw it to the drawbuffer > once (just like you can do today, with #1). Adding context attributes > complicates the implementations, potentially significantly, so I'd like to > avoid 4 and 5. > > I'd lean towards #3, but what are the list's thoughts on this? > I'm fine with 3 with the caveats that I mentioned before. Namely that toDataURL, readPixels, drawImage, texImage2D(canvas3d, ...) all work as expected. Namely that reading the canvas through any of those calls gives you the contents what you see displayed until first draw call after a swap. I mentioned 2 ways to implement that. Either don't issue the clear until the first draw call after a swap or, read from the display buffer after a swap, read from the draw buffer after a draw, > > - Vlad > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Nov 15 16:53:40 2010 From: cma...@ (Chris Marrin) Date: Mon, 15 Nov 2010 16:53:40 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: References: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <9BA6993A-1DC9-4EC9-8F3D-5866161CC84B@apple.com> On Nov 15, 2010, at 2:34 PM, Gregg Tavares (wrk) wrote: > > > On Mon, Nov 15, 2010 at 1:56 PM, Vladimir Vukicevic wrote: > > One of the major issues that came up during the last f2f was that the current canvas model is not the most efficient for implementing on hardware, especially on mobile hardware. The current model was based on how the 2D canvas works: drawing happens during content JS script, and as soon as control is returned to the browser, it's supposed to be presented for display. Content can also read back the current contents of the displayed image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both via toDataURL). > > However, most 3D hardware doesn't really want to work like that -- they're optimized for double-buffering, where you draw a scene to the back buffer, and then swap buffers; after a swap, the new back buffer contains garbage. Implementing the current canvas semantics is not a big issue on the desktop, because there is cpu/gpu/bandwidth to spare, but it's a pretty big deal on mobile. > > We identified a few different options: > > 1) Do nothing. Leave things as it is. There would be fairly significant overhead that all apps would pay, even if they never want to call readPixels or toDataURL. > > 2) Add explicit double-buffering to WebGL canvases, and add an explicit present() call. This complicates things for developers, because they need to then actually make this present() call, and can potentially result in higher memory usage due to some implementations needing to keep around both a front and back buffer, where before they could be effectively single-buffered. > > 3) Add implicit double-buffering to canvas. Follow the same semantics as canvas does currently -- swap happens whenever control is returned to the browser -- but always enforce an uninitialized/cleared back buffer after each swap. > > 4) Like #2 and #3, by adding a context attribute that allows the author to choose which they would want. > > 5) Like #1 (do nothing), but add a context attribute for the author to indicate whether readback from the window/canvas buffer will ever be done. If it's set to true, then dimply disallow readPixels/toDataURL when framebuffer 0 is bound (or have them always return all black). > > We identified a few different use cases that should be considered. Printing and screenshots were two, along with using a WebGL canvas as a texImage2D source, and using a WebGL canvas as a 2D canvas drawImage source. > > Note that even with implicit double-buffering, it's possible to use a FBO to build up a scene across many events and only draw it to the drawbuffer once (just like you can do today, with #1). Adding context attributes complicates the implementations, potentially significantly, so I'd like to avoid 4 and 5. > > I'd lean towards #3, but what are the list's thoughts on this? > > I'm fine with 3 with the caveats that I mentioned before. Namely that toDataURL, readPixels, drawImage, texImage2D(canvas3d, ...) all work as expected. Namely that reading the canvas through any of those calls gives you the contents what you see displayed until first draw call after a swap. I mentioned 2 ways to implement that. Either don't issue the clear until the first draw call after a swap or, read from the display buffer after a swap, read from the draw buffer after a draw, But that is exactly the case that is expensive or impossible on some embedded hardware (at least). You can never get access to the contents you see displayed. Once the drawing buffer is displayed, its contents are not longer available to be read. Essentially the problem is this: 1) All OpenGL-like implementations (including D3D) do an explicit Present() (a). WebGL hides this by saying that this Present() is implicitly done on return from any JS function in which WebGL drawing is done. But when Present() is actually done is not well defined. 2) In some implementations (mostly on the Desktop), Present() is simply a message to the compositor that the current drawing buffer should be composited with the rest of the page. The drawing buffer image doesn't change so it can be used until new WebGL calls are made which overwrite it. 3) Some hardware doesn't work that way. In the hardware used in the iPhone, for instance, Present() actually takes the drawing buffer away from the WebGL context and uses it in a compositing operation that might not even be in sync with the WebGL rendering process. So there is no access to the drawing buffer possible after Present(). If you need access to it, you'd have to make a (costly) copy before issuing the Present() call. Given that a lot of mobile hardware is similar to that in iPhone, I would assume similar issues exist. 4) It would be a shame if the default WebGL operation required that copy. It would mean that platforms that can least afford it (mobile) would be the most heavily penalized. All for the possibility that some fairly rare operations might be called. Of those operations, I'm not sure readPixels() should be included. It seems reasonable that readPixels() would have to be called before a Present() (implicit or explicit) is performed. The real question is what are the rules for calling toDataURL(), or calling drawImage or texImage2D with a WebGL context. An illustrative example was raised at the last F2F that involved taking a snapshot of a running WebGL game. It is interesting because you don't want to penalize the performance of your game just on the odd chance that someone might hit control-S to capture a screen snapshot. Assuming such a penalty were not the default, then what would the author have to do when control-S is pressed? The problem is that the control-S handler would come in as a browser event so you won't know if an implicit Present() had been called and whether or not the data in the current drawing buffer is valid. I'm not sure this is a real issue though. For an app that is continuously drawn, you can just as easily set a flag when control-S comes in and then do a toDataURL after the next render if that flag is set. Calling toDataURL after rendering the current scene and before returning from that rendering operation ensures that the data in the drawing buffer is valid. I think the real problem is in calls to drawImage() or texImage2D() with a WebGL context. Since these are rendering to different 2D or WebGL Canvas contexts, you can't be sure of the state of the WebGL context you're trying to use as the image source. How do you solve that problem? I think adding context attributes and the like are overkill. There's no need to mark a WebGL context as "preserving the drawing buffer" for it's entire life. I think it's also a mistake to have a WebGL context that requires a Present() call. I think it's better to just acknowledge that using a WebGL context as an image source is not "free". Doing it requires cooperation on the part of the context wanting to use a WebGL image source and the WebGL context being used as the source. We can have a Present() call, but make it optional and pass a parameter to it. Passing true says that the current drawing buffer should still be available after the Present() call. Also, passing false should say that the buffer will not be available after Present(), rather than making it undefined whether or not it is available, for consistency. If Present() is not called on return from a JS call that did some rendering, then it would be implicitly called as before, with a param of false. Using a WebGL context as an image source when Present(true) had been previously called on that context causes the contents of the drawing buffer when Present(true) was called to be used as that image source. Otherwise using that context will result in an image of transparent black (0x00000000) being used. I'm not sure printing is an issue. Printing is a system function and so the contents of all buffers should be available to the printing functionality. I think this is true both on desktop and mobile. ----------- (a) It's sometimes possible to do single buffer rendering with OpenGL and D3D, where what you are rendering is actually what is being shown on the display. When doing this, the author of the app has to make sure to render in the "vertical blanking" interval and take no longer than a fraction of the display's frame-rate, or tearing of the image will occur. So this is very specialized and not applicable to WebGL. In fact, because the WebGL drawing buffer has to be "composited" with the other HTML content on the page, single buffering is never possible. So for all practical purposes, all WebGL implementation need an explicit Present(). ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From gma...@ Mon Nov 15 17:09:05 2010 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 15 Nov 2010 17:09:05 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: <9BA6993A-1DC9-4EC9-8F3D-5866161CC84B@apple.com> References: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> <9BA6993A-1DC9-4EC9-8F3D-5866161CC84B@apple.com> Message-ID: On Mon, Nov 15, 2010 at 4:53 PM, Chris Marrin wrote: > > On Nov 15, 2010, at 2:34 PM, Gregg Tavares (wrk) wrote: > > > > > > > On Mon, Nov 15, 2010 at 1:56 PM, Vladimir Vukicevic < > vladimir...@> wrote: > > > > One of the major issues that came up during the last f2f was that the > current canvas model is not the most efficient for implementing on hardware, > especially on mobile hardware. The current model was based on how the 2D > canvas works: drawing happens during content JS script, and as soon as > control is returned to the browser, it's supposed to be presented for > display. Content can also read back the current contents of the displayed > image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both > via toDataURL). > > > > However, most 3D hardware doesn't really want to work like that -- > they're optimized for double-buffering, where you draw a scene to the back > buffer, and then swap buffers; after a swap, the new back buffer contains > garbage. Implementing the current canvas semantics is not a big issue on > the desktop, because there is cpu/gpu/bandwidth to spare, but it's a pretty > big deal on mobile. > > > > We identified a few different options: > > > > 1) Do nothing. Leave things as it is. There would be fairly significant > overhead that all apps would pay, even if they never want to call readPixels > or toDataURL. > > > > 2) Add explicit double-buffering to WebGL canvases, and add an explicit > present() call. This complicates things for developers, because they need > to then actually make this present() call, and can potentially result in > higher memory usage due to some implementations needing to keep around both > a front and back buffer, where before they could be effectively > single-buffered. > > > > 3) Add implicit double-buffering to canvas. Follow the same semantics as > canvas does currently -- swap happens whenever control is returned to the > browser -- but always enforce an uninitialized/cleared back buffer after > each swap. > > > > 4) Like #2 and #3, by adding a context attribute that allows the author > to choose which they would want. > > > > 5) Like #1 (do nothing), but add a context attribute for the author to > indicate whether readback from the window/canvas buffer will ever be done. > If it's set to true, then dimply disallow readPixels/toDataURL when > framebuffer 0 is bound (or have them always return all black). > > > > We identified a few different use cases that should be considered. > Printing and screenshots were two, along with using a WebGL canvas as a > texImage2D source, and using a WebGL canvas as a 2D canvas drawImage source. > > > > Note that even with implicit double-buffering, it's possible to use a FBO > to build up a scene across many events and only draw it to the drawbuffer > once (just like you can do today, with #1). Adding context attributes > complicates the implementations, potentially significantly, so I'd like to > avoid 4 and 5. > > > > I'd lean towards #3, but what are the list's thoughts on this? > > > > I'm fine with 3 with the caveats that I mentioned before. Namely that > toDataURL, readPixels, drawImage, texImage2D(canvas3d, ...) all work as > expected. Namely that reading the canvas through any of those calls gives > you the contents what you see displayed until first draw call after a swap. > I mentioned 2 ways to implement that. Either don't issue the clear until the > first draw call after a swap or, read from the display buffer after a swap, > read from the draw buffer after a draw, > > But that is exactly the case that is expensive or impossible on some > embedded hardware (at least). You can never get access to the contents you > see displayed. Once the drawing buffer is displayed, its contents are not > longer available to be read. Essentially the problem is this: > > 1) All OpenGL-like implementations (including D3D) do an explicit Present() > (a). WebGL hides this by saying that this Present() is implicitly done on > return from any JS function in which WebGL drawing is done. But when > Present() is actually done is not well defined. > > 2) In some implementations (mostly on the Desktop), Present() is simply a > message to the compositor that the current drawing buffer should be > composited with the rest of the page. The drawing buffer image doesn't > change so it can be used until new WebGL calls are made which overwrite it. > > 3) Some hardware doesn't work that way. In the hardware used in the iPhone, > for instance, Present() actually takes the drawing buffer away from the > WebGL context and uses it in a compositing operation that might not even be > in sync with the WebGL rendering process. So there is no access to the > drawing buffer possible after Present(). If you need access to it, you'd > have to make a (costly) copy before issuing the Present() call. Given that a > lot of mobile hardware is similar to that in iPhone, I would assume similar > issues exist. > > 4) It would be a shame if the default WebGL operation required that copy. > It would mean that platforms that can least afford it (mobile) would be the > most heavily penalized. All for the possibility that some fairly rare > operations might be called. > > Of those operations, I'm not sure readPixels() should be included. It seems > reasonable that readPixels() would have to be called before a Present() > (implicit or explicit) is performed. The real question is what are the rules > for calling toDataURL(), or calling drawImage or texImage2D with a WebGL > context. > > An illustrative example was raised at the last F2F that involved taking a > snapshot of a running WebGL game. It is interesting because you don't want > to penalize the performance of your game just on the odd chance that someone > might hit control-S to capture a screen snapshot. Assuming such a penalty > were not the default, then what would the author have to do when control-S > is pressed? The problem is that the control-S handler would come in as a > browser event so you won't know if an implicit Present() had been called and > whether or not the data in the current drawing buffer is valid. > > I'm not sure this is a real issue though. For an app that is continuously > drawn, you can just as easily set a flag when control-S comes in and then do > a toDataURL after the next render if that flag is set. Calling toDataURL > after rendering the current scene and before returning from that rendering > operation ensures that the data in the drawing buffer is valid. > > I think the real problem is in calls to drawImage() or texImage2D() with a > WebGL context. Since these are rendering to different 2D or WebGL Canvas > contexts, you can't be sure of the state of the WebGL context you're trying > to use as the image source. How do you solve that problem? I think adding > context attributes and the like are overkill. There's no need to mark a > WebGL context as "preserving the drawing buffer" for it's entire life. I > think it's also a mistake to have a WebGL context that requires a Present() > call. > > I think it's better to just acknowledge that using a WebGL context as an > image source is not "free". Doing it requires cooperation on the part of the > context wanting to use a WebGL image source and the WebGL context being used > as the source. We can have a Present() call, but make it optional and pass a > parameter to it. Passing true says that the current drawing buffer should > still be available after the Present() call. Also, passing false should say > that the buffer will not be available after Present(), rather than making it > undefined whether or not it is available, for consistency. If Present() is > not called on return from a JS call that did some rendering, then it would > be implicitly called as before, with a param of false. Using a WebGL context > as an image source when Present(true) had been previously called on that > context causes the contents of the drawing buffer when Present(true) was > called to be used as that image source. Otherwise using that context will > result in an image of transparent black (0x00000000) being used. > Adding a Present function seems like it certainly has advantages. Why not require it instead of having the current behavior? Like others have mentioned, this makes it more like real OpenGL and makes it easy to spread out rendering across callbacks, possibly making it better for web worker stuff in the future as well. > > I'm not sure printing is an issue. Printing is a system function and so the > contents of all buffers should be available to the printing functionality. I > think this is true both on desktop and mobile. > > ----------- > > > (a) It's sometimes possible to do single buffer rendering with OpenGL and > D3D, where what you are rendering is actually what is being shown on the > display. When doing this, the author of the app has to make sure to render > in the "vertical blanking" interval and take no longer than a fraction of > the display's frame-rate, or tearing of the image will occur. So this is > very specialized and not applicable to WebGL. In fact, because the WebGL > drawing buffer has to be "composited" with the other HTML content on the > page, single buffering is never possible. So for all practical purposes, all > WebGL implementation need an explicit Present(). > > ----- > ~Chris > cmarrin...@ > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Nov 15 17:14:16 2010 From: cma...@ (Chris Marrin) Date: Mon, 15 Nov 2010 17:14:16 -0800 Subject: [Public WebGL] Re: WebGL spec clarifications In-Reply-To: References: <22D217E8-EB35-4EE1-A5C9-D30F998722AA@apple.com> Message-ID: On Nov 15, 2010, at 4:46 PM, Ligon, David wrote: > Hey Chris, > > I am looking at the WebGL spec and have some questions that I cannot find clear answers to. > > I noticed support for compressed texture enums: > > const GLenum NUM_COMPRESSED_TEXTURE_FORMATS = 0x86A2; > const GLenum COMPRESSED_TEXTURE_FORMATS = 0x86A3; > > But I did not see > void CompressedTexImage2D( enum target, int level, > enum internalformat, sizei width, sizei height, > int border, sizei imageSize, void *data ); > > It appears that > void texImage2D(GLenum target, GLint level, GLenum internalformat, > GLsizei width, GLsizei height, GLint border, GLenum format, > GLenum type, ArrayBufferView pixels); > > is a similar format. > > Is "format" overloaded in WebGL to include compressed formats? If so, this seem contradictory to the pointer to the spec page being pointed to: > > "void texImage2D(GLenum target, GLint level, GLenum internalformat, GLsizei width, GLsizei height, GLint border, GLenum format, GLenum type, ArrayBufferView pixels) (OpenGL ES 2.0 man page)" > > Perhaps CompressedTexImage2D should also be pointed to.... These are all good comments, Dave. I'm adding the public list to get more comments. My comment is, yes, this is an inconsistency in the spec. As of now we don't support any compressed texture formats. We have discussed supporting ETC1 (and maybe ETC2?) since it seems like they may be moving in the direction of being IP free. But for now I believe we plan to ship WebGL 1.0 without any specified support for compressed textures. There are really a couple of issues here. One is that it is currently not easy to download binary data, so it's difficult to get compressed image data into the system. This is being solved by making it possible to get an ArrayBuffer (our binary data object) back from XMLHttpRequest (HTML's generic data fetching mechanism). The other question is, when we can get binary data in and when we decide on the compressed format(s) to support, what calls do we make? My preference, and I believe the solution we have discussed, is to use the current texImage2D call. As you noticed, it has separate format and internalformat params, which should be sufficient to allow incoming compressed data. If we do that, do we need the compressed format enums? I don't think we do. I think it would be better to simply mandate support for whatever compressed format we agree on. So I think the action item is to remove the compressed texture enums. I think it's clear enough in the texImage2D prose that no compressed formats are supported. Other comments? ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From vla...@ Mon Nov 15 17:23:59 2010 From: vla...@ (Vladimir Vukicevic) Date: Mon, 15 Nov 2010 17:23:59 -0800 (PST) Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: Message-ID: <1309280175.355941.1289870639397.JavaMail.root@cm-mail03.mozilla.org> Adding a Present function seems like it certainly has advantages. Why not require it instead of having the current behavior? Like others have mentioned, this makes it more like real OpenGL and makes it easy to spread out rendering across callbacks, possibly making it better for web worker stuff in the future as well. It has a cost -- it would mean that you would have to double-buffer all webgl content; that is, you'd have to be able to keep the displayed front buffer entirely separate than the back buffer. Right now, a WebGL implementation can have a single buffer (for example, a FBO) that it can both render to and use as a texture for compositing. Chris, if I'm understanding your proposal correctly, a code snippet like this: function draw(gl) { gl.clear(..); gl.drawElements(..); // draw #1 gl.Present(true); gl.drawElements(..); // draw #2 } would have an implicit Present(false) at the end, with the displayed buffer containing draw #2 on top of draw #1, and the next time GL drawing happens (that is, the current conceptual back buffer) being cleared/invalid? It seems, as Chris said, the main issue is what the contents of a webgl canvas are for toDataURL, drawImage, and texImage2D (with a webgl canvas as a source). - Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Nov 15 17:28:55 2010 From: cma...@ (Chris Marrin) Date: Mon, 15 Nov 2010 17:28:55 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: References: <630513332.347257.1289777622156.JavaMail.root@cm-mail03.mozilla.org> <2033847348.354199.1289858189572.JavaMail.root@cm-mail03.mozilla.org> <9BA6993A-1DC9-4EC9-8F3D-5866161CC84B@apple.com> Message-ID: On Nov 15, 2010, at 5:09 PM, Gregg Tavares (wrk) wrote: > > > ...> I'm fine with 3 with the caveats that I mentioned before. Namely that toDataURL, readPixels, drawImage, texImage2D(canvas3d, ...) all work as expected. Namely that reading the canvas through any of those calls gives you the contents what you see displayed until first draw call after a swap. I mentioned 2 ways to implement that. Either don't issue the clear until the first draw call after a swap or, read from the display buffer after a swap, read from the draw buffer after a draw, > > But that is exactly the case that is expensive or impossible on some embedded hardware (at least). You can never get access to the contents you see displayed. Once the drawing buffer is displayed, its contents are not longer available to be read. Essentially the problem is this: > > 1) All OpenGL-like implementations (including D3D) do an explicit Present() (a). WebGL hides this by saying that this Present() is implicitly done on return from any JS function in which WebGL drawing is done. But when Present() is actually done is not well defined. > > 2) In some implementations (mostly on the Desktop), Present() is simply a message to the compositor that the current drawing buffer should be composited with the rest of the page. The drawing buffer image doesn't change so it can be used until new WebGL calls are made which overwrite it. > > 3) Some hardware doesn't work that way. In the hardware used in the iPhone, for instance, Present() actually takes the drawing buffer away from the WebGL context and uses it in a compositing operation that might not even be in sync with the WebGL rendering process. So there is no access to the drawing buffer possible after Present(). If you need access to it, you'd have to make a (costly) copy before issuing the Present() call. Given that a lot of mobile hardware is similar to that in iPhone, I would assume similar issues exist. > > 4) It would be a shame if the default WebGL operation required that copy. It would mean that platforms that can least afford it (mobile) would be the most heavily penalized. All for the possibility that some fairly rare operations might be called. > > Of those operations, I'm not sure readPixels() should be included. It seems reasonable that readPixels() would have to be called before a Present() (implicit or explicit) is performed. The real question is what are the rules for calling toDataURL(), or calling drawImage or texImage2D with a WebGL context. > > An illustrative example was raised at the last F2F that involved taking a snapshot of a running WebGL game. It is interesting because you don't want to penalize the performance of your game just on the odd chance that someone might hit control-S to capture a screen snapshot. Assuming such a penalty were not the default, then what would the author have to do when control-S is pressed? The problem is that the control-S handler would come in as a browser event so you won't know if an implicit Present() had been called and whether or not the data in the current drawing buffer is valid. > > I'm not sure this is a real issue though. For an app that is continuously drawn, you can just as easily set a flag when control-S comes in and then do a toDataURL after the next render if that flag is set. Calling toDataURL after rendering the current scene and before returning from that rendering operation ensures that the data in the drawing buffer is valid. > > I think the real problem is in calls to drawImage() or texImage2D() with a WebGL context. Since these are rendering to different 2D or WebGL Canvas contexts, you can't be sure of the state of the WebGL context you're trying to use as the image source. How do you solve that problem? I think adding context attributes and the like are overkill. There's no need to mark a WebGL context as "preserving the drawing buffer" for it's entire life. I think it's also a mistake to have a WebGL context that requires a Present() call. > > I think it's better to just acknowledge that using a WebGL context as an image source is not "free". Doing it requires cooperation on the part of the context wanting to use a WebGL image source and the WebGL context being used as the source. We can have a Present() call, but make it optional and pass a parameter to it. Passing true says that the current drawing buffer should still be available after the Present() call. Also, passing false should say that the buffer will not be available after Present(), rather than making it undefined whether or not it is available, for consistency. If Present() is not called on return from a JS call that did some rendering, then it would be implicitly called as before, with a param of false. Using a WebGL context as an image source when Present(true) had been previously called on that context causes the contents of the drawing buffer when Present(true) was called to be used as that image source. Otherwise using that context will result in an image of transparent black (0x00000000) being used. > > Adding a Present function seems like it certainly has advantages. Why not require it instead of having the current behavior? Like others have mentioned, this makes it more like real OpenGL and makes it easy to spread out rendering across callbacks, possibly making it better for web worker stuff in the future as well. So you're saying we use my proposal but require Present()? I was thinking about compatibility with existing content, but I suppose we're early enough that it's not a big issue. You're right that explicit Present() makes it easy to split the render across multiple calls. And calling Present() (without a param) would be the same as Present(false) so by default you'd get the faster form. And this solves another issue I was concerned about. Before Present() is called, toDataURL() and using the WebGL context as a source image would work as expected; the current (unpresented) contents of the drawing buffer would be used. But what about after the drawing function returns. If you don't know when Present() will be called, how do you know when the contents of the drawing buffer become invalid? With explicit Present() that question goes away. If the author knows when Present() will be called, toDataURL() and using the WebGL context as an image source can be done without using Present(true), as long as the author is careful about the order of operations. Present(true) is just there as a way to decouple presenting the drawing buffer to the compositor and using it as an image source. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cma...@ Mon Nov 15 17:37:14 2010 From: cma...@ (Chris Marrin) Date: Mon, 15 Nov 2010 17:37:14 -0800 Subject: [Public WebGL] double-buffering and back buffer preservation In-Reply-To: <1309280175.355941.1289870639397.JavaMail.root@cm-mail03.mozilla.org> References: <1309280175.355941.1289870639397.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Nov 15, 2010, at 5:23 PM, Vladimir Vukicevic wrote: > > Adding a Present function seems like it certainly has advantages. Why not require it instead of having the current behavior? Like others have mentioned, this makes it more like real OpenGL and makes it easy to spread out rendering across callbacks, possibly making it better for web worker stuff in the future as well. > It has a cost -- it would mean that you would have to double-buffer all webgl content; that is, you'd have to be able to keep the displayed front buffer entirely separate than the back buffer. Right now, a WebGL implementation can have a single buffer (for example, a FBO) that it can both render to and use as a texture for compositing. Damn, you're right. I think I'm seeing how we arrived at the "explicitPresent" flag in our last go-round with this. I really like the idea of explicit Present() because it takes away the question of when Present() is performed. As I said in my last response to Gregg, leaving that open makes it a question of when you can and when you can't use the contents of the drawing buffer as an image source. In the current WebKit implementation we are already double buffered just because of the way it is implemented. and our (future) iOS implementation is double buffered because of the way the hardware works. Does the "double-buffered" requirement add overhead to any of the other implementations? If not, maybe explicit Present() is reasonable? > > Chris, if I'm understanding your proposal correctly, a code snippet like this: > > function draw(gl) { > gl.clear(..); > gl.drawElements(..); // draw #1 > gl.Present(true); > > gl.drawElements(..); // draw #2 > } > > would have an implicit Present(false) at the end, with the displayed buffer containing draw #2 on top of draw #1, and the next time GL drawing happens (that is, the current conceptual back buffer) being cleared/invalid? Right, in the above case, the rendering that occured in draw #1 would never be seen. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Mon Nov 15 18:03:12 2010 From: cal...@ (Mark Callow) Date: Tue, 16 Nov 2010 11:03:12 +0900 Subject: [Public WebGL] Getting FF4 to use ANGLE In-Reply-To: <376364760.352134.1289848849192.JavaMail.root@cm-mail03.mozilla.org> References: <376364760.352134.1289848849192.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <4CE1E660.9010908@hicorp.co.jp> Thanks for the answer Vlad. What about WebGL on the Android version? Regards -Mark On 16/11/2010 04:20, Vladimir Vukicevic wrote: > You can install an extension for ANGLE (relatively recent angle + some patches for some ANGLE bugs) from http://people.mozilla.com/~vladimir/misc/angleproject.xpi . No restart needed after the install. It should be coming into the core fairly soon. > > - Vlad > > ----- Original Message ----- >> Hi, >> >> >> I'm trying to see if I can get WebGL content to run accelerated on my >> notebook computer (Panasonic Let's Note with a 1.06GHz Core2 CPU, an >> on-board Intel GMA 950 graphics chip and DirectX 9). The GL driver for >> this chip is reputedly not good so I want to try ANGLE. I got the >> latest Minefield build (4.0b8pre). webgl.mochitest_native_gl is at the >> default "false" setting. I thought this would mean it would use ANGLE >> but I haven't had any luck running any of the demos from the wiki. >> Most indicate inability to obtain a webgl context but at least 1 just >> gives an empty page. >> >> >> How do I force FF to use ANGLE? >> >> >> P.S. Does the Android version of FF4 support WebGL yet? >> >> >> Regards >> >> >> >> -Mark > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From ced...@ Mon Nov 15 18:13:49 2010 From: ced...@ (Cedric Vivier) Date: Tue, 16 Nov 2010 10:13:49 +0800 Subject: [Public WebGL] Re: WebGL spec clarifications In-Reply-To: References: <22D217E8-EB35-4EE1-A5C9-D30F998722AA@apple.com> Message-ID: On Tue, Nov 16, 2010 at 09:14, Chris Marrin wrote: > My comment is, yes, this is an inconsistency in the spec. As of now we don't support any compressed texture formats. Stock OpenGL ES 2.0 spec doesn't support any compressed texture formats either... It just gives the entry points that can be used by implementations to support one or more compressed formats. >We have discussed supporting ETC1 (and maybe ETC2?) since it seems like they may be moving in the direction of being IP free. But for now I believe we plan to ship WebGL 1.0 without any specified support for compressed textures. Yes so we probably should remove these enums in 1.0. > There are really a couple of issues here. One is that it is currently not easy to download binary data, so it's difficult to get compressed image data into the system. This is being solved by making it possible to get an ArrayBuffer (our binary data object) back from XMLHttpRequest (HTML's generic data fetching mechanism). This is a nice incremental improvement but there's plenty of examples of for download binary data (eg. for meshes) that run actually quite well. > The other question is, when we can get binary data in and when we decide on the compressed format(s) to support, what calls do we make? My preference, and I believe the solution we have discussed, is to use the current texImage2D call. I do not see any reason to divert from OpenGL here. A simple getExtension("some_format") test should be enough, the issue is do we want to make a policy decisio in order to enforce compatibility by waiting for a IP-safe format that is actually in use everywhere and that can be decompressed by the browser on non-supporting GPUs (which makes the usage of such format *useless* compared to say a PNG) ... or just be follow OpenGL's way, which incidentally is the same that was choosen for