From pya...@ Fri May 1 13:10:14 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 1 May 2015 22:10:14 +0200 Subject: [Public WebGL] PSA: fullscreen only over HTTPS Message-ID: Both google and mozilla are planning a coercion scheme whereby "new features" are withheld from sites that don't implement HTTPS. One of these features planned to be withheld is fullscreen and pointerlock. This is a public service message that i the near future if you are using these features, you will now have to pay to unlock those features (at your SSL CA of convenience), and also please stop using any servers or hosters that don't support TLS for whatever reason. Please also stop using any runtime environments/languages which do not have a complete TLS implementation (with all its bewildering cyphersuite variety). Wildcard (multi domain, multi server) certificates start at $10'000/year from verisign. A single domain/host cert will usually cost you around $30-$100/year. A free (as in beer) CA is planned to go life mid-year. It's anybodies guess if that will happen at all (or if they'll get torpedoed by the existing CAs who would see their business collapse) or if they'll issue wildcard certificates. On any account, it will be hosted on US soil and so will have to comply to any C&D, DMCA takedown request etc. that will be whimsically issued to them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat May 2 11:03:30 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 2 May 2015 20:03:30 +0200 Subject: [Public WebGL] Re: PSA: fullscreen only over HTTPS In-Reply-To: References: Message-ID: I have polled a client of mine which has a small web property that contains a WebGL widget which does include a fullscreen button. Here is what I wrote that client: I'd like to inform you that it's likely that the fullscreen button will > break in google chrome and firefox in the forseeable future (mid > 2015-2016). For security reasons browsers want to disable fullscreen if you > are not serving the website over HTTPS. > Starting mid 2015 a new SSL Certificate Authority will offer free > certificates (https://letsencrypt.org/) > Do you think you could host your site over HTTPS to prevent the fullscreen > button breaking? If required, I could also remove the fullscreen button. The clients response below: I appreciate the heads up. > Redesigning our site to use HTTPS is probably possible but I currently do > not have time and resources to undertake that task. > Would it be possible to let me know when you get the information that the > first production Chrome or Firefox is released? At that time I can > certainly disable the fullscreen function myself as this is real easy to do > in your .js file. I quote this conversion because precisely this scenario is what is going to play out across countless web properties once fullscreen is put behind HTTPS. The practice will be that some features can just not be used anymore. That's all there is to it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon May 4 14:48:32 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 4 May 2015 14:48:32 -0700 Subject: [Public WebGL] Re: PSA: fullscreen only over HTTPS In-Reply-To: References: Message-ID: There is an ongoing discussion on this topic on https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus . I'd encourage you all to provide your feedback there. -Ken On Sat, May 2, 2015 at 11:03 AM, Florian B?sch wrote: > I have polled a client of mine which has a small web property that contains > a WebGL widget which does include a fullscreen button. > > Here is what I wrote that client: > >> I'd like to inform you that it's likely that the fullscreen button will >> break in google chrome and firefox in the forseeable future (mid 2015-2016). >> For security reasons browsers want to disable fullscreen if you are not >> serving the website over HTTPS. >> Starting mid 2015 a new SSL Certificate Authority will offer free >> certificates (https://letsencrypt.org/) >> Do you think you could host your site over HTTPS to prevent the fullscreen >> button breaking? If required, I could also remove the fullscreen button. > > > The clients response below: > >> I appreciate the heads up. >> Redesigning our site to use HTTPS is probably possible but I currently do >> not have time and resources to undertake that task. >> Would it be possible to let me know when you get the information that the >> first production Chrome or Firefox is released? At that time I can >> certainly disable the fullscreen function myself as this is real easy to do >> in your .js file. > > > I quote this conversion because precisely this scenario is what is going to > play out across countless web properties once fullscreen is put behind > HTTPS. > > The practice will be that some features can just not be used anymore. That's > all there is to it. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From din...@ Wed May 6 15:07:39 2015 From: din...@ (Dean Jackson) Date: Thu, 7 May 2015 08:07:39 +1000 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: > On 28 Apr 2015, at 4:33 pm, Florian B?sch wrote: > > For various reasons (ANGLE, drivers, etc.) it's possible to: > > - crash firefox > - hang chrome (with an eventual GPU process crash) > > I'm sure other UAs are affected as well. I and others have observed this phenomenon on any OS, and it's nothing that's isolated. > > I have personally filed tickets (and even a conformance test) towards this issue. Can you provide links to the bugs you've filed? I'd at least like to try to make sure WebKit either doesn't crash or we have a plan to avoid it. I agree that being able to crash a browser while compiling a shader is bad. Dean > Many others have also filed tickets. Some of these tickets are of substantial age. Some pages (such as shadertoy, for reasons I get to shortly) has become the butt of a joke in some online communities (such as r/graphicsprogramming). > > I can understand if a shader fails to compile. I can understand if a shader, once compiled will run incredibly slow. What I cannot understand is that simply compiling a shader should hang/crash the software attempting to compile it. > > Shadertoy is a particular victim of this effect. This is because they're blasting up to 10 canvases each compiling a shader somebody submitted to their site at the UA. The likelyhood of encountering a UA busting shader on shadertoy is very high. You usually don't have to navigate very many overview pages to meet one for your platform. > > Shadertoys author is categorically refusing to do any of these things: > > - limit pages to one shader at a time > - track which shaders provoke issues > - inform shader authors about issues with their shaders > > Which is his prerogative. I personally don't agree with that stance, but it is a fairly valid stance to take, that UA should fix something which is obviously broken (see hangs/crashes). > > This has been a long-running issue, documented in many tickets. It's also become the main topic of debate whenever shadertoy pops up in a social media site somewhere. This is harmful to WebGL. > > For whatever reasons UAs think it's not their mission to fix a broken shader compilation pipeline, that is a sadly mistaken point of view. The bucket stops at UAs unfortunately. It's not possible to get all GPU drivers fixed right this day, even if GPU vendors could be bothered to introduce these fixes. > > The practice of ignoring this issue is self-defeating and just serves to cast popular WebGL pages in a bad light, and it casts WebGL as a whole in a bad light. It's a disservice to the work UA WebGL implementor teams do, because it cheapens the fruits of their labor. I'd implore every UA to take a long hard look at this issue and put it on top of their priority list to make sure their software is well behaved even with input they consider unreasonable. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu May 7 23:39:19 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 8 May 2015 08:39:19 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: A recent issue I hit on Linux: https://code.google.com/p/chromium/issues/detail?id=477306 https://bugzilla.mozilla.org/show_bug.cgi?id=1154688 Conformance test I filed because it made a lot of problems on Windows at the time: http://codeflow.org/issues/unroll-problem/ https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/conformance/glsl/misc/large-loop-compile.html This morning browsing the new section of shadertoy ( https://www.shadertoy.com/results?query=&sort=newest&filter=) on page 3 ( https://www.shadertoy.com/results?query=&sort=newest&from=36&num=12) the first shader (https://www.shadertoy.com/view/4tBGzc) crashes the GPU process in chrome on OSX (next page load is "rats ..." bar). It crashes Firefox instantly, and in Safari it does a "a problem occured to this page was reloaded", it reloads it a few times and then DOS the whole of OSX for about half a minute while beechball of death and then safari crashes completely. It took me around 5 minutes of idle browsing on shadertoy to find a cross-browser crash/hang/beachball of death shader for an OS of choice. On Thu, May 7, 2015 at 12:07 AM, Dean Jackson wrote: > > > On 28 Apr 2015, at 4:33 pm, Florian B?sch wrote: > > > > For various reasons (ANGLE, drivers, etc.) it's possible to: > > > > - crash firefox > > - hang chrome (with an eventual GPU process crash) > > > > I'm sure other UAs are affected as well. I and others have observed this > phenomenon on any OS, and it's nothing that's isolated. > > > > I have personally filed tickets (and even a conformance test) towards > this issue. > > Can you provide links to the bugs you've filed? I'd at least like to try > to make sure WebKit either doesn't crash or we have a plan to avoid it. I > agree that being able to crash a browser while compiling a shader is bad. > > Dean > > > > Many others have also filed tickets. Some of these tickets are of > substantial age. Some pages (such as shadertoy, for reasons I get to > shortly) has become the butt of a joke in some online communities (such as > r/graphicsprogramming). > > > > I can understand if a shader fails to compile. I can understand if a > shader, once compiled will run incredibly slow. What I cannot understand is > that simply compiling a shader should hang/crash the software attempting to > compile it. > > > > Shadertoy is a particular victim of this effect. This is because they're > blasting up to 10 canvases each compiling a shader somebody submitted to > their site at the UA. The likelyhood of encountering a UA busting shader on > shadertoy is very high. You usually don't have to navigate very many > overview pages to meet one for your platform. > > > > Shadertoys author is categorically refusing to do any of these things: > > > > - limit pages to one shader at a time > > - track which shaders provoke issues > > - inform shader authors about issues with their shaders > > > > Which is his prerogative. I personally don't agree with that stance, but > it is a fairly valid stance to take, that UA should fix something which is > obviously broken (see hangs/crashes). > > > > This has been a long-running issue, documented in many tickets. It's > also become the main topic of debate whenever shadertoy pops up in a social > media site somewhere. This is harmful to WebGL. > > > > For whatever reasons UAs think it's not their mission to fix a broken > shader compilation pipeline, that is a sadly mistaken point of view. The > bucket stops at UAs unfortunately. It's not possible to get all GPU drivers > fixed right this day, even if GPU vendors could be bothered to introduce > these fixes. > > > > The practice of ignoring this issue is self-defeating and just serves to > cast popular WebGL pages in a bad light, and it casts WebGL as a whole in a > bad light. It's a disservice to the work UA WebGL implementor teams do, > because it cheapens the fruits of their labor. I'd implore every UA to take > a long hard look at this issue and put it on top of their priority list to > make sure their software is well behaved even with input they consider > unreasonable. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon May 11 00:13:45 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 11 May 2015 09:13:45 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: Tickets for this last one: Chrome: https://code.google.com/p/chromium/issues/detail?id=486636 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1163502 Safari: https://bugs.webkit.org/show_bug.cgi?id=144859 Let me know if you need more details or if you can reproduce it on your own. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon May 11 08:24:04 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 11 May 2015 17:24:04 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: Crash reports have been attached to the Chrome and Firefox tickets, also machine and GPU information. Dean, do you need anything for this ticket? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue May 12 00:14:31 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 12 May 2015 09:14:31 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: Safari crash reports have been attached. On Mon, May 11, 2015 at 5:24 PM, Florian B?sch wrote: > Crash reports have been attached to the Chrome and Firefox tickets, also > machine and GPU information. Dean, do you need anything for this ticket? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue May 12 16:46:24 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 12 May 2015 16:46:24 -0700 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: Thanks for the reports. Please note that in Chrome's bug database, the people working on WebGL don't see the initially filed bugs from end users. Please inform us directly about issues you file so that we can tag them appropriately. Otherwise they can slip through the cracks during the triage process. It's not a fair statement to say that UAs don't care about shader compilation issues. On the contrary, many of the tests in the WebGL conformance suite came from developers who ran into shader compilation or evaluation problems on one platform or another. Wherever possible, workarounds have been added to implementations, and these reports have often resulted in bug fixes to the graphics drivers. In the case of the recently-filed Chrome issues, the WebGL team wasn't made aware of the bugs until a few days ago. We would appreciate help reducing the shaders into test cases, and will gladly accept pull requests to the conformance suite acting as regression tests. This will also help identify what shader constructs are causing the poor behavior. It is impossible for the browser to detect all shader compilation and execution problems ahead of time, but where it can, we will try to. Finally, apologies for the slow reply; I fell behind on email some weeks ago and didn't fully catch up. -Ken On Mon, May 11, 2015 at 12:13 AM, Florian B?sch wrote: > Tickets for this last one: > > Chrome: https://code.google.com/p/chromium/issues/detail?id=486636 > Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1163502 > Safari: https://bugs.webkit.org/show_bug.cgi?id=144859 > > Let me know if you need more details or if you can reproduce it on your own. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From Raf...@ Tue May 12 17:34:11 2015 From: Raf...@ (Rafael Cintron) Date: Wed, 13 May 2015 00:34:11 +0000 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: The shadertoy link referenced in the bug reports below do not crash or hang the latest version of Microsoft Edge running on Windows 10. Florian, if you find crash or hang bugs in Edge, please send me e-mail and I will get to the bottom of the problem. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Florian B?sch Sent: Monday, May 11, 2015 12:14 AM To: Dean Jackson Cc: public webgl Subject: Re: [Public WebGL] shader compilation hangs/crashes Tickets for this last one: Chrome: https://code.google.com/p/chromium/issues/detail?id=486636 Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1163502 Safari: https://bugs.webkit.org/show_bug.cgi?id=144859 Let me know if you need more details or if you can reproduce it on your own. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue May 12 23:36:59 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 13 May 2015 08:36:59 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: On Wed, May 13, 2015 at 1:46 AM, Kenneth Russell wrote: > It's not a fair statement to say that UAs don't care about shader > compilation issues. On the contrary, many of the tests in the WebGL > conformance suite came from developers who ran into shader compilation > or evaluation problems on one platform or another. Wherever possible, > workarounds have been added to implementations, and these reports have > often resulted in bug fixes to the graphics drivers. > Having contributed one of these tests I have to say that's not entirely true. I had to have long, long discussions with you and others about getting that conformance suite in and the main reason to reject it was basically "well, you can't expect the implementations to gracefully deal with just any shader" (maybe not those exact words, but that's how I remember that). The problem also went ignored for quite a while till sites like shadertoy became the butt of the joke on reddit for instance. Everybody on #webgl on freenode frequently experiences crashes on shadertoy. It's quite an obvious problem. > It is impossible for the browser to detect all shader compilation and > execution problems ahead of time, but where it can, we will try to. > How about crawling the top 1000 shaders on shadertoy in the categories popular and new and running it automated trough on your testfarm? That should give you a pretty good "ahead of time" warning if stuff's broken. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue May 12 23:41:48 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 13 May 2015 08:41:48 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: On Wed, May 13, 2015 at 8:36 AM, Florian B?sch wrote: > > How about crawling the top 1000 shaders on shadertoy in the categories > popular and new and running it automated trough on your testfarm? That > should give you a pretty good "ahead of time" warning if stuff's broken. > And reducing those to conformance tests can be done nearly automatically. Nearly every shader you find on shadertoy is pasted together from snippets of other shaders. In the case of http://glslsandbox.com/ they even have an explicit derivation feature for a shader. With a bit of text mangling and crawling you can build up a fairly good derivation graph for shaders, and bisect that graph till you automatically arrive at an offending snippet of code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Wed May 13 09:06:59 2015 From: vla...@ (Vladimir Vukicevic) Date: Wed, 13 May 2015 12:06:59 -0400 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: Thanks Florian, I've moved them to the Core - WebGL component and made our team aware of them. I can understand if a shader fails to compile. I can understand if a > shader, once compiled will run incredibly slow. What I cannot understand is > that simply compiling a shader should hang/crash the software attempting to > compile it. These aren't shader compilation hangs/crashes, though; bug 1163502 is crashing in DrawArrays() inside the GL driver, and bug 1154688 is crashing somewhere in nvidia-land, not clear from where (that one might be a compilation issue, will need actual debugging to figure out where). So we need to identify what situation is causing the crashes and avoid it on these particular drivers (assuming it's not a general issue). If they were pure compilation crashes, we could do something like do a trial compilation run in a separate process and make sure it doesn't crash; but that's not the case unfortunately. - Vlad On Mon, May 11, 2015 at 3:13 AM, Florian B?sch wrote: > Tickets for this last one: > > Chrome: https://code.google.com/p/chromium/issues/detail?id=486636 > Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1163502 > Safari: https://bugs.webkit.org/show_bug.cgi?id=144859 > > Let me know if you need more details or if you can reproduce it on your > own. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed May 13 10:04:06 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 13 May 2015 19:04:06 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: On Wed, May 13, 2015 at 6:06 PM, Vladimir Vukicevic wrote: > These aren't shader compilation hangs/crashes, though; bug 1163502 is > crashing in DrawArrays() inside the GL driver, and bug 1154688 is crashing > somewhere in nvidia-land, not clear from where (that one might be a > compilation issue, will need actual debugging to figure out where). > > So we need to identify what situation is causing the crashes and avoid it > on these particular drivers (assuming it's not a general issue). If they > were pure compilation crashes, we could do something like do a trial > compilation run in a separate process and make sure it doesn't crash; but > that's not the case unfortunately. > That's why I called for massive testing of shaders, which are fortunately found aplenty on shadertoy and glslsandbox. There really isn't a good reason to have unidentified/unhandled/unworked-around driver bugs manifest itself when the browser exercises the driver when there's test material easily available. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Wed May 13 16:57:14 2015 From: zmo...@ (Zhenyao Mo) Date: Wed, 13 May 2015 16:57:14 -0700 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: This is something we hope the community can contribute to. I think when Ken mentioned about minimized test cases, he meant not just the entire crashing shadertoy shader (which is usually pretty big), but a reduced shader that's rid of all unnecessary code, so it's clearer if there is a pattern, then we can detect the pattern in shader translator, either fail the compile or rewrite (work around) some patterns to make the compile successful. On Wed, May 13, 2015 at 10:04 AM, Florian B?sch wrote: > On Wed, May 13, 2015 at 6:06 PM, Vladimir Vukicevic > wrote: >> >> These aren't shader compilation hangs/crashes, though; bug 1163502 is >> crashing in DrawArrays() inside the GL driver, and bug 1154688 is crashing >> somewhere in nvidia-land, not clear from where (that one might be a >> compilation issue, will need actual debugging to figure out where). >> >> So we need to identify what situation is causing the crashes and avoid it >> on these particular drivers (assuming it's not a general issue). If they >> were pure compilation crashes, we could do something like do a trial >> compilation run in a separate process and make sure it doesn't crash; but >> that's not the case unfortunately. > > That's why I called for massive testing of shaders, which are fortunately > found aplenty on shadertoy and glslsandbox. There really isn't a good reason > to have unidentified/unhandled/unworked-around driver bugs manifest itself > when the browser exercises the driver when there's test material easily > available. > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu May 14 02:01:41 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 14 May 2015 11:01:41 +0200 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: On Thu, May 14, 2015 at 1:57 AM, Zhenyao Mo wrote: > I think when Ken mentioned about minimized test cases, he meant not > just the entire crashing shadertoy shader (which is usually pretty > big), but a reduced shader that's rid of all unnecessary code, so it's > clearer if there is a pattern, then we can detect the pattern in > shader translator, either fail the compile or rewrite (work around) > some patterns to make the compile successful. And what I mean is that you can use shadertoy/glslsandbox to do that mostly automated: 1) automated crawl for thousands of shaders 2) automated find one that crashes 3) automated scan trough existing shaders that use identical pieces of code 4) automated scan which of the similar shaders also crash, and which don't 5) automated use this information to narrow down a revision/snippet that is causing the crash 6) present it to a user for editing/submission as a conformance test -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Thu May 14 12:19:17 2015 From: din...@ (Dean Jackson) Date: Fri, 15 May 2015 05:19:17 +1000 Subject: [Public WebGL] shader compilation hangs/crashes In-Reply-To: References: Message-ID: > On 12 May 2015, at 5:14 pm, Florian B?sch wrote: > > Safari crash reports have been attached. Thanks Florian! Dean > > On Mon, May 11, 2015 at 5:24 PM, Florian B?sch > wrote: > Crash reports have been attached to the Chrome and Firefox tickets, also machine and GPU information. Dean, do you need anything for this ticket? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon May 18 03:40:54 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 18 May 2015 12:40:54 +0200 Subject: [Public WebGL] context loss, slowdowns and aw-snap dialogs In-Reply-To: References: Message-ID: So I started poking about context loss some more ( http://codeflow.org/issues/vram/gpu-process-crash.html), and then I encountered this: [image: Inline image 1] (Sorry, the program "chrome" closed unexpectedly. Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers.) This was provoked by allocating 64gigs of vram in a single loop at window.onload (in 4k texture chunks). The tab that this originated from was then dead. A second run did not exhibit this behavior, but instead managed to be somehow worse. The tab was still alive, but no context restore was ever received and the aw snap page was displayed. The user would press that 3x and now no WebGL was forthcoming anymore. Page reloads would not help either, the whole UA had to be restarted. Inexplicably, the same test run in Firefox just allocated all those textures and never presented a context loss and even webgl still seemed to work afterwards. I don't really know what that means, maybe somebody can explain that to me (Jeff?) Getting somewhat miffled at this point, I decided to spread things out across animation frames so I could at least see what was done last. It turns out that FF just keeps allocating textures forever. In Chrome at least some information was now visible ( http://codeflow.org/issues/vram/index.html) 0000: start 0001: context lost 0002: gl.CONTEXT_LOST_WEBGL 0003: vram use: 15936.0mb 0004: run interrupted So Chrome allocated 15gigs of ram (I have a 3-gig GPU) before context loss happened). A context loss event was generated, but no out of memory error was ever received. No context restore happened. So I went and tested this on my android Nexus 4 now: This yielded: 0000: start 0001: gl.OUT_OF_MEMORY 0002: vram use: 2496.0mb 0003: run interrupted So no context loss at all, instead an out of memory getError was generated. So I thought well, what happens if we don't stop there? It turns out nothing, the context is never lost, it just keeps generating out of memory errors. Now the same on iOS: 0000: start 0001: gl.OUT_OF_MEMORY 0002: vram use: 1024.0mb 0003: run interrupted Ok, so how about we let it run along beyond that? It keeps generating glErrors for a while, and then: "A problem occured with this webpage so it was reloaded". Again, no context (and no chance to recover from it). On OSX chrome behaves similar to firefox, it just keeps allocating forever. I still don't know what that means (anybody elaborate?) So on to a conclusion: 1. If you overstep ram boundaries you will get either context loss or a gl.OUT_OF_MEMORY error (but not both) 2. It may crash the GPU process/browser/tab (but not reliably) 3. If you get a context loss, there is no context restore (so handling that event is completely useless for this case) 4. If you get a gl.OUT_OF_MEMORY, it's possible you might recover for this, but only if you recover quickly enough before some UA reloads your page (and they might reload anyways). To put this under a suitable heading: COMPLETELY BONKERS. I have conversations with people from time to time about how much resources they can use, and how to handle cases of running out of them. There is no answer to this question. It's just spray&pray and don't even attempt to recover. Do I really have to emphasize that this is in no way, shape or form a way to write reliable WebGL content? This needs a solution that is: - Behaving the same on every UA - Allows to avoid the issue and destroying the whole context before it happens - And if the context is destroyed, allows to gracefully recover from it - Know the reason why the context was lost so allocation hysteresis can be avoided. - Does not disable WebGL entirely for the entire UA - Doss not randomly crash the UA/GPU process/tab -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23611 bytes Desc: not available URL: From kbr...@ Mon May 18 15:11:13 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 18 May 2015 15:11:13 -0700 Subject: [Public WebGL] context loss, slowdowns and aw-snap dialogs In-Reply-To: References: Message-ID: I'm not optimistic that the browser can magically solve these issues. The browser could arbitrarily impose VRAM consumption limits, but to date we've avoided doing so because it would categorically prevent high-end content from running, even on hardware that can handle it. Querying available VRAM is an ill-posed problem for two reasons: 1) GPU vendors haven't wanted to standardize these definitions and queries, and 2) other running applications can affect the current application's behavior, at least on certain OSs that have less-than-ideal VRAM paging implementations. As I suggested before, I think well-written applications should use a heuristic like 100 bytes of VRAM per pixel, which should scale well from mobile to desktop GPUs. Applications allocating gigabytes of VRAM are pushing the boundaries, and will probably have to query the user about whether to attempt these sorts of allocations at all. Concrete suggestions and code snippets which could improve browsers' behavior are welcome, as are suggestions on the reporting mechanisms browsers should ask from graphics drivers during low-memory and out-of-memory situations. On Mon, May 18, 2015 at 3:40 AM, Florian B?sch wrote: > So I started poking about context loss some more ( > http://codeflow.org/issues/vram/gpu-process-crash.html), and then I > encountered this: > > [image: Inline image 1] > (Sorry, the program "chrome" closed unexpectedly. Your computer does not > have enough free memory to automatically analyze the problem and send a > report to the developers.) > > This was provoked by allocating 64gigs of vram in a single loop at > window.onload (in 4k texture chunks). The tab that this originated from was > then dead. A second run did not exhibit this behavior, but instead managed > to be somehow worse. > > The tab was still alive, but no context restore was ever received and the > aw snap page was displayed. The user would press that 3x and now no WebGL > was forthcoming anymore. Page reloads would not help either, the whole UA > had to be restarted. > > Inexplicably, the same test run in Firefox just allocated all those > textures and never presented a context loss and even webgl still seemed to > work afterwards. I don't really know what that means, maybe somebody can > explain that to me (Jeff?) > > Getting somewhat miffled at this point, I decided to spread things out > across animation frames so I could at least see what was done last. It > turns out that FF just keeps allocating textures forever. In Chrome at > least some information was now visible ( > http://codeflow.org/issues/vram/index.html) > > 0000: start > 0001: context lost > 0002: gl.CONTEXT_LOST_WEBGL > 0003: vram use: 15936.0mb > 0004: run interrupted > > > So Chrome allocated 15gigs of ram (I have a 3-gig GPU) before context loss > happened). A context loss event was generated, but no out of memory error > was ever received. No context restore happened. > > So I went and tested this on my android Nexus 4 now: > > This yielded: > > 0000: start > 0001: gl.OUT_OF_MEMORY > 0002: vram use: 2496.0mb > 0003: run interrupted > > > So no context loss at all, instead an out of memory getError was > generated. So I thought well, what happens if we don't stop there? It turns > out nothing, the context is never lost, it just keeps generating out of > memory errors. > > Now the same on iOS: > > 0000: start > 0001: gl.OUT_OF_MEMORY > 0002: vram use: 1024.0mb > 0003: run interrupted > > > Ok, so how about we let it run along beyond that? It keeps generating > glErrors for a while, and then: "A problem occured with this webpage so it > was reloaded". Again, no context (and no chance to recover from it). > > On OSX chrome behaves similar to firefox, it just keeps allocating > forever. I still don't know what that means (anybody elaborate?) > > So on to a conclusion: > > 1. If you overstep ram boundaries you will get either context loss or > a gl.OUT_OF_MEMORY error (but not both) > 2. It may crash the GPU process/browser/tab (but not reliably) > 3. If you get a context loss, there is no context restore (so handling > that event is completely useless for this case) > 4. If you get a gl.OUT_OF_MEMORY, it's possible you might recover for > this, but only if you recover quickly enough before some UA reloads your > page (and they might reload anyways). > > To put this under a suitable heading: COMPLETELY BONKERS. > > I have conversations with people from time to time about how much > resources they can use, and how to handle cases of running out of them. > There is no answer to this question. It's just spray&pray and don't even > attempt to recover. > > Do I really have to emphasize that this is in no way, shape or form a way > to write reliable WebGL content? This needs a solution that is: > > - Behaving the same on every UA > - Allows to avoid the issue and destroying the whole context before it > happens > - And if the context is destroyed, allows to gracefully recover from it > - Know the reason why the context was lost so allocation hysteresis > can be avoided. > - Does not disable WebGL entirely for the entire UA > - Doss not randomly crash the UA/GPU process/tab > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 23611 bytes Desc: not available URL: From pya...@ Mon May 18 15:22:13 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 19 May 2015 00:22:13 +0200 Subject: [Public WebGL] context loss, slowdowns and aw-snap dialogs In-Reply-To: References: Message-ID: On Tue, May 19, 2015 at 12:11 AM, Kenneth Russell wrote: > Concrete suggestions and code snippets which could improve browsers' > behavior are welcome, as are suggestions on the reporting mechanisms > browsers should ask from graphics drivers during low-memory and > out-of-memory situations. > There's UA specific behavior that should be unified, such as: - crashing the GPU process on an allocation triggered context loss but not issuing an out of memory error (chrome linux) - not issuing either a context loss nor issuing an out of memory error (firefox, chrome osx) - not issuing a context loss but issuing an out of memory error (chrome android, ios mobile safari) - not reloading the page on out of memory error (android) - reloading the page on out of memory error (ios) Even if you can't improve upon the allocation situation, consistent behavior would at least go some way to get a consistent user experience. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Fri May 22 04:02:44 2015 From: jda...@ (John Davis) Date: Fri, 22 May 2015 07:02:44 -0400 Subject: [Public WebGL] 3d textures Message-ID: eta? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri May 22 12:40:32 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 22 May 2015 12:40:32 -0700 Subject: [Public WebGL] 3d textures In-Reply-To: References: Message-ID: WebGL 2. On Fri, May 22, 2015 at 4:02 AM, John Davis wrote: > eta? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Tue May 26 08:12:42 2015 From: ash...@ (Ashley Gullen) Date: Tue, 26 May 2015 16:12:42 +0100 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced Message-ID: KHR_blend_equation_advanced adds some interesting new color blend modes such as multiply, screen, overlay and more. I think these warrant particular attention on the web platform because they correspond to some of the 2D context's more recent composite modes. Consider the mapping of globalCompositeMode to OpenGL blend modes: "source-over", "source-in", "source-out", "source-atop", "destination-over", "destination-in", "destination-out", "destination-atop", "lighter", "copy": all possible with existing blend modes "xor": don't know? "multiply": MULTIPLY_KHR "screen": SCREEN_KHR "overlay": OVERLAY_KHR "darken": DARKEN_KHR "lighten": LIGHTEN_KHR "color-dodge": COLORDODGE_KHR "color-burn": COLORBURN_KHR "hard-light": HARDLIGHT_KHR "soft-light": SOFTLIGHT_KHR "difference": DIFFERENCE_KHR "exclusion": EXCLUSION_KHR "hue": HSL_HUE_KHR "saturation": HSL_SATURATION_KHR "color": HSL_COLOR_KHR "luminosity": HSL_LUMINOSITY_KHR The mapping is pretty much perfect. I don't know if there's a blend mode that covers "xor", but if there is (and I'd be interested to know!) then the mapping is perfect. This extension has a few use cases: - Improve consistency across the web platform, by bringing the WebGL and 2D context's capabilities closer together. This makes it easier to build 2D WebGL applications that are equivalent to their canvas2d counterparts. - make it easier to polyfill/extend/implement canvas2d via WebGL (browser vendors may be interested in a JS implementation of CanvasRenderingContext2D for performance reasons) - provide useful blending modes without making authors resort to writing their own shaders and having to know all the formulae involved - provide a performance guarantee, since the blending uses hardware/driver-authored implementations and minimises the necessary draw calls/state changes to use these blend modes, avoiding inefficient implementations by developers (or possibly even exceeding what they can achieve even in the best case depending on if the driver uses any special optimisations) It also appears to be a relatively small API surface, mainly introducing new enums for blendEquation. Some questions/risks: - I don't know what the GPU support for this is like in the wild across desktop and mobile, although I've read it's part of the Android Extension Pack which suggests some mobile support - I don't know enough about this area to comment on the suitability of the "coherent" version or the "blendBarrier" function's suitability in a WebGL context - if GPU support is not broad, developers may feel that a fallback is still necessary so developers will need to write their own shaders for these blend modes anyway, eliminating some of the benefits Still, these blend modes were deemed suitable for the 2D context so I feel it would be useful to have them in WebGL too. In our particular case as developers of a 2D HTML5 game engine, this would simplify our code and improve consistency with the 2D context fallback. Ashley Gullen Scirra.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue May 26 08:40:04 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 26 May 2015 18:40:04 +0300 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: Currently neither GLES2 core or WebGL1 supports exclusive-or blending. Desktop OpenGL since something like 1.4 has had this and more via glLogicOp functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I think GLES3 didn't add it back either, but my GL spec lawyer stamina is too low to actually check the pdf). Don't know the reason why since OpenGL decision making is not open in the public, but if I had to guess, some vendor x with chip y on OS z was not able to support it efficiently and wanted it gone, probably basing the argument on it not being a very common functionality, and/or that the renderable texture format family that was chosen to GLES2 core didn't feel appropriate enough. Not sure if glLogicOp support should be a prerequisite for WEBGL_blend_equation_advanced, though the other blend modes than xor sound like they don't need bitwise ops being supported. 2015-05-26 18:12 GMT+03:00 Ashley Gullen : > KHR_blend_equation_advanced adds some interesting new color blend modes > such as multiply, screen, overlay and more. I think these warrant > particular attention on the web platform because they correspond to some of > the 2D context's more recent composite modes. Consider the mapping of > globalCompositeMode to OpenGL blend modes: > > "source-over", "source-in", "source-out", "source-atop", > "destination-over", "destination-in", "destination-out", > "destination-atop", "lighter", "copy": all possible with existing blend > modes > "xor": don't know? > "multiply": MULTIPLY_KHR > "screen": SCREEN_KHR > "overlay": OVERLAY_KHR > "darken": DARKEN_KHR > "lighten": LIGHTEN_KHR > "color-dodge": COLORDODGE_KHR > "color-burn": COLORBURN_KHR > "hard-light": HARDLIGHT_KHR > "soft-light": SOFTLIGHT_KHR > "difference": DIFFERENCE_KHR > "exclusion": EXCLUSION_KHR > "hue": HSL_HUE_KHR > "saturation": HSL_SATURATION_KHR > "color": HSL_COLOR_KHR > "luminosity": HSL_LUMINOSITY_KHR > > The mapping is pretty much perfect. I don't know if there's a blend mode > that covers "xor", but if there is (and I'd be interested to know!) then > the mapping is perfect. > > This extension has a few use cases: > - Improve consistency across the web platform, by bringing the WebGL and > 2D context's capabilities closer together. This makes it easier to build 2D > WebGL applications that are equivalent to their canvas2d counterparts. > - make it easier to polyfill/extend/implement canvas2d via WebGL (browser > vendors may be interested in a JS implementation of > CanvasRenderingContext2D for performance reasons) > - provide useful blending modes without making authors resort to writing > their own shaders and having to know all the formulae involved > - provide a performance guarantee, since the blending uses > hardware/driver-authored implementations and minimises the necessary draw > calls/state changes to use these blend modes, avoiding inefficient > implementations by developers (or possibly even exceeding what they can > achieve even in the best case depending on if the driver uses any special > optimisations) > > It also appears to be a relatively small API surface, mainly introducing > new enums for blendEquation. > > Some questions/risks: > - I don't know what the GPU support for this is like in the wild across > desktop and mobile, although I've read it's part of the Android Extension > Pack which suggests some mobile support > - I don't know enough about this area to comment on the suitability of the > "coherent" version or the "blendBarrier" function's suitability in a WebGL > context > - if GPU support is not broad, developers may feel that a fallback is > still necessary so developers will need to write their own shaders for > these blend modes anyway, eliminating some of the benefits > > Still, these blend modes were deemed suitable for the 2D context so I feel > it would be useful to have them in WebGL too. In our particular case as > developers of a 2D HTML5 game engine, this would simplify our code and > improve consistency with the 2D context fallback. > > Ashley Gullen > Scirra.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue May 26 08:54:26 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 26 May 2015 17:54:26 +0200 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: A few remarks: glLogicOp interacts with the rest of the blending machinery, so supporting blend equation advanced via that function might be tricky. Also it'd be quite difficult to ensure non-coherent undefinedness using this route. Fortunately the blend equation advanced extensions also exist for desktop GL. However they're some of the very latest extensions in ARB status, and so support might come in different (non ARB) flavours or not at all. The blend barrier function should be no problem to support on the extension object provided the extension is provided by the underlying extension rather than emulated via other functionality. Support is difficult to gauge, but it's probably not great. This capability index tracks it on desktop GL at 2% http://feedback.wildfiregames.com/report/opengl/ I would guesstimate support on mobiles would be similarly low for the time being. An open question would be how you get that behavior into Direct3D of course. Can somebody elaborate on that point? Regardless of that, I'd encourage you to propose an extension definition (via git pull request) for this functionality, this will help direct the discussion away from idle speculation on a ML and into something with real consequences for stakeholders (it's not real until you spec it). On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki wrote: > Currently neither GLES2 core or WebGL1 supports exclusive-or blending. > Desktop OpenGL since something like 1.4 has had this and more via glLogicOp > functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml > and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I > think GLES3 didn't add it back either, but my GL spec lawyer stamina is too > low to actually check the pdf). Don't know the reason why since OpenGL > decision making is not open in the public, but if I had to guess, some > vendor x with chip y on OS z was not able to support it efficiently and > wanted it gone, probably basing the argument on it not being a very common > functionality, and/or that the renderable texture format family that was > chosen to GLES2 core didn't feel appropriate enough. > > Not sure if glLogicOp support should be a prerequisite for > WEBGL_blend_equation_advanced, though the other blend modes than xor sound > like they don't need bitwise ops being supported. > > 2015-05-26 18:12 GMT+03:00 Ashley Gullen : > >> KHR_blend_equation_advanced adds some interesting new color blend modes >> such as multiply, screen, overlay and more. I think these warrant >> particular attention on the web platform because they correspond to some of >> the 2D context's more recent composite modes. Consider the mapping of >> globalCompositeMode to OpenGL blend modes: >> >> "source-over", "source-in", "source-out", "source-atop", >> "destination-over", "destination-in", "destination-out", >> "destination-atop", "lighter", "copy": all possible with existing blend >> modes >> "xor": don't know? >> "multiply": MULTIPLY_KHR >> "screen": SCREEN_KHR >> "overlay": OVERLAY_KHR >> "darken": DARKEN_KHR >> "lighten": LIGHTEN_KHR >> "color-dodge": COLORDODGE_KHR >> "color-burn": COLORBURN_KHR >> "hard-light": HARDLIGHT_KHR >> "soft-light": SOFTLIGHT_KHR >> "difference": DIFFERENCE_KHR >> "exclusion": EXCLUSION_KHR >> "hue": HSL_HUE_KHR >> "saturation": HSL_SATURATION_KHR >> "color": HSL_COLOR_KHR >> "luminosity": HSL_LUMINOSITY_KHR >> >> The mapping is pretty much perfect. I don't know if there's a blend mode >> that covers "xor", but if there is (and I'd be interested to know!) then >> the mapping is perfect. >> >> This extension has a few use cases: >> - Improve consistency across the web platform, by bringing the WebGL and >> 2D context's capabilities closer together. This makes it easier to build 2D >> WebGL applications that are equivalent to their canvas2d counterparts. >> - make it easier to polyfill/extend/implement canvas2d via WebGL (browser >> vendors may be interested in a JS implementation of >> CanvasRenderingContext2D for performance reasons) >> - provide useful blending modes without making authors resort to writing >> their own shaders and having to know all the formulae involved >> - provide a performance guarantee, since the blending uses >> hardware/driver-authored implementations and minimises the necessary draw >> calls/state changes to use these blend modes, avoiding inefficient >> implementations by developers (or possibly even exceeding what they can >> achieve even in the best case depending on if the driver uses any special >> optimisations) >> >> It also appears to be a relatively small API surface, mainly introducing >> new enums for blendEquation. >> >> Some questions/risks: >> - I don't know what the GPU support for this is like in the wild across >> desktop and mobile, although I've read it's part of the Android Extension >> Pack which suggests some mobile support >> - I don't know enough about this area to comment on the suitability of >> the "coherent" version or the "blendBarrier" function's suitability in a >> WebGL context >> - if GPU support is not broad, developers may feel that a fallback is >> still necessary so developers will need to write their own shaders for >> these blend modes anyway, eliminating some of the benefits >> >> Still, these blend modes were deemed suitable for the 2D context so I >> feel it would be useful to have them in WebGL too. In our particular case >> as developers of a 2D HTML5 game engine, this would simplify our code and >> improve consistency with the 2D context fallback. >> >> Ashley Gullen >> Scirra.com >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Tue May 26 09:09:01 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Tue, 26 May 2015 19:09:01 +0300 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: Direct3D 11.1 adds support for logic ops via blend states: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target , which is present on Windows 8 and Windows Phone 8. I am not sure if this is one of the "partial D3D11.1 support on Windows 7" features, could not find that page at a quick glance. In D3D11.1 one creates an immutable blend state that has the desired logic operation on a render target: ID3D11Device1::CreateBlendState1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx -> D3D11_BLEND_DESC1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx -> D3D11_RENDER_TARGET_BLEND_DESC1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx -> D3D11_LOGIC_OP: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx 2015-05-26 18:54 GMT+03:00 Florian B?sch : > A few remarks: > > glLogicOp interacts with the rest of the blending machinery, so supporting > blend equation advanced via that function might be tricky. Also it'd be > quite difficult to ensure non-coherent undefinedness using this route. > Fortunately the blend equation advanced extensions also exist for desktop > GL. However they're some of the very latest extensions in ARB status, and > so support might come in different (non ARB) flavours or not at all. > > The blend barrier function should be no problem to support on the > extension object provided the extension is provided by the underlying > extension rather than emulated via other functionality. > > Support is difficult to gauge, but it's probably not great. This > capability index tracks it on desktop GL at 2% > http://feedback.wildfiregames.com/report/opengl/ > > I would guesstimate support on mobiles would be similarly low for the time > being. > > An open question would be how you get that behavior into Direct3D of > course. Can somebody elaborate on that point? > > Regardless of that, I'd encourage you to propose an extension definition > (via git pull request) for this functionality, this will help direct the > discussion away from idle speculation on a ML and into something with real > consequences for stakeholders (it's not real until you spec it). > > On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki wrote: > >> Currently neither GLES2 core or WebGL1 supports exclusive-or blending. >> Desktop OpenGL since something like 1.4 has had this and more via glLogicOp >> functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml >> and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I >> think GLES3 didn't add it back either, but my GL spec lawyer stamina is too >> low to actually check the pdf). Don't know the reason why since OpenGL >> decision making is not open in the public, but if I had to guess, some >> vendor x with chip y on OS z was not able to support it efficiently and >> wanted it gone, probably basing the argument on it not being a very common >> functionality, and/or that the renderable texture format family that was >> chosen to GLES2 core didn't feel appropriate enough. >> >> Not sure if glLogicOp support should be a prerequisite for >> WEBGL_blend_equation_advanced, though the other blend modes than xor sound >> like they don't need bitwise ops being supported. >> >> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >> >>> KHR_blend_equation_advanced adds some interesting new color blend modes >>> such as multiply, screen, overlay and more. I think these warrant >>> particular attention on the web platform because they correspond to some of >>> the 2D context's more recent composite modes. Consider the mapping of >>> globalCompositeMode to OpenGL blend modes: >>> >>> "source-over", "source-in", "source-out", "source-atop", >>> "destination-over", "destination-in", "destination-out", >>> "destination-atop", "lighter", "copy": all possible with existing blend >>> modes >>> "xor": don't know? >>> "multiply": MULTIPLY_KHR >>> "screen": SCREEN_KHR >>> "overlay": OVERLAY_KHR >>> "darken": DARKEN_KHR >>> "lighten": LIGHTEN_KHR >>> "color-dodge": COLORDODGE_KHR >>> "color-burn": COLORBURN_KHR >>> "hard-light": HARDLIGHT_KHR >>> "soft-light": SOFTLIGHT_KHR >>> "difference": DIFFERENCE_KHR >>> "exclusion": EXCLUSION_KHR >>> "hue": HSL_HUE_KHR >>> "saturation": HSL_SATURATION_KHR >>> "color": HSL_COLOR_KHR >>> "luminosity": HSL_LUMINOSITY_KHR >>> >>> The mapping is pretty much perfect. I don't know if there's a blend mode >>> that covers "xor", but if there is (and I'd be interested to know!) then >>> the mapping is perfect. >>> >>> This extension has a few use cases: >>> - Improve consistency across the web platform, by bringing the WebGL and >>> 2D context's capabilities closer together. This makes it easier to build 2D >>> WebGL applications that are equivalent to their canvas2d counterparts. >>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>> (browser vendors may be interested in a JS implementation of >>> CanvasRenderingContext2D for performance reasons) >>> - provide useful blending modes without making authors resort to writing >>> their own shaders and having to know all the formulae involved >>> - provide a performance guarantee, since the blending uses >>> hardware/driver-authored implementations and minimises the necessary draw >>> calls/state changes to use these blend modes, avoiding inefficient >>> implementations by developers (or possibly even exceeding what they can >>> achieve even in the best case depending on if the driver uses any special >>> optimisations) >>> >>> It also appears to be a relatively small API surface, mainly introducing >>> new enums for blendEquation. >>> >>> Some questions/risks: >>> - I don't know what the GPU support for this is like in the wild across >>> desktop and mobile, although I've read it's part of the Android Extension >>> Pack which suggests some mobile support >>> - I don't know enough about this area to comment on the suitability of >>> the "coherent" version or the "blendBarrier" function's suitability in a >>> WebGL context >>> - if GPU support is not broad, developers may feel that a fallback is >>> still necessary so developers will need to write their own shaders for >>> these blend modes anyway, eliminating some of the benefits >>> >>> Still, these blend modes were deemed suitable for the 2D context so I >>> feel it would be useful to have them in WebGL too. In our particular case >>> as developers of a 2D HTML5 game engine, this would simplify our code and >>> improve consistency with the 2D context fallback. >>> >>> Ashley Gullen >>> Scirra.com >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Tue May 26 10:48:58 2015 From: ash...@ (Ashley Gullen) Date: Tue, 26 May 2015 18:48:58 +0100 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: TBH I don't care much for the xor effect, I don't think it's terribly useful - it was a weird choice to support it in canvas2d - and if it's not possible to support then that's fine by me. I'm more interested in the photoshop style blends like screen and multiply. I'll do a little research in to the D3D11 side of things and write a draft definition. Ashley On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: > Direct3D 11.1 adds support for logic ops via blend states: > https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target > , which is present on Windows 8 and Windows Phone 8. I am not sure if this > is one of the "partial D3D11.1 support on Windows 7" features, could not > find that page at a quick glance. In D3D11.1 one creates an immutable blend > state that has the desired logic operation on a render target: > > ID3D11Device1::CreateBlendState1: > https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx > -> D3D11_BLEND_DESC1: > https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx > -> D3D11_RENDER_TARGET_BLEND_DESC1: > https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx > -> D3D11_LOGIC_OP: > https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx > > > 2015-05-26 18:54 GMT+03:00 Florian B?sch : > >> A few remarks: >> >> glLogicOp interacts with the rest of the blending machinery, so >> supporting blend equation advanced via that function might be tricky. Also >> it'd be quite difficult to ensure non-coherent undefinedness using this >> route. Fortunately the blend equation advanced extensions also exist for >> desktop GL. However they're some of the very latest extensions in ARB >> status, and so support might come in different (non ARB) flavours or not at >> all. >> >> The blend barrier function should be no problem to support on the >> extension object provided the extension is provided by the underlying >> extension rather than emulated via other functionality. >> >> Support is difficult to gauge, but it's probably not great. This >> capability index tracks it on desktop GL at 2% >> http://feedback.wildfiregames.com/report/opengl/ >> >> I would guesstimate support on mobiles would be similarly low for the >> time being. >> >> An open question would be how you get that behavior into Direct3D of >> course. Can somebody elaborate on that point? >> >> Regardless of that, I'd encourage you to propose an extension definition >> (via git pull request) for this functionality, this will help direct the >> discussion away from idle speculation on a ML and into something with real >> consequences for stakeholders (it's not real until you spec it). >> >> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki wrote: >> >>> Currently neither GLES2 core or WebGL1 supports exclusive-or blending. >>> Desktop OpenGL since something like 1.4 has had this and more via glLogicOp >>> functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml >>> and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I >>> think GLES3 didn't add it back either, but my GL spec lawyer stamina is too >>> low to actually check the pdf). Don't know the reason why since OpenGL >>> decision making is not open in the public, but if I had to guess, some >>> vendor x with chip y on OS z was not able to support it efficiently and >>> wanted it gone, probably basing the argument on it not being a very common >>> functionality, and/or that the renderable texture format family that was >>> chosen to GLES2 core didn't feel appropriate enough. >>> >>> Not sure if glLogicOp support should be a prerequisite for >>> WEBGL_blend_equation_advanced, though the other blend modes than xor sound >>> like they don't need bitwise ops being supported. >>> >>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >>> >>>> KHR_blend_equation_advanced adds some interesting new color blend modes >>>> such as multiply, screen, overlay and more. I think these warrant >>>> particular attention on the web platform because they correspond to some of >>>> the 2D context's more recent composite modes. Consider the mapping of >>>> globalCompositeMode to OpenGL blend modes: >>>> >>>> "source-over", "source-in", "source-out", "source-atop", >>>> "destination-over", "destination-in", "destination-out", >>>> "destination-atop", "lighter", "copy": all possible with existing blend >>>> modes >>>> "xor": don't know? >>>> "multiply": MULTIPLY_KHR >>>> "screen": SCREEN_KHR >>>> "overlay": OVERLAY_KHR >>>> "darken": DARKEN_KHR >>>> "lighten": LIGHTEN_KHR >>>> "color-dodge": COLORDODGE_KHR >>>> "color-burn": COLORBURN_KHR >>>> "hard-light": HARDLIGHT_KHR >>>> "soft-light": SOFTLIGHT_KHR >>>> "difference": DIFFERENCE_KHR >>>> "exclusion": EXCLUSION_KHR >>>> "hue": HSL_HUE_KHR >>>> "saturation": HSL_SATURATION_KHR >>>> "color": HSL_COLOR_KHR >>>> "luminosity": HSL_LUMINOSITY_KHR >>>> >>>> The mapping is pretty much perfect. I don't know if there's a blend >>>> mode that covers "xor", but if there is (and I'd be interested to know!) >>>> then the mapping is perfect. >>>> >>>> This extension has a few use cases: >>>> - Improve consistency across the web platform, by bringing the WebGL >>>> and 2D context's capabilities closer together. This makes it easier to >>>> build 2D WebGL applications that are equivalent to their canvas2d >>>> counterparts. >>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>>> (browser vendors may be interested in a JS implementation of >>>> CanvasRenderingContext2D for performance reasons) >>>> - provide useful blending modes without making authors resort to >>>> writing their own shaders and having to know all the formulae involved >>>> - provide a performance guarantee, since the blending uses >>>> hardware/driver-authored implementations and minimises the necessary draw >>>> calls/state changes to use these blend modes, avoiding inefficient >>>> implementations by developers (or possibly even exceeding what they can >>>> achieve even in the best case depending on if the driver uses any special >>>> optimisations) >>>> >>>> It also appears to be a relatively small API surface, mainly >>>> introducing new enums for blendEquation. >>>> >>>> Some questions/risks: >>>> - I don't know what the GPU support for this is like in the wild across >>>> desktop and mobile, although I've read it's part of the Android Extension >>>> Pack which suggests some mobile support >>>> - I don't know enough about this area to comment on the suitability of >>>> the "coherent" version or the "blendBarrier" function's suitability in a >>>> WebGL context >>>> - if GPU support is not broad, developers may feel that a fallback is >>>> still necessary so developers will need to write their own shaders for >>>> these blend modes anyway, eliminating some of the benefits >>>> >>>> Still, these blend modes were deemed suitable for the 2D context so I >>>> feel it would be useful to have them in WebGL too. In our particular case >>>> as developers of a 2D HTML5 game engine, this would simplify our code and >>>> improve consistency with the 2D context fallback. >>>> >>>> Ashley Gullen >>>> Scirra.com >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Tue May 26 12:38:09 2015 From: Raf...@ (Rafael Cintron) Date: Tue, 26 May 2015 19:38:09 +0000 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: Jukka, D3D does have support for logical operations. However, to know for sure whether you can use them, you need to call ID3D11Device::CheckFeatureSupport and refer to the OutputMergerLogicOp member of the D3D11_FEATURE_DATA_D3D11_OPTIONS. Here is what the docs for OutputMergerLogicOp have to say at https://msdn.microsoft.com/en-us/library/windows/desktop/hh404457(v=vs.85).aspx OutputMergerLogicOp. Specifies whether logic operations are available in blend state. The runtime sets this member to TRUE if logic operations are available in blend state and FALSE otherwise. This member is FALSE for feature level 9.1, 9.2, and 9.3. This member is optional for feature level 10, 10.1, and 11. This member is TRUE for feature level 11.1. So while you can use them, only feature level 11.1+ hardware is guaranteed to have them. For hardware that doesn?t have them, browsers will need to render the effect a different way, likely involving an intermediate and a shader. I?ve asked the D3D team to improve the documentation for CreateBlendState1. I, too, was unsure of the support level when I first read it. --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Ashley Gullen Sent: Tuesday, May 26, 2015 10:49 AM To: Jukka Jyl?nki Cc: Florian B?sch; public_webgl...@ Subject: Re: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced TBH I don't care much for the xor effect, I don't think it's terribly useful - it was a weird choice to support it in canvas2d - and if it's not possible to support then that's fine by me. I'm more interested in the photoshop style blends like screen and multiply. I'll do a little research in to the D3D11 side of things and write a draft definition. Ashley On 26 May 2015 at 17:09, Jukka Jyl?nki > wrote: Direct3D 11.1 adds support for logic ops via blend states: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target , which is present on Windows 8 and Windows Phone 8. I am not sure if this is one of the "partial D3D11.1 support on Windows 7" features, could not find that page at a quick glance. In D3D11.1 one creates an immutable blend state that has the desired logic operation on a render target: ID3D11Device1::CreateBlendState1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx -> D3D11_BLEND_DESC1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx -> D3D11_RENDER_TARGET_BLEND_DESC1: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx -> D3D11_LOGIC_OP: https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx 2015-05-26 18:54 GMT+03:00 Florian B?sch >: A few remarks: glLogicOp interacts with the rest of the blending machinery, so supporting blend equation advanced via that function might be tricky. Also it'd be quite difficult to ensure non-coherent undefinedness using this route. Fortunately the blend equation advanced extensions also exist for desktop GL. However they're some of the very latest extensions in ARB status, and so support might come in different (non ARB) flavours or not at all. The blend barrier function should be no problem to support on the extension object provided the extension is provided by the underlying extension rather than emulated via other functionality. Support is difficult to gauge, but it's probably not great. This capability index tracks it on desktop GL at 2% http://feedback.wildfiregames.com/report/opengl/ I would guesstimate support on mobiles would be similarly low for the time being. An open question would be how you get that behavior into Direct3D of course. Can somebody elaborate on that point? Regardless of that, I'd encourage you to propose an extension definition (via git pull request) for this functionality, this will help direct the discussion away from idle speculation on a ML and into something with real consequences for stakeholders (it's not real until you spec it). On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki > wrote: Currently neither GLES2 core or WebGL1 supports exclusive-or blending. Desktop OpenGL since something like 1.4 has had this and more via glLogicOp functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I think GLES3 didn't add it back either, but my GL spec lawyer stamina is too low to actually check the pdf). Don't know the reason why since OpenGL decision making is not open in the public, but if I had to guess, some vendor x with chip y on OS z was not able to support it efficiently and wanted it gone, probably basing the argument on it not being a very common functionality, and/or that the renderable texture format family that was chosen to GLES2 core didn't feel appropriate enough. Not sure if glLogicOp support should be a prerequisite for WEBGL_blend_equation_advanced, though the other blend modes than xor sound like they don't need bitwise ops being supported. 2015-05-26 18:12 GMT+03:00 Ashley Gullen >: KHR_blend_equation_advanced adds some interesting new color blend modes such as multiply, screen, overlay and more. I think these warrant particular attention on the web platform because they correspond to some of the 2D context's more recent composite modes. Consider the mapping of globalCompositeMode to OpenGL blend modes: "source-over", "source-in", "source-out", "source-atop", "destination-over", "destination-in", "destination-out", "destination-atop", "lighter", "copy": all possible with existing blend modes "xor": don't know? "multiply": MULTIPLY_KHR "screen": SCREEN_KHR "overlay": OVERLAY_KHR "darken": DARKEN_KHR "lighten": LIGHTEN_KHR "color-dodge": COLORDODGE_KHR "color-burn": COLORBURN_KHR "hard-light": HARDLIGHT_KHR "soft-light": SOFTLIGHT_KHR "difference": DIFFERENCE_KHR "exclusion": EXCLUSION_KHR "hue": HSL_HUE_KHR "saturation": HSL_SATURATION_KHR "color": HSL_COLOR_KHR "luminosity": HSL_LUMINOSITY_KHR The mapping is pretty much perfect. I don't know if there's a blend mode that covers "xor", but if there is (and I'd be interested to know!) then the mapping is perfect. This extension has a few use cases: - Improve consistency across the web platform, by bringing the WebGL and 2D context's capabilities closer together. This makes it easier to build 2D WebGL applications that are equivalent to their canvas2d counterparts. - make it easier to polyfill/extend/implement canvas2d via WebGL (browser vendors may be interested in a JS implementation of CanvasRenderingContext2D for performance reasons) - provide useful blending modes without making authors resort to writing their own shaders and having to know all the formulae involved - provide a performance guarantee, since the blending uses hardware/driver-authored implementations and minimises the necessary draw calls/state changes to use these blend modes, avoiding inefficient implementations by developers (or possibly even exceeding what they can achieve even in the best case depending on if the driver uses any special optimisations) It also appears to be a relatively small API surface, mainly introducing new enums for blendEquation. Some questions/risks: - I don't know what the GPU support for this is like in the wild across desktop and mobile, although I've read it's part of the Android Extension Pack which suggests some mobile support - I don't know enough about this area to comment on the suitability of the "coherent" version or the "blendBarrier" function's suitability in a WebGL context - if GPU support is not broad, developers may feel that a fallback is still necessary so developers will need to write their own shaders for these blend modes anyway, eliminating some of the benefits Still, these blend modes were deemed suitable for the 2D context so I feel it would be useful to have them in WebGL too. In our particular case as developers of a 2D HTML5 game engine, this would simplify our code and improve consistency with the 2D context fallback. Ashley Gullen Scirra.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Tue May 26 12:42:03 2015 From: vla...@ (Vladimir Vukicevic) Date: Tue, 26 May 2015 15:42:03 -0400 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: XOR got supported on Canvas 2D due to an artifact of it being a mapping of Apple's canvas/CoreGraphics APIs. It's at best poorly supported today, at least with any reasonable performance. I don't see any downside to proposing this extension, but I suspect that all the WebGL implementors are currently busy working on their WebGL 2 implementations, and even beyond that I'd suggest that GL ES 3.1-equivalent functionality would take precedence. Then again, it would not be a difficult extension to implement, especially if it was only exposed if the underlying graphics API had support. - Vlad On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen wrote: > TBH I don't care much for the xor effect, I don't think it's terribly > useful - it was a weird choice to support it in canvas2d - and if it's not > possible to support then that's fine by me. I'm more interested in the > photoshop style blends like screen and multiply. I'll do a little research > in to the D3D11 side of things and write a draft definition. > > Ashley > > > On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: > >> Direct3D 11.1 adds support for logic ops via blend states: >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target >> , which is present on Windows 8 and Windows Phone 8. I am not sure if this >> is one of the "partial D3D11.1 support on Windows 7" features, could not >> find that page at a quick glance. In D3D11.1 one creates an immutable blend >> state that has the desired logic operation on a render target: >> >> ID3D11Device1::CreateBlendState1: >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx >> -> D3D11_BLEND_DESC1: >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx >> -> D3D11_RENDER_TARGET_BLEND_DESC1: >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx >> -> D3D11_LOGIC_OP: >> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx >> >> >> 2015-05-26 18:54 GMT+03:00 Florian B?sch : >> >>> A few remarks: >>> >>> glLogicOp interacts with the rest of the blending machinery, so >>> supporting blend equation advanced via that function might be tricky. Also >>> it'd be quite difficult to ensure non-coherent undefinedness using this >>> route. Fortunately the blend equation advanced extensions also exist for >>> desktop GL. However they're some of the very latest extensions in ARB >>> status, and so support might come in different (non ARB) flavours or not at >>> all. >>> >>> The blend barrier function should be no problem to support on the >>> extension object provided the extension is provided by the underlying >>> extension rather than emulated via other functionality. >>> >>> Support is difficult to gauge, but it's probably not great. This >>> capability index tracks it on desktop GL at 2% >>> http://feedback.wildfiregames.com/report/opengl/ >>> >>> I would guesstimate support on mobiles would be similarly low for the >>> time being. >>> >>> An open question would be how you get that behavior into Direct3D of >>> course. Can somebody elaborate on that point? >>> >>> Regardless of that, I'd encourage you to propose an extension definition >>> (via git pull request) for this functionality, this will help direct the >>> discussion away from idle speculation on a ML and into something with real >>> consequences for stakeholders (it's not real until you spec it). >>> >>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki wrote: >>> >>>> Currently neither GLES2 core or WebGL1 supports exclusive-or blending. >>>> Desktop OpenGL since something like 1.4 has had this and more via glLogicOp >>>> functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml >>>> and GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I >>>> think GLES3 didn't add it back either, but my GL spec lawyer stamina is too >>>> low to actually check the pdf). Don't know the reason why since OpenGL >>>> decision making is not open in the public, but if I had to guess, some >>>> vendor x with chip y on OS z was not able to support it efficiently and >>>> wanted it gone, probably basing the argument on it not being a very common >>>> functionality, and/or that the renderable texture format family that was >>>> chosen to GLES2 core didn't feel appropriate enough. >>>> >>>> Not sure if glLogicOp support should be a prerequisite for >>>> WEBGL_blend_equation_advanced, though the other blend modes than xor sound >>>> like they don't need bitwise ops being supported. >>>> >>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >>>> >>>>> KHR_blend_equation_advanced adds some interesting new color blend >>>>> modes such as multiply, screen, overlay and more. I think these warrant >>>>> particular attention on the web platform because they correspond to some of >>>>> the 2D context's more recent composite modes. Consider the mapping of >>>>> globalCompositeMode to OpenGL blend modes: >>>>> >>>>> "source-over", "source-in", "source-out", "source-atop", >>>>> "destination-over", "destination-in", "destination-out", >>>>> "destination-atop", "lighter", "copy": all possible with existing blend >>>>> modes >>>>> "xor": don't know? >>>>> "multiply": MULTIPLY_KHR >>>>> "screen": SCREEN_KHR >>>>> "overlay": OVERLAY_KHR >>>>> "darken": DARKEN_KHR >>>>> "lighten": LIGHTEN_KHR >>>>> "color-dodge": COLORDODGE_KHR >>>>> "color-burn": COLORBURN_KHR >>>>> "hard-light": HARDLIGHT_KHR >>>>> "soft-light": SOFTLIGHT_KHR >>>>> "difference": DIFFERENCE_KHR >>>>> "exclusion": EXCLUSION_KHR >>>>> "hue": HSL_HUE_KHR >>>>> "saturation": HSL_SATURATION_KHR >>>>> "color": HSL_COLOR_KHR >>>>> "luminosity": HSL_LUMINOSITY_KHR >>>>> >>>>> The mapping is pretty much perfect. I don't know if there's a blend >>>>> mode that covers "xor", but if there is (and I'd be interested to know!) >>>>> then the mapping is perfect. >>>>> >>>>> This extension has a few use cases: >>>>> - Improve consistency across the web platform, by bringing the WebGL >>>>> and 2D context's capabilities closer together. This makes it easier to >>>>> build 2D WebGL applications that are equivalent to their canvas2d >>>>> counterparts. >>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>>>> (browser vendors may be interested in a JS implementation of >>>>> CanvasRenderingContext2D for performance reasons) >>>>> - provide useful blending modes without making authors resort to >>>>> writing their own shaders and having to know all the formulae involved >>>>> - provide a performance guarantee, since the blending uses >>>>> hardware/driver-authored implementations and minimises the necessary draw >>>>> calls/state changes to use these blend modes, avoiding inefficient >>>>> implementations by developers (or possibly even exceeding what they can >>>>> achieve even in the best case depending on if the driver uses any special >>>>> optimisations) >>>>> >>>>> It also appears to be a relatively small API surface, mainly >>>>> introducing new enums for blendEquation. >>>>> >>>>> Some questions/risks: >>>>> - I don't know what the GPU support for this is like in the wild >>>>> across desktop and mobile, although I've read it's part of the Android >>>>> Extension Pack which suggests some mobile support >>>>> - I don't know enough about this area to comment on the suitability of >>>>> the "coherent" version or the "blendBarrier" function's suitability in a >>>>> WebGL context >>>>> - if GPU support is not broad, developers may feel that a fallback is >>>>> still necessary so developers will need to write their own shaders for >>>>> these blend modes anyway, eliminating some of the benefits >>>>> >>>>> Still, these blend modes were deemed suitable for the 2D context so I >>>>> feel it would be useful to have them in WebGL too. In our particular case >>>>> as developers of a 2D HTML5 game engine, this would simplify our code and >>>>> improve consistency with the 2D context fallback. >>>>> >>>>> Ashley Gullen >>>>> Scirra.com >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Tue May 26 15:34:49 2015 From: ash...@ (Ashley Gullen) Date: Tue, 26 May 2015 23:34:49 +0100 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: I'm not sure how to mark up a proposal or how the whole pull request thing is supposed to be done, so I drafted a proposal and I'm just attaching it as a .txt file. Someone can do something more official with this if they like! On 26 May 2015 at 20:42, Vladimir Vukicevic wrote: > XOR got supported on Canvas 2D due to an artifact of it being a mapping of > Apple's canvas/CoreGraphics APIs. It's at best poorly supported today, at > least with any reasonable performance. > > I don't see any downside to proposing this extension, but I suspect that > all the WebGL implementors are currently busy working on their WebGL 2 > implementations, and even beyond that I'd suggest that GL ES 3.1-equivalent > functionality would take precedence. Then again, it would not be a > difficult extension to implement, especially if it was only exposed if the > underlying graphics API had support. > > - Vlad > > > On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen wrote: > >> TBH I don't care much for the xor effect, I don't think it's terribly >> useful - it was a weird choice to support it in canvas2d - and if it's not >> possible to support then that's fine by me. I'm more interested in the >> photoshop style blends like screen and multiply. I'll do a little research >> in to the D3D11 side of things and write a draft definition. >> >> Ashley >> >> >> On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: >> >>> Direct3D 11.1 adds support for logic ops via blend states: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target >>> , which is present on Windows 8 and Windows Phone 8. I am not sure if this >>> is one of the "partial D3D11.1 support on Windows 7" features, could not >>> find that page at a quick glance. In D3D11.1 one creates an immutable blend >>> state that has the desired logic operation on a render target: >>> >>> ID3D11Device1::CreateBlendState1: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx >>> -> D3D11_BLEND_DESC1: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx >>> -> D3D11_RENDER_TARGET_BLEND_DESC1: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx >>> -> D3D11_LOGIC_OP: >>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx >>> >>> >>> 2015-05-26 18:54 GMT+03:00 Florian B?sch : >>> >>>> A few remarks: >>>> >>>> glLogicOp interacts with the rest of the blending machinery, so >>>> supporting blend equation advanced via that function might be tricky. Also >>>> it'd be quite difficult to ensure non-coherent undefinedness using this >>>> route. Fortunately the blend equation advanced extensions also exist for >>>> desktop GL. However they're some of the very latest extensions in ARB >>>> status, and so support might come in different (non ARB) flavours or not at >>>> all. >>>> >>>> The blend barrier function should be no problem to support on the >>>> extension object provided the extension is provided by the underlying >>>> extension rather than emulated via other functionality. >>>> >>>> Support is difficult to gauge, but it's probably not great. This >>>> capability index tracks it on desktop GL at 2% >>>> http://feedback.wildfiregames.com/report/opengl/ >>>> >>>> I would guesstimate support on mobiles would be similarly low for the >>>> time being. >>>> >>>> An open question would be how you get that behavior into Direct3D of >>>> course. Can somebody elaborate on that point? >>>> >>>> Regardless of that, I'd encourage you to propose an extension >>>> definition (via git pull request) for this functionality, this will help >>>> direct the discussion away from idle speculation on a ML and into something >>>> with real consequences for stakeholders (it's not real until you spec it). >>>> >>>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki >>>> wrote: >>>> >>>>> Currently neither GLES2 core or WebGL1 supports exclusive-or blending. >>>>> Desktop OpenGL since something like 1.4 has had this and more via glLogicOp >>>>> functionality: >>>>> https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and GLES1.1 >>>>> had it as well, but for some reason, GLES2 removed glLogicOp (I think GLES3 >>>>> didn't add it back either, but my GL spec lawyer stamina is too low to >>>>> actually check the pdf). Don't know the reason why since OpenGL decision >>>>> making is not open in the public, but if I had to guess, some vendor x with >>>>> chip y on OS z was not able to support it efficiently and wanted it gone, >>>>> probably basing the argument on it not being a very common functionality, >>>>> and/or that the renderable texture format family that was chosen to GLES2 >>>>> core didn't feel appropriate enough. >>>>> >>>>> Not sure if glLogicOp support should be a prerequisite for >>>>> WEBGL_blend_equation_advanced, though the other blend modes than xor sound >>>>> like they don't need bitwise ops being supported. >>>>> >>>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >>>>> >>>>>> KHR_blend_equation_advanced adds some interesting new color blend >>>>>> modes such as multiply, screen, overlay and more. I think these warrant >>>>>> particular attention on the web platform because they correspond to some of >>>>>> the 2D context's more recent composite modes. Consider the mapping of >>>>>> globalCompositeMode to OpenGL blend modes: >>>>>> >>>>>> "source-over", "source-in", "source-out", "source-atop", >>>>>> "destination-over", "destination-in", "destination-out", >>>>>> "destination-atop", "lighter", "copy": all possible with existing blend >>>>>> modes >>>>>> "xor": don't know? >>>>>> "multiply": MULTIPLY_KHR >>>>>> "screen": SCREEN_KHR >>>>>> "overlay": OVERLAY_KHR >>>>>> "darken": DARKEN_KHR >>>>>> "lighten": LIGHTEN_KHR >>>>>> "color-dodge": COLORDODGE_KHR >>>>>> "color-burn": COLORBURN_KHR >>>>>> "hard-light": HARDLIGHT_KHR >>>>>> "soft-light": SOFTLIGHT_KHR >>>>>> "difference": DIFFERENCE_KHR >>>>>> "exclusion": EXCLUSION_KHR >>>>>> "hue": HSL_HUE_KHR >>>>>> "saturation": HSL_SATURATION_KHR >>>>>> "color": HSL_COLOR_KHR >>>>>> "luminosity": HSL_LUMINOSITY_KHR >>>>>> >>>>>> The mapping is pretty much perfect. I don't know if there's a blend >>>>>> mode that covers "xor", but if there is (and I'd be interested to know!) >>>>>> then the mapping is perfect. >>>>>> >>>>>> This extension has a few use cases: >>>>>> - Improve consistency across the web platform, by bringing the WebGL >>>>>> and 2D context's capabilities closer together. This makes it easier to >>>>>> build 2D WebGL applications that are equivalent to their canvas2d >>>>>> counterparts. >>>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>>>>> (browser vendors may be interested in a JS implementation of >>>>>> CanvasRenderingContext2D for performance reasons) >>>>>> - provide useful blending modes without making authors resort to >>>>>> writing their own shaders and having to know all the formulae involved >>>>>> - provide a performance guarantee, since the blending uses >>>>>> hardware/driver-authored implementations and minimises the necessary draw >>>>>> calls/state changes to use these blend modes, avoiding inefficient >>>>>> implementations by developers (or possibly even exceeding what they can >>>>>> achieve even in the best case depending on if the driver uses any special >>>>>> optimisations) >>>>>> >>>>>> It also appears to be a relatively small API surface, mainly >>>>>> introducing new enums for blendEquation. >>>>>> >>>>>> Some questions/risks: >>>>>> - I don't know what the GPU support for this is like in the wild >>>>>> across desktop and mobile, although I've read it's part of the Android >>>>>> Extension Pack which suggests some mobile support >>>>>> - I don't know enough about this area to comment on the suitability >>>>>> of the "coherent" version or the "blendBarrier" function's suitability in a >>>>>> WebGL context >>>>>> - if GPU support is not broad, developers may feel that a fallback is >>>>>> still necessary so developers will need to write their own shaders for >>>>>> these blend modes anyway, eliminating some of the benefits >>>>>> >>>>>> Still, these blend modes were deemed suitable for the 2D context so I >>>>>> feel it would be useful to have them in WebGL too. In our particular case >>>>>> as developers of a 2D HTML5 game engine, this would simplify our code and >>>>>> improve consistency with the 2D context fallback. >>>>>> >>>>>> Ashley Gullen >>>>>> Scirra.com >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- WEBGL_blend_equation_advanced extension proposal Name: WEBGL_blend_equation_advanced Contact: public_webgl...@ Contributors: ashley...@, members of the WebGL working group Last modified: 26th May 2015 Revision: 1 Number: WebGL extension #?? Dependencies: Written against the WebGL API 1.0 specification Overview: This extension exposes the KHR_blend_equation_advanced functionality to WebGL. CanvasRenderingContext2D provides a series of common blend functions with globalComposeOperation, such as "multiply" and "screen". KHR_blend_equation_advanced provides, with the exception of "xor", exactly the same list of blend functions for WebGL, as detailed below: "multiply": MULTIPLY_KHR "screen": SCREEN_KHR "overlay": OVERLAY_KHR "darken": DARKEN_KHR "lighten": LIGHTEN_KHR "color-dodge": COLORDODGE_KHR "color-burn": COLORBURN_KHR "hard-light": HARDLIGHT_KHR "soft-light": SOFTLIGHT_KHR "difference": DIFFERENCE_KHR "exclusion": EXCLUSION_KHR "hue": HSL_HUE_KHR "saturation": HSL_SATURATION_KHR "color": HSL_COLOR_KHR "luminosity": HSL_LUMINOSITY_KHR Providing these blend modes to WebGL improves the consistency across the web platform by bringing WebGL and CanvasRenderingContext2D's capabilities closer together, making it easier to port 2D content to WebGL. It increases the opportunity for polyfilling/implementing the 2D context with WebGL, and provides convenient common blend modes without requiring authors to write the shaders and implement the rendering modes for them. When this extension is enabled, the blendEquation entry points are extended to accept the enums in the IDL below. IDL: [NoInterfaceObject] interface WEBGL_blend_equation_advanced { const GLenum MULTIPLY = 0x9294; const GLenum SCREEN = 0x9295; const GLenum OVERLAY = 0x9296; const GLenum DARKEN = 0x9297; const GLenum LIGHTEN = 0x9298; const GLenum COLORDODGE = 0x9299; const GLenum COLORBURN = 0x929A; const GLenum HARDLIGHT = 0x929B; const GLenum SOFTLIGHT = 0x929C; const GLenum DIFFERENCE = 0x929E; const GLenum EXCLUSION = 0x92A0; const GLenum HSL_HUE = 0x92AD; const GLenum HSL_SATURATION = 0x92AE; const GLenum HSL_COLOR = 0x92AF; const GLenum HSL_LUMINOSITY = 0x92B0; }; Sample code: var ext = gl.getExtension("WEBGL_blend_equation_advanced"); gl.blendEquation(ext.MULTIPLY); gl.getParameter(gl.BLEND_EQUATION) == ext.MULTIPLY; Issues: (0) What is the adoption of KHR_blend_equation_advanced in the wild? (1) Can implementors provide fallbacks if support is missing, or should WebGL developers provide their own? (2) Should the "coherent" variant and blendBarrier entry point be supported? (3) Should an equivalent to the "xor" globalComposeOperation be supported? Implementation notes: KHR_blend_equation_advanced: https://www.opengl.org/registry/specs/KHR/blend_equation_advanced.txt May need an equivalent feature in D3D11 - starting point could be:https://msdn.microsoft.com/en-us/library/windows/desktop/ff476200(v=vs.85).aspx Direct2D also offers a similar list of blend modes: https://msdn.microsoft.com/ru-ru/dn934217 Revision history: Revision 1, 2015-05-26: Initial revision From kbr...@ Tue May 26 17:24:24 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 26 May 2015 17:24:24 -0700 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: The majority of the work in exposing this extension would be writing conformance tests. It looks like the drawElements test suite has some tests of this extension: https://android.googlesource.com/platform/external/deqp/+/master/modules/gles31/functional/es31fAdvancedBlendTests.cpp . They'd need to be ported to JavaScript and WebGL. Given that device support for the extension is pretty low, though, it'd be more profitable to write a JavaScript library that would either provide similar functionality to this extension, or polyfill it altogether. Assuming there's no support for it in the OpenGL driver, implementing this extension in the browser won't make it run significantly faster than a JavaScript implementation. The same technique of ping-ponging the source and destination textures and implementing the blending equations in a shader can be implemented with basically the same speed in JavaScript as it can in the WebGL implementation -- and if that's not the case, then that's something that needs to be fixed in the browser to make all WebGL apps run faster. Fixing bugs and passing the WebGL 2.0 conformance suite is at the top of our priority list right now -- so I'd agree with Vlad's assessment that this particular extension shouldn't delay that work. -Ken On Tue, May 26, 2015 at 3:34 PM, Ashley Gullen wrote: > I'm not sure how to mark up a proposal or how the whole pull request thing > is supposed to be done, so I drafted a proposal and I'm just attaching it as > a .txt file. Someone can do something more official with this if they like! > > On 26 May 2015 at 20:42, Vladimir Vukicevic wrote: >> >> XOR got supported on Canvas 2D due to an artifact of it being a mapping of >> Apple's canvas/CoreGraphics APIs. It's at best poorly supported today, at >> least with any reasonable performance. >> >> I don't see any downside to proposing this extension, but I suspect that >> all the WebGL implementors are currently busy working on their WebGL 2 >> implementations, and even beyond that I'd suggest that GL ES 3.1-equivalent >> functionality would take precedence. Then again, it would not be a >> difficult extension to implement, especially if it was only exposed if the >> underlying graphics API had support. >> >> - Vlad >> >> >> On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen wrote: >>> >>> TBH I don't care much for the xor effect, I don't think it's terribly >>> useful - it was a weird choice to support it in canvas2d - and if it's not >>> possible to support then that's fine by me. I'm more interested in the >>> photoshop style blends like screen and multiply. I'll do a little research >>> in to the D3D11 side of things and write a draft definition. >>> >>> Ashley >>> >>> >>> On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: >>>> >>>> Direct3D 11.1 adds support for logic ops via blend states: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target >>>> , which is present on Windows 8 and Windows Phone 8. I am not sure if this >>>> is one of the "partial D3D11.1 support on Windows 7" features, could not >>>> find that page at a quick glance. In D3D11.1 one creates an immutable blend >>>> state that has the desired logic operation on a render target: >>>> >>>> ID3D11Device1::CreateBlendState1: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx >>>> -> D3D11_BLEND_DESC1: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx >>>> -> D3D11_RENDER_TARGET_BLEND_DESC1: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx >>>> -> D3D11_LOGIC_OP: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx >>>> >>>> >>>> 2015-05-26 18:54 GMT+03:00 Florian B?sch : >>>>> >>>>> A few remarks: >>>>> >>>>> glLogicOp interacts with the rest of the blending machinery, so >>>>> supporting blend equation advanced via that function might be tricky. Also >>>>> it'd be quite difficult to ensure non-coherent undefinedness using this >>>>> route. Fortunately the blend equation advanced extensions also exist for >>>>> desktop GL. However they're some of the very latest extensions in ARB >>>>> status, and so support might come in different (non ARB) flavours or not at >>>>> all. >>>>> >>>>> The blend barrier function should be no problem to support on the >>>>> extension object provided the extension is provided by the underlying >>>>> extension rather than emulated via other functionality. >>>>> >>>>> Support is difficult to gauge, but it's probably not great. This >>>>> capability index tracks it on desktop GL at 2% >>>>> http://feedback.wildfiregames.com/report/opengl/ >>>>> >>>>> I would guesstimate support on mobiles would be similarly low for the >>>>> time being. >>>>> >>>>> An open question would be how you get that behavior into Direct3D of >>>>> course. Can somebody elaborate on that point? >>>>> >>>>> Regardless of that, I'd encourage you to propose an extension >>>>> definition (via git pull request) for this functionality, this will help >>>>> direct the discussion away from idle speculation on a ML and into something >>>>> with real consequences for stakeholders (it's not real until you spec it). >>>>> >>>>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki >>>>> wrote: >>>>>> >>>>>> Currently neither GLES2 core or WebGL1 supports exclusive-or blending. >>>>>> Desktop OpenGL since something like 1.4 has had this and more via glLogicOp >>>>>> functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and >>>>>> GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I >>>>>> think GLES3 didn't add it back either, but my GL spec lawyer stamina is too >>>>>> low to actually check the pdf). Don't know the reason why since OpenGL >>>>>> decision making is not open in the public, but if I had to guess, some >>>>>> vendor x with chip y on OS z was not able to support it efficiently and >>>>>> wanted it gone, probably basing the argument on it not being a very common >>>>>> functionality, and/or that the renderable texture format family that was >>>>>> chosen to GLES2 core didn't feel appropriate enough. >>>>>> >>>>>> Not sure if glLogicOp support should be a prerequisite for >>>>>> WEBGL_blend_equation_advanced, though the other blend modes than xor sound >>>>>> like they don't need bitwise ops being supported. >>>>>> >>>>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >>>>>>> >>>>>>> KHR_blend_equation_advanced adds some interesting new color blend >>>>>>> modes such as multiply, screen, overlay and more. I think these warrant >>>>>>> particular attention on the web platform because they correspond to some of >>>>>>> the 2D context's more recent composite modes. Consider the mapping of >>>>>>> globalCompositeMode to OpenGL blend modes: >>>>>>> >>>>>>> "source-over", "source-in", "source-out", "source-atop", >>>>>>> "destination-over", "destination-in", "destination-out", "destination-atop", >>>>>>> "lighter", "copy": all possible with existing blend modes >>>>>>> "xor": don't know? >>>>>>> "multiply": MULTIPLY_KHR >>>>>>> "screen": SCREEN_KHR >>>>>>> "overlay": OVERLAY_KHR >>>>>>> "darken": DARKEN_KHR >>>>>>> "lighten": LIGHTEN_KHR >>>>>>> "color-dodge": COLORDODGE_KHR >>>>>>> "color-burn": COLORBURN_KHR >>>>>>> "hard-light": HARDLIGHT_KHR >>>>>>> "soft-light": SOFTLIGHT_KHR >>>>>>> "difference": DIFFERENCE_KHR >>>>>>> "exclusion": EXCLUSION_KHR >>>>>>> "hue": HSL_HUE_KHR >>>>>>> "saturation": HSL_SATURATION_KHR >>>>>>> "color": HSL_COLOR_KHR >>>>>>> "luminosity": HSL_LUMINOSITY_KHR >>>>>>> >>>>>>> The mapping is pretty much perfect. I don't know if there's a blend >>>>>>> mode that covers "xor", but if there is (and I'd be interested to know!) >>>>>>> then the mapping is perfect. >>>>>>> >>>>>>> This extension has a few use cases: >>>>>>> - Improve consistency across the web platform, by bringing the WebGL >>>>>>> and 2D context's capabilities closer together. This makes it easier to build >>>>>>> 2D WebGL applications that are equivalent to their canvas2d counterparts. >>>>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>>>>>> (browser vendors may be interested in a JS implementation of >>>>>>> CanvasRenderingContext2D for performance reasons) >>>>>>> - provide useful blending modes without making authors resort to >>>>>>> writing their own shaders and having to know all the formulae involved >>>>>>> - provide a performance guarantee, since the blending uses >>>>>>> hardware/driver-authored implementations and minimises the necessary draw >>>>>>> calls/state changes to use these blend modes, avoiding inefficient >>>>>>> implementations by developers (or possibly even exceeding what they can >>>>>>> achieve even in the best case depending on if the driver uses any special >>>>>>> optimisations) >>>>>>> >>>>>>> It also appears to be a relatively small API surface, mainly >>>>>>> introducing new enums for blendEquation. >>>>>>> >>>>>>> Some questions/risks: >>>>>>> - I don't know what the GPU support for this is like in the wild >>>>>>> across desktop and mobile, although I've read it's part of the Android >>>>>>> Extension Pack which suggests some mobile support >>>>>>> - I don't know enough about this area to comment on the suitability >>>>>>> of the "coherent" version or the "blendBarrier" function's suitability in a >>>>>>> WebGL context >>>>>>> - if GPU support is not broad, developers may feel that a fallback is >>>>>>> still necessary so developers will need to write their own shaders for these >>>>>>> blend modes anyway, eliminating some of the benefits >>>>>>> >>>>>>> Still, these blend modes were deemed suitable for the 2D context so I >>>>>>> feel it would be useful to have them in WebGL too. In our particular case as >>>>>>> developers of a 2D HTML5 game engine, this would simplify our code and >>>>>>> improve consistency with the 2D context fallback. >>>>>>> >>>>>>> Ashley Gullen >>>>>>> Scirra.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: unsubscribe public_webgl ----------------------------------------------------------- From oet...@ Tue May 26 23:27:59 2015 From: oet...@ (Olli Etuaho) Date: Wed, 27 May 2015 06:27:59 +0000 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: , Message-ID: <1432708078955.51376@nvidia.com> Hi, as it happens I already have a WebGL implementation of advanced blend modes in my hobby project: https://github.com/Oletus/glbrush.js/blob/master/compositing_shader.js If there's a lot of interest, I could make that a more easily reusable component. A native implementation would be quite significantly faster and easier to use though, and this is very useful functionality. So I think an extension is worth considering even if support is limited today. -Olli ________________________________________ From: owners-public_webgl...@ on behalf of Kenneth Russell Sent: Wednesday, May 27, 2015 3:24 AM To: Ashley Gullen Cc: Vladimir Vukicevic; Jukka Jyl?nki; Florian B?sch; public_webgl...@ Subject: Re: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced The majority of the work in exposing this extension would be writing conformance tests. It looks like the drawElements test suite has some tests of this extension: https://android.googlesource.com/platform/external/deqp/+/master/modules/gles31/functional/es31fAdvancedBlendTests.cpp . They'd need to be ported to JavaScript and WebGL. Given that device support for the extension is pretty low, though, it'd be more profitable to write a JavaScript library that would either provide similar functionality to this extension, or polyfill it altogether. Assuming there's no support for it in the OpenGL driver, implementing this extension in the browser won't make it run significantly faster than a JavaScript implementation. The same technique of ping-ponging the source and destination textures and implementing the blending equations in a shader can be implemented with basically the same speed in JavaScript as it can in the WebGL implementation -- and if that's not the case, then that's something that needs to be fixed in the browser to make all WebGL apps run faster. Fixing bugs and passing the WebGL 2.0 conformance suite is at the top of our priority list right now -- so I'd agree with Vlad's assessment that this particular extension shouldn't delay that work. -Ken On Tue, May 26, 2015 at 3:34 PM, Ashley Gullen wrote: > I'm not sure how to mark up a proposal or how the whole pull request thing > is supposed to be done, so I drafted a proposal and I'm just attaching it as > a .txt file. Someone can do something more official with this if they like! > > On 26 May 2015 at 20:42, Vladimir Vukicevic wrote: >> >> XOR got supported on Canvas 2D due to an artifact of it being a mapping of >> Apple's canvas/CoreGraphics APIs. It's at best poorly supported today, at >> least with any reasonable performance. >> >> I don't see any downside to proposing this extension, but I suspect that >> all the WebGL implementors are currently busy working on their WebGL 2 >> implementations, and even beyond that I'd suggest that GL ES 3.1-equivalent >> functionality would take precedence. Then again, it would not be a >> difficult extension to implement, especially if it was only exposed if the >> underlying graphics API had support. >> >> - Vlad >> >> >> On Tue, May 26, 2015 at 1:48 PM, Ashley Gullen wrote: >>> >>> TBH I don't care much for the xor effect, I don't think it's terribly >>> useful - it was a weird choice to support it in canvas2d - and if it's not >>> possible to support then that's fine by me. I'm more interested in the >>> photoshop style blends like screen and multiply. I'll do a little research >>> in to the D3D11 side of things and write a draft definition. >>> >>> Ashley >>> >>> >>> On 26 May 2015 at 17:09, Jukka Jyl?nki wrote: >>>> >>>> Direct3D 11.1 adds support for logic ops via blend states: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562%28v=vs.85%29.aspx#use_logical_operations_in_a_render_target >>>> , which is present on Windows 8 and Windows Phone 8. I am not sure if this >>>> is one of the "partial D3D11.1 support on Windows 7" features, could not >>>> find that page at a quick glance. In D3D11.1 one creates an immutable blend >>>> state that has the desired logic operation on a render target: >>>> >>>> ID3D11Device1::CreateBlendState1: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404577(v=vs.85).aspx >>>> -> D3D11_BLEND_DESC1: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404435(v=vs.85).aspx >>>> -> D3D11_RENDER_TARGET_BLEND_DESC1: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404492(v=vs.85).aspx >>>> -> D3D11_LOGIC_OP: >>>> https://msdn.microsoft.com/en-us/library/windows/desktop/hh404484(v=vs.85).aspx >>>> >>>> >>>> 2015-05-26 18:54 GMT+03:00 Florian B?sch : >>>>> >>>>> A few remarks: >>>>> >>>>> glLogicOp interacts with the rest of the blending machinery, so >>>>> supporting blend equation advanced via that function might be tricky. Also >>>>> it'd be quite difficult to ensure non-coherent undefinedness using this >>>>> route. Fortunately the blend equation advanced extensions also exist for >>>>> desktop GL. However they're some of the very latest extensions in ARB >>>>> status, and so support might come in different (non ARB) flavours or not at >>>>> all. >>>>> >>>>> The blend barrier function should be no problem to support on the >>>>> extension object provided the extension is provided by the underlying >>>>> extension rather than emulated via other functionality. >>>>> >>>>> Support is difficult to gauge, but it's probably not great. This >>>>> capability index tracks it on desktop GL at 2% >>>>> http://feedback.wildfiregames.com/report/opengl/ >>>>> >>>>> I would guesstimate support on mobiles would be similarly low for the >>>>> time being. >>>>> >>>>> An open question would be how you get that behavior into Direct3D of >>>>> course. Can somebody elaborate on that point? >>>>> >>>>> Regardless of that, I'd encourage you to propose an extension >>>>> definition (via git pull request) for this functionality, this will help >>>>> direct the discussion away from idle speculation on a ML and into something >>>>> with real consequences for stakeholders (it's not real until you spec it). >>>>> >>>>> On Tue, May 26, 2015 at 5:40 PM, Jukka Jyl?nki >>>>> wrote: >>>>>> >>>>>> Currently neither GLES2 core or WebGL1 supports exclusive-or blending. >>>>>> Desktop OpenGL since something like 1.4 has had this and more via glLogicOp >>>>>> functionality: https://www.opengl.org/sdk/docs/man/html/glLogicOp.xhtml and >>>>>> GLES1.1 had it as well, but for some reason, GLES2 removed glLogicOp (I >>>>>> think GLES3 didn't add it back either, but my GL spec lawyer stamina is too >>>>>> low to actually check the pdf). Don't know the reason why since OpenGL >>>>>> decision making is not open in the public, but if I had to guess, some >>>>>> vendor x with chip y on OS z was not able to support it efficiently and >>>>>> wanted it gone, probably basing the argument on it not being a very common >>>>>> functionality, and/or that the renderable texture format family that was >>>>>> chosen to GLES2 core didn't feel appropriate enough. >>>>>> >>>>>> Not sure if glLogicOp support should be a prerequisite for >>>>>> WEBGL_blend_equation_advanced, though the other blend modes than xor sound >>>>>> like they don't need bitwise ops being supported. >>>>>> >>>>>> 2015-05-26 18:12 GMT+03:00 Ashley Gullen : >>>>>>> >>>>>>> KHR_blend_equation_advanced adds some interesting new color blend >>>>>>> modes such as multiply, screen, overlay and more. I think these warrant >>>>>>> particular attention on the web platform because they correspond to some of >>>>>>> the 2D context's more recent composite modes. Consider the mapping of >>>>>>> globalCompositeMode to OpenGL blend modes: >>>>>>> >>>>>>> "source-over", "source-in", "source-out", "source-atop", >>>>>>> "destination-over", "destination-in", "destination-out", "destination-atop", >>>>>>> "lighter", "copy": all possible with existing blend modes >>>>>>> "xor": don't know? >>>>>>> "multiply": MULTIPLY_KHR >>>>>>> "screen": SCREEN_KHR >>>>>>> "overlay": OVERLAY_KHR >>>>>>> "darken": DARKEN_KHR >>>>>>> "lighten": LIGHTEN_KHR >>>>>>> "color-dodge": COLORDODGE_KHR >>>>>>> "color-burn": COLORBURN_KHR >>>>>>> "hard-light": HARDLIGHT_KHR >>>>>>> "soft-light": SOFTLIGHT_KHR >>>>>>> "difference": DIFFERENCE_KHR >>>>>>> "exclusion": EXCLUSION_KHR >>>>>>> "hue": HSL_HUE_KHR >>>>>>> "saturation": HSL_SATURATION_KHR >>>>>>> "color": HSL_COLOR_KHR >>>>>>> "luminosity": HSL_LUMINOSITY_KHR >>>>>>> >>>>>>> The mapping is pretty much perfect. I don't know if there's a blend >>>>>>> mode that covers "xor", but if there is (and I'd be interested to know!) >>>>>>> then the mapping is perfect. >>>>>>> >>>>>>> This extension has a few use cases: >>>>>>> - Improve consistency across the web platform, by bringing the WebGL >>>>>>> and 2D context's capabilities closer together. This makes it easier to build >>>>>>> 2D WebGL applications that are equivalent to their canvas2d counterparts. >>>>>>> - make it easier to polyfill/extend/implement canvas2d via WebGL >>>>>>> (browser vendors may be interested in a JS implementation of >>>>>>> CanvasRenderingContext2D for performance reasons) >>>>>>> - provide useful blending modes without making authors resort to >>>>>>> writing their own shaders and having to know all the formulae involved >>>>>>> - provide a performance guarantee, since the blending uses >>>>>>> hardware/driver-authored implementations and minimises the necessary draw >>>>>>> calls/state changes to use these blend modes, avoiding inefficient >>>>>>> implementations by developers (or possibly even exceeding what they can >>>>>>> achieve even in the best case depending on if the driver uses any special >>>>>>> optimisations) >>>>>>> >>>>>>> It also appears to be a relatively small API surface, mainly >>>>>>> introducing new enums for blendEquation. >>>>>>> >>>>>>> Some questions/risks: >>>>>>> - I don't know what the GPU support for this is like in the wild >>>>>>> across desktop and mobile, although I've read it's part of the Android >>>>>>> Extension Pack which suggests some mobile support >>>>>>> - I don't know enough about this area to comment on the suitability >>>>>>> of the "coherent" version or the "blendBarrier" function's suitability in a >>>>>>> WebGL context >>>>>>> - if GPU support is not broad, developers may feel that a fallback is >>>>>>> still necessary so developers will need to write their own shaders for these >>>>>>> blend modes anyway, eliminating some of the benefits >>>>>>> >>>>>>> Still, these blend modes were deemed suitable for the 2D context so I >>>>>>> feel it would be useful to have them in WebGL too. In our particular case as >>>>>>> developers of a 2D HTML5 game engine, this would simplify our code and >>>>>>> improve consistency with the 2D context fallback. >>>>>>> >>>>>>> Ashley Gullen >>>>>>> Scirra.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: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed May 27 01:50:00 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 27 May 2015 10:50:00 +0200 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: <1432708078955.51376@nvidia.com> References: <1432708078955.51376@nvidia.com> Message-ID: I personally feel like the advanced blending extension isn't very useful. In the non-coherent case, which is easily emulated by sampling two textures and producing a third, a shader affords a lot more flexibility and control (remember that the non-coherent case is undefined in case a fragment gets written twice between barriers). The non-coherent case is also the one most easily "shimmed", that is structure your code in a fashion that's oblivious to the underlying functionality (which is something you'd need to do in order to deal with an extension that has a very low support rate). The coherent case behaves more like traditional blending, in that multiple overdraws of a fragment all blend between blend barriers. However this case cannot be shimmed in any fashion, and so the code that'd rely on it would be stuck to nearly never work for the forseeable future, hence making the effort to use it a bad investment of time. The one case where the extension does offer a tangible new functionality (bit-wise XOR) is probably also the one that'd be least interesting to use, but will be doable come WebGL 2 because of the ES 3.0 bitwise XOR operator (^). Based on that reasoning, I'd cast my vote to reject this extension if it was proposed, and I'd like to see it properly proposed so that we can reject it and capture the reason for why it was rejected permanently. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Wed May 27 02:22:28 2015 From: khr...@ (Mark Callow) Date: Wed, 27 May 2015 18:22:28 +0900 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: References: Message-ID: <281CA776-91B3-4F29-B1CC-4987C90A0828@callow.im> > On May 27, 2015, at 2:48 AM, Ashley Gullen wrote: > > TBH I don't care much for the xor effect, I don't think it's terribly useful - it was a weird choice to support it in canvas2d - and if it's not possible to support then that's fine by me. I'm more interested in the photoshop style blends like screen and multiply. I'll do a little research in to the D3D11 side of things and write a draft definition. > +10. xor should have been banned when color displays were introduced. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Wed May 27 04:39:03 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 27 May 2015 13:39:03 +0200 Subject: [Public WebGL] Extension suggestion: WEBGL_blend_equation_advanced In-Reply-To: <281CA776-91B3-4F29-B1CC-4987C90A0828@callow.im> References: <281CA776-91B3-4F29-B1CC-4987C90A0828@callow.im> Message-ID: XOR is a hypothetically interesting blending mode if you're doing some bit-fiddling GPGPU work. However you're far more likely to use the stencil buffer for that (which supports XOR), read from a stencil texture (if we'll ever introduce that to webgl) or use the ES 3.0 XOR operator. On Wed, May 27, 2015 at 11:22 AM, Mark Callow wrote: > > > On May 27, 2015, at 2:48 AM, Ashley Gullen wrote: > > > > TBH I don't care much for the xor effect, I don't think it's terribly > useful - it was a weird choice to support it in canvas2d - and if it's not > possible to support then that's fine by me. I'm more interested in the > photoshop style blends like screen and multiply. I'll do a little research > in to the D3D11 side of things and write a draft definition. > > > > +10. xor should have been banned when color displays were introduced. > > Regards > > -Mark > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri May 29 17:03:59 2015 From: kbr...@ (Kenneth Russell) Date: Fri, 29 May 2015 17:03:59 -0700 Subject: [Public WebGL] Ratified extension wrappers Message-ID: The WebGL wrappers for the OpenGL ES extensions EXT_blend_minmax, EXT_frag_depth and EXT_shader_texture_lod have been moved to Ratified status after vote by the Khronos Board of Promoters. Thanks to all who contributed to these wrappers. https://www.khronos.org/registry/webgl/extensions/ -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl -----------------------------------------------------------