From pya...@ Mon Jun 1 03:58:26 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 1 Jun 2015 12:58:26 +0200 Subject: [Public WebGL] frame timing and continous scaling Message-ID: I have a usecase where I need to measure how long a frame took (in total JS+GPU+pre/post frame overhead) for dynamic scaling. What I currently do for that is measure a moving average of interframe times and adjust a scaling factor (gauss-seidel relaxed) to 30 fps. This method does not work to hit framerates of 60 (or whatever the UA wants to limit to) because it exhibits hysteresis since it doesn't know how far it is above 60fps (and because the UA immediately steps down to 30fps if it can't hit 60). Here are the things that won't work: 1. Use performance.now: 1. intraframe: Does not work because doesn't capture GPU processing end and does not capture pre/post frame overhead 2. interframe: Does not work because of UA fps limiting 2. Use timer queries: 1. intraframe: Does not work because it doesn't capture pre/post frame overhead 2. interframe: Does not work because of UA fps limiting 3. Use performance.mark: That's just performance.now with labels 4. Toggle off FPS limiting: does not work in a production setting (development only measure) Would it be possible to add an API to navigator.performance? - performance.frameTime (this would indicate the true measured frame time) - performance.frameTimeLimit (this would indicate what target the UA is limiting to) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Jun 2 19:44:40 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Jun 2015 19:44:40 -0700 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: I'm not sure that the number you're looking for is well defined. Consider the situation in Chrome on a multi-core machine, where GPU commands are issued from JavaScript and executed in parallel in a different process. In the best case there is perfect overlap between JS execution and GPU command execution. A naive sum of these times might yield a result over 16.67 milliseconds, but the application might be able to achieve a steady-state 60 FPS framerate because of the overlap of the current frame's JS and the previous frame's GPU commands. I'd recommend you ask this question on graphics-dev...@ for Chromium specifically, since the engineers who know the compositor's scheduling algorithms are all on that list. If these numbers are known to the browser already, then a good way to proceed would be to prototype exposing them to JavaScript and see whether they'd solve the problem in practice. As an aside, I haven't witnessed requestAnimationFrame being throttled to 30 FPS by UAs. At least Chrome and Firefox on my Mac laptop will both render content with irregular frame times (resulting in the app measuring anywhere between 30 and 60 FPS) if they're GPU bound. I don't understand the details of the algorithm you've described, but perhaps having a window near 60 FPS where the algorithm either maintains the current scene complexity, or periodically tries to increase it, it would avoid the problem of it immediately dropping to 30 FPS because it doesn't know how much faster than 60 FPS the content could potentially render. -Ken On Mon, Jun 1, 2015 at 3:58 AM, Florian B?sch wrote: > I have a usecase where I need to measure how long a frame took (in total > JS+GPU+pre/post frame overhead) for dynamic scaling. > > What I currently do for that is measure a moving average of interframe > times and adjust a scaling factor (gauss-seidel relaxed) to 30 fps. > > This method does not work to hit framerates of 60 (or whatever the UA > wants to limit to) because it exhibits hysteresis since it doesn't know how > far it is above 60fps (and because the UA immediately steps down to 30fps > if it can't hit 60). > > Here are the things that won't work: > > 1. Use performance.now: > 1. intraframe: Does not work because doesn't capture GPU processing > end and does not capture pre/post frame overhead > 2. interframe: Does not work because of UA fps limiting > 2. Use timer queries: > 1. intraframe: Does not work because it doesn't capture pre/post > frame overhead > 2. interframe: Does not work because of UA fps limiting > 3. Use performance.mark: That's just performance.now with labels > 4. Toggle off FPS limiting: does not work in a production setting > (development only measure) > > Would it be possible to add an API to navigator.performance? > > - performance.frameTime (this would indicate the true measured frame > time) > - performance.frameTimeLimit (this would indicate what target the UA > is limiting to) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 3 00:42:54 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 3 Jun 2015 09:42:54 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Let me state the problem quite simply: How much stuff can we do in JS/GPU land *before* we fall out of a consistent and regular composition synced framerate. *Definitions* - JS-land: everything that blocks production of the next frame (i.e. everything on the main thread) - GPU-land: everything that blocks compositing of that frame (i.e. the compositor has to wait till the GPUs done) - before: this means before a degradation (to the user) becomes evident (i.e. framerate dropping) - consistent and regular composition synced: this means that everytime the UA wants to composit a frame, a frame has been produced and is ready from the WebGL context *Related (but mostly solved) problems* - Measuring JS execution time: This is a good measure to see how much time you spend per frame in the JS main thread JS execution (and related utility code like DOM) - Measuring GPU execution time (timer queries): This is a good measure to see how much time you spend on the GPU doing which task - Measuring interframe times: This is a good measure to identify if you already do have a problem *Problem Relevance* It might not be clear as to why this is an important problem to solve for everybody. Therefore I'll paste a couple of links that relate to the topic: - Blur busters UFO test: http://www.testufo.com/ - http://en.wikipedia.org/wiki/Micro_stuttering - http://blog.tojicode.com/2014/07/bringing-vr-to-chrome.html - https://docs.google.com/presentation/d/1q2WU0LusCyQFKDMjOSWLj3xGeOxMWmLzConrC8euJpA/edit#slide=id.g297180da4_0443 In a nutshell, this is about that UAs (should) try to hit a native (display) framerate consistently for a page. Everything that page does that moves (video playback, GIF cycling, JS animations of html, WebGL, Canvas 2D, etc.) depends on stutter free (and fast) turnover of that cycle. Native applications do have some advantages in that regard (they can claim processing/GPU time exclusively, toggle off vsync etc. and don't nearly as many things as a UA). If one WebGL context or the JS main thread does something to interrupt that cycle, everything on the page suffers (including that WebGL context). Let's suppose you're trying to nail 60FPS (16.66ms/frame). And for some reason (JS or GPU execution time) the cycle takes say 18ms. Depending on UA implementation, a variety of problems now ensues (framerate drop down to 30fps/jittering/stuttering/frame-tearing/etc.) On Wed, Jun 3, 2015 at 4:44 AM, Kenneth Russell wrote: > I'm not sure that the number you're looking for is well defined. Consider > the situation in Chrome on a multi-core machine, where GPU commands are > issued from JavaScript and executed in parallel in a different process. In > the best case there is perfect overlap between JS execution and GPU command > execution. A naive sum of these times might yield a result over 16.67 > milliseconds, but the application might be able to achieve a steady-state > 60 FPS framerate because of the overlap of the current frame's JS and the > previous frame's GPU commands. > I don't think this matters much because it's not about how much time you spend where, but how fast a complete frame for display in the tab could have composited, starting the count before anything for that frame is done, and stopping after it's *known* to be completely submitted. > As an aside, I haven't witnessed requestAnimationFrame being throttled to > 30 FPS by UAs. At least Chrome and Firefox on my Mac laptop will both > render content with irregular frame times (resulting in the app measuring > anywhere between 30 and 60 FPS) if they're GPU bound. > I can illustrate the issue when I get around to plot some frame-time charts. > I don't understand the details of the algorithm you've described, but > perhaps having a window near 60 FPS where the algorithm either maintains > the current scene complexity, or periodically tries to increase it, it > would avoid the problem of it immediately dropping to 30 FPS because it > doesn't know how much faster than 60 FPS the content could potentially > render. > Maintaining 30fps is actually better than maintaining 16,32,32,16,32,16,32,16,32,16,32 (microstuttering). -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jun 6 05:36:06 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 14:36:06 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: On Wed, Jun 3, 2015 at 9:42 AM, Florian B?sch wrote: > > As an aside, I haven't witnessed requestAnimationFrame being throttled to >> 30 FPS by UAs. At least Chrome and Firefox on my Mac laptop will both >> render content with irregular frame times (resulting in the app measuring >> anywhere between 30 and 60 FPS) if they're GPU bound. >> > I can illustrate the issue when I get around to plot some frame-time > charts. > I have written a tool (http://codeflow.org/issues/timing/) to measure exactly this. Here's 4 saved plots for google chrome on linux: http://codeflow.org/issues/timing/saved/google-chrome-linux.png These plots clearly show that frame timings fall predominantly between 16.6ms and 33.3ms at the transition regions, and they also show that google Chrome somehow magically knows when to toggle. For the rising load case that could be explained by a heuristic of when chrome starts to skip frames. But for the falling load case this is a wee bit mysterious. How does chrome know the load enters a transition region coming from (throttled) 30fps and switching to 60fps unless chrome does indeed have some kind of idea how long frames take to render... -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jun 6 05:52:26 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 14:52:26 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: I've also done the test (http://codeflow.org/issues/timing/) with firefox on linux. The results are pretty bad, and I present them without further comment. [image: Inline image 1] [image: Inline image 2] The rest of saves here: http://codeflow.org/issues/timing/saved/firefox-linux.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: medium-static.png Type: image/png Size: 22307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minimal-static.png Type: image/png Size: 24071 bytes Desc: not available URL: From pya...@ Sat Jun 6 06:20:26 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 15:20:26 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Here are the tests with google chrome on windows with the same machine. Lots of microstuttering once things fall below 60fps. Low static load (no microstuttering): [image: Inline image 1] High static load (below 60fps, lots of microstuttering): [image: Inline image 2] Rising load coming from faster than 60fps (no microstuttering) and degrading to 30fps and worse (bad microstuttering all the way). [image: Inline image 3] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: google-chrome-windows-low-static-load.png Type: image/png Size: 29891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: google-chrome-windows-high-static-load.png Type: image/png Size: 32017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: google-chrome-windows-rising-load.png Type: image/png Size: 32574 bytes Desc: not available URL: From pya...@ Sat Jun 6 06:29:04 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 15:29:04 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: The same test on the same machine on windows. Remarkably better behaved than on linux (and better than chrome). Although it's dubious to me how having uneven frame-times (that chrome on windows also exhibits) will be effective to address v-sync busting (which emphasizes how important it would be to have a means to stay above 60fps). Also notice the huge off the charts spike towards the end, I guess that was a 200ms+ GC cycle. [image: Inline image 1] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-windows-rising-load.png Type: image/png Size: 12477 bytes Desc: not available URL: From pya...@ Sat Jun 6 06:45:42 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 15:45:42 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Running the same test (http://codeflow.org/issues/timing/) on IE on Win8 exhibits the same symptoms of uneven framerates (so a lot of vsync busting), and increased microstutter once you go below 60fps. The transition region between "things are good" and "now it's bad" is also very small, giving a developer preciously little room to detect when a drop from 60fps is imminent. Static load [image: Inline image 1] Rising load [image: Inline image 4] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IE-rising-load.png Type: image/png Size: 18664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IE-low-static-load.png Type: image/png Size: 17557 bytes Desc: not available URL: From pya...@ Sat Jun 6 07:13:32 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 16:13:32 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Running the tests (http://codeflow.org/issues/timing/) on OSX as well, and this also reveals remarkably bad results once dropping below 60fps. Chrome: [image: Inline image 1] Firefox: [image: Inline image 2] Note how here again frame times are clamped roughly between 16.6ms and 33.3ms (quite similar to chrome on linux). However unlike chrome on linux, these exhibit hysteresis all the way. Safari: [image: Inline image 3] It needs to be noted, that although the RAF curve for safari looks quite good, the display experienced by the user in this case is incredibly choppy (this is because uneven frame timings bust vsync/composition sync). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-osx-rising.png Type: image/png Size: 44959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: safari-osx-rising.png Type: image/png Size: 35610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-osx-rising.png Type: image/png Size: 35093 bytes Desc: not available URL: From pya...@ Sat Jun 6 08:57:47 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 6 Jun 2015 17:57:47 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Here's the test repeated on iOS which I think is fairly interesting: [image: Inline image 1] There's still lots of microstuttering but it's at least not all over the place and cleanly clamps to 60fps and 30fps. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ios.jpeg Type: image/jpeg Size: 24447 bytes Desc: not available URL: From pya...@ Sun Jun 7 00:43:46 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 7 Jun 2015 09:43:46 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Investigating this issue a bit more I came to some conclusions. I've also extended the test tool to measure/display both interframe time (grey) and intraframe time (red) and added options for different synchronizing methods. The conclusions first, the observational evidence after. - In order to avoid going below 60fps where all the microstepping and degradation dragons live, it's required to know when that would happen. - I have proposed to solve that problem with an API, but the resonance from UA vendors is neglible, and so I have to assume it's going to take considerable time (if ever) when that issue gets addressed (wtg here WebGL, competing with native platforms, naaat) - In lieu of a solution emerging, it's up to JS app developers to get around that problem somehow - The "getting around it" part is degrading performance and force a synchronize start and end of a frame, so as to get a measure how close we are to stepping below 60fps. - Unfortunately, forcing a synchronize (proverbially gl.finish) doesn't work in every user-agent, and so we'll have to find methods to do that which UAs haven't borked up. - If you are on google chrome or IE, insert a gl.readPixels at the start and end of a frame. Don't use gl.finish, it doesn't do anything. - If you are on firefox or safari, never use gl.readPixels, it seriously degrades everything. However gl.finish works as intended. - Even if we find a solution to consistently across browsers synchronize, it's going to cost us considerable performance. However if given a choice to ridiculously undershoot hardware capabilities (by a factor of say 10000%) in order not to fall below 60fps, or sacrifice ~30% of performance to get a smooth/jitter-free application, or live with ridiculously low framerates and lots of jittering for a sizable percentage of our users, it's not really that much of a contest. *Chrome on windows* Here is where we want to be (ideally). This is a rising JS load test (no webgl) in chrome which nicely shows how well behaved this can be (and what we want to get out of UAs). [image: Inline image 1] Of course if we toggle to a WebGL load test without any synchronization it looks like this, no indication whatsoever when we're going to drive into a wall. [image: Inline image 2] Unfortunately, the same is true in chrome when calling gl.finish as well: [image: Inline image 3] I have tried various other methods (flush, texImage2D, bufferData) and they don't have any appreciatable effect. The only two that do have an effect is readPixels and getError. Get error is not very helpful however. [image: Inline image 4] So the last command to synchronize things that can work is readPixels, and low and behold, it does work as intended. However this costs us roughly 30% of performance. [image: Inline image 7] *Internet Explorer* Internet explorer doesn't implement even frame division stepping. So at a rising load and no finish no attempt at FPS stepping is evident (other than the 60fps clamping). [image: Inline image 8] And like in Chrome, gl.finish doesn't seem to do a whole lot (though it does a little more than in Chrome). [image: Inline image 9] Also like in Chrome, gl.readPixels is about the only solution left: [image: Inline image 10] *Firefox on windows* Firefox also doesn't implement even frame division stepping. And like IE, after the 60fps clamping, interframe times just keep rising. Unlike chrome, firefox seems to spend a considerable amount of time in JS for a few simple loops. [image: Inline image 11] Here however readPixels seriously mucks things up. [image: Inline image 12] Luckily, gl.finish is much better behaved: [image: Inline image 13] I have run these tests on Linux so far also comparing UAs, and have arrived at similar results. It's possible this is different on OSX, and it might also depend on the GPU. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-finish.png Type: image/png Size: 23858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-readpixels.png Type: image/png Size: 38455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-finish.png Type: image/png Size: 15888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-no-finish.png Type: image/png Size: 23303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-geterror.png Type: image/png Size: 37302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-no-finish.png Type: image/png Size: 20432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-stepping-test.png Type: image/png Size: 33185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-readpixels.png Type: image/png Size: 17618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-readpixels.png Type: image/png Size: 25220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-finish.png Type: image/png Size: 33506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-nofinish.png Type: image/png Size: 34282 bytes Desc: not available URL: From thu...@ Sun Jun 7 00:52:37 2015 From: thu...@ (Ben Adams) Date: Sun, 7 Jun 2015 08:52:37 +0100 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Could you could throttle to 30fps by skipping any work in a rAF that is < 30ms of the end of previous rAF? On 7 June 2015 at 08:43, Florian B?sch wrote: > Investigating this issue a bit more I came to some conclusions. I've also > extended the test tool to measure/display both interframe time (grey) and > intraframe time (red) and added options for different synchronizing > methods. The conclusions first, the observational evidence after. > > - In order to avoid going below 60fps where all the microstepping and > degradation dragons live, it's required to know when that would happen. > - I have proposed to solve that problem with an API, but the resonance > from UA vendors is neglible, and so I have to assume it's going to take > considerable time (if ever) when that issue gets addressed (wtg here WebGL, > competing with native platforms, naaat) > - In lieu of a solution emerging, it's up to JS app developers to get > around that problem somehow > - The "getting around it" part is degrading performance and force a > synchronize start and end of a frame, so as to get a measure how close we > are to stepping below 60fps. > - Unfortunately, forcing a synchronize (proverbially gl.finish) > doesn't work in every user-agent, and so we'll have to find methods to do > that which UAs haven't borked up. > - If you are on google chrome or IE, insert a gl.readPixels at the > start and end of a frame. Don't use gl.finish, it doesn't do anything. > - If you are on firefox or safari, never use gl.readPixels, it > seriously degrades everything. However gl.finish works as intended. > - Even if we find a solution to consistently across browsers > synchronize, it's going to cost us considerable performance. However if > given a choice to ridiculously undershoot hardware capabilities (by a > factor of say 10000%) in order not to fall below 60fps, or sacrifice ~30% > of performance to get a smooth/jitter-free application, or live with > ridiculously low framerates and lots of jittering for a sizable percentage > of our users, it's not really that much of a contest. > > *Chrome on windows* > > Here is where we want to be (ideally). This is a rising JS load test (no > webgl) in chrome which nicely shows how well behaved this can be (and what > we want to get out of UAs). > > [image: Inline image 1] > > Of course if we toggle to a WebGL load test without any synchronization it > looks like this, no indication whatsoever when we're going to drive into a > wall. > > [image: Inline image 2] > > Unfortunately, the same is true in chrome when calling gl.finish as well: > > [image: Inline image 3] > > I have tried various other methods (flush, texImage2D, bufferData) and > they don't have any appreciatable effect. The only two that do have an > effect is readPixels and getError. Get error is not very helpful however. > > [image: Inline image 4] > > So the last command to synchronize things that can work is readPixels, and > low and behold, it does work as intended. However this costs us roughly 30% > of performance. > > [image: Inline image 7] > > *Internet Explorer* > > Internet explorer doesn't implement even frame division stepping. So at a > rising load and no finish no attempt at FPS stepping is evident (other than > the 60fps clamping). > > [image: Inline image 8] > > And like in Chrome, gl.finish doesn't seem to do a whole lot (though it > does a little more than in Chrome). > > [image: Inline image 9] > > Also like in Chrome, gl.readPixels is about the only solution left: > > [image: Inline image 10] > > *Firefox on windows* > > Firefox also doesn't implement even frame division stepping. And like IE, > after the 60fps clamping, interframe times just keep rising. Unlike chrome, > firefox seems to spend a considerable amount of time in JS for a few simple > loops. > [image: Inline image 11] > > Here however readPixels seriously mucks things up. > > [image: Inline image 12] > > Luckily, gl.finish is much better behaved: > > [image: Inline image 13] > > > I have run these tests on Linux so far also comparing UAs, and have > arrived at similar results. It's possible this is different on OSX, and it > might also depend on the GPU. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-readpixels.png Type: image/png Size: 38455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-nofinish.png Type: image/png Size: 34282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-readpixels.png Type: image/png Size: 25220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-finish.png Type: image/png Size: 15888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-finish.png Type: image/png Size: 23858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-stepping-test.png Type: image/png Size: 33185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-no-finish.png Type: image/png Size: 20432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-no-finish.png Type: image/png Size: 23303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-geterror.png Type: image/png Size: 37302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-readpixels.png Type: image/png Size: 17618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-finish.png Type: image/png Size: 33506 bytes Desc: not available URL: From pya...@ Sun Jun 7 01:18:49 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 7 Jun 2015 10:18:49 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: I don't know, I think it could be problematic because of hysteresis, but you'd have to basically try. If it works or not could also depend on the UA (and if it attempts even frame division stepping) or not, and the GPU/OS/driver, which can also muck things up in that regard. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Jun 7 01:27:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 7 Jun 2015 10:27:05 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: I've also ran this comparison on OSX with the same conclusion as on windows. use start/end frame synchronization. With chrome use gl.readPixels to synchronize with other UAs use gl.finish. Safari reference without synchronization: [image: Inline image 1] Safari with synchronization. An outstanding example nearly perfect behavior. [image: Inline image 2] Firefox reference without finish. [image: Inline image 3] Firefox with finish: [image: Inline image 4] Chrome reference without finish. [image: Inline image 5] Chrome with finish (gl.readPixels) [image: Inline image 6] I've ran these test as well with the integrated Intel HD GPU. The results are basically the same, although a bit more noisy and the intel driver seems to do some odd scaling things by itself, but the basic method still works. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-osx-nofinish.png Type: image/png Size: 46365 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-osx-finish.png Type: image/png Size: 29106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: safari-osx-finish.png Type: image/png Size: 41166 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-osx-readpixels.png Type: image/png Size: 44815 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: safari-osx-nofinish.png Type: image/png Size: 40026 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-osx-nofinish.png Type: image/png Size: 33870 bytes Desc: not available URL: From pya...@ Sun Jun 7 01:33:40 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 7 Jun 2015 10:33:40 +0200 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Oh, also if the browser doesn't do even frame division stepping, then 60fps is the only synchronized display frequency. So even if you skip rAFs, you will not be 30fps synchronized, and so you'll get a lot of microstuttering/jittering/frame-tearing. Aiming at 60fps is really the only method to get even a chance to avoid all that. On Sun, Jun 7, 2015 at 9:52 AM, Ben Adams wrote: > Could you could throttle to 30fps by skipping any work in a rAF that is < > 30ms of the end of previous rAF? > > > On 7 June 2015 at 08:43, Florian B?sch wrote: > >> Investigating this issue a bit more I came to some conclusions. I've also >> extended the test tool to measure/display both interframe time (grey) and >> intraframe time (red) and added options for different synchronizing >> methods. The conclusions first, the observational evidence after. >> >> - In order to avoid going below 60fps where all the microstepping and >> degradation dragons live, it's required to know when that would happen. >> - I have proposed to solve that problem with an API, but the >> resonance from UA vendors is neglible, and so I have to assume it's going >> to take considerable time (if ever) when that issue gets addressed (wtg >> here WebGL, competing with native platforms, naaat) >> - In lieu of a solution emerging, it's up to JS app developers to get >> around that problem somehow >> - The "getting around it" part is degrading performance and force a >> synchronize start and end of a frame, so as to get a measure how close we >> are to stepping below 60fps. >> - Unfortunately, forcing a synchronize (proverbially gl.finish) >> doesn't work in every user-agent, and so we'll have to find methods to do >> that which UAs haven't borked up. >> - If you are on google chrome or IE, insert a gl.readPixels at the >> start and end of a frame. Don't use gl.finish, it doesn't do anything. >> - If you are on firefox or safari, never use gl.readPixels, it >> seriously degrades everything. However gl.finish works as intended. >> - Even if we find a solution to consistently across browsers >> synchronize, it's going to cost us considerable performance. However if >> given a choice to ridiculously undershoot hardware capabilities (by a >> factor of say 10000%) in order not to fall below 60fps, or sacrifice ~30% >> of performance to get a smooth/jitter-free application, or live with >> ridiculously low framerates and lots of jittering for a sizable percentage >> of our users, it's not really that much of a contest. >> >> *Chrome on windows* >> >> Here is where we want to be (ideally). This is a rising JS load test (no >> webgl) in chrome which nicely shows how well behaved this can be (and what >> we want to get out of UAs). >> >> [image: Inline image 1] >> >> Of course if we toggle to a WebGL load test without any synchronization >> it looks like this, no indication whatsoever when we're going to drive into >> a wall. >> >> [image: Inline image 2] >> >> Unfortunately, the same is true in chrome when calling gl.finish as well: >> >> [image: Inline image 3] >> >> I have tried various other methods (flush, texImage2D, bufferData) and >> they don't have any appreciatable effect. The only two that do have an >> effect is readPixels and getError. Get error is not very helpful however. >> >> [image: Inline image 4] >> >> So the last command to synchronize things that can work is readPixels, >> and low and behold, it does work as intended. However this costs us roughly >> 30% of performance. >> >> [image: Inline image 7] >> >> *Internet Explorer* >> >> Internet explorer doesn't implement even frame division stepping. So at a >> rising load and no finish no attempt at FPS stepping is evident (other than >> the 60fps clamping). >> >> [image: Inline image 8] >> >> And like in Chrome, gl.finish doesn't seem to do a whole lot (though it >> does a little more than in Chrome). >> >> [image: Inline image 9] >> >> Also like in Chrome, gl.readPixels is about the only solution left: >> >> [image: Inline image 10] >> >> *Firefox on windows* >> >> Firefox also doesn't implement even frame division stepping. And like IE, >> after the 60fps clamping, interframe times just keep rising. Unlike chrome, >> firefox seems to spend a considerable amount of time in JS for a few simple >> loops. >> [image: Inline image 11] >> >> Here however readPixels seriously mucks things up. >> >> [image: Inline image 12] >> >> Luckily, gl.finish is much better behaved: >> >> [image: Inline image 13] >> >> >> I have run these tests on Linux so far also comparing UAs, and have >> arrived at similar results. It's possible this is different on OSX, and it >> might also depend on the GPU. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-readpixels.png Type: image/png Size: 17618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-readpixels.png Type: image/png Size: 38455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-geterror.png Type: image/png Size: 37302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-no-finish.png Type: image/png Size: 20432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-readpixels.png Type: image/png Size: 25220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-no-finish.png Type: image/png Size: 23303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-nofinish.png Type: image/png Size: 34282 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-stepping-test.png Type: image/png Size: 33185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-finish.png Type: image/png Size: 15888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-finish.png Type: image/png Size: 33506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-finish.png Type: image/png Size: 23858 bytes Desc: not available URL: From flo...@ Sat Jun 13 03:47:13 2015 From: flo...@ (Floh) Date: Sat, 13 Jun 2015 12:47:13 +0200 Subject: [Public WebGL] WebGL vs Khronos GLSL compiler: illegal chars in inactive #if / #endif blocks Message-ID: Hi, I just noticed that the WebGL compilers at least in Firefox, Chrome and Safari on OSX reject shader source code when #if/#endif blocks that are not taken contain illegal characters (in my case a '$'), while the Khronos reference compiler doesn't complain about this. Now I know that WebGL might do additional shader validation that the Khronos compiler doesn't know/care about, but when looking for similar bugs in the FF and Chrome bug trackers I found that a similar problem existed a few years ago with illegal characters in comments. My question is whether shader source in inactive #if/#endif blocks should be treated like a comment and not be included in the validation (for instance the code in inactive #if/#endif blocks could be meant for other platforms, if the shader source was generated and contains conditionally compiled code for multiple platforms). Basically, whether the current behaviour is an implementation bug (which I'm happy to write tickets for), or whether it 'works as intended'? The WebGL spec is not very clear, and only mentions comments, and non-ASCII characters (but a '$' is clearly a valid ASCII character): https://www.khronos.org/registry/webgl/specs/1.0/#6.19 Also, the error reporting could be better. Chrome and Safari just say "WebGL: INVALID_VALUE: shaderSource: string not ASCII" in the JS console, Firefox at least tells me the ASCII code of the character I should look for: "Error: WebGL: shaderSource: String contains the illegal character '36'", but both don't tell me the location in the shader source code where the problems occurs. Cheers, -Floh. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon Jun 15 13:56:00 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 15 Jun 2015 13:56:00 -0700 Subject: [Public WebGL] WebGL vs Khronos GLSL compiler: illegal chars in inactive #if / #endif blocks In-Reply-To: References: Message-ID: First, sorry about the poor error message -- for Chrome at least, please feel free to file a bug with a test case about it. It should at least state that the string doesn't conform to the ASCII subset allowed by GLSL ES. The restriction is correct, and comes from section 3.1 "Character Set" in the GLSL ES 1.0.17 spec. "$" isn't a legal character in any GLSL ES shader, regardless of whether it's in an #if block that's compiled out. WebGL inherits this behavior from GLSL ES. I agree that https://www.khronos.org/registry/webgl/specs/1.0/#6.19 could be clearer. We don't want to unnecessarily replicate the table from the GLSL ES spec, but perhaps there could be a more explicit mention of the GLSL ES rules. -Ken On Sat, Jun 13, 2015 at 3:47 AM, Floh wrote: > > Hi, > > I just noticed that the WebGL compilers at least in Firefox, Chrome > and Safari on OSX reject shader source code when #if/#endif blocks > that are not taken contain illegal characters (in my case a '$'), > while the Khronos reference compiler doesn't complain about this. Now > I know that WebGL might do additional shader validation that the > Khronos compiler doesn't know/care about, but when looking for similar > bugs in the FF and Chrome bug trackers I found that a similar problem > existed a few years ago with illegal characters in comments. > > My question is whether shader source in inactive #if/#endif blocks > should be treated like a comment and not be included in the validation > (for instance the code in inactive #if/#endif blocks could be meant > for other platforms, if the shader source was generated and contains > conditionally compiled code for multiple platforms). Basically, > whether the current behaviour is an implementation bug (which I'm > happy to write tickets for), or whether it 'works as intended'? > > The WebGL spec is not very clear, and only mentions comments, and > non-ASCII characters (but a '$' is clearly a valid ASCII character): > > https://www.khronos.org/registry/webgl/specs/1.0/#6.19 > > Also, the error reporting could be better. Chrome and Safari just say > "WebGL: INVALID_VALUE: shaderSource: string not ASCII" in the JS > console, Firefox at least tells me the ASCII code of the character I > should look for: "Error: WebGL: shaderSource: String contains the > illegal character '36'", but both don't tell me the location in the > shader source code where the problems occurs. > > Cheers, > -Floh. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Mon Jun 15 15:34:52 2015 From: baj...@ (Brandon Jones) Date: Mon, 15 Jun 2015 22:34:52 +0000 Subject: [Public WebGL] Error catching with getBufferSubData Message-ID: Something I noticed today while working on Chrome's implementation of this function. The implied underlying call to glMapBufferRange may return a NULL pointer if the call fails for some reason. This provides a way to do efficient error handling. The WebGL function, however, passes in an ArrayBuffer to be populated and returns nothing, which means the only way to communicate a failure is via getError. It's poor API design to require getError calls after an otherwise valid API call just to ensure it worked. I propose we update the spec to have getBufferSubData return a GLboolean or similar to indicate whether or not the mapping succeeded. That way getError calls can be avoided unless we know the mapping failed. Any concerns with this approach? --Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 15 15:52:05 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 15 Jun 2015 15:52:05 -0700 Subject: [Public WebGL] frame timing and continous scaling In-Reply-To: References: Message-ID: Sorry for the long delay replying. Dealing with WebGL stability bugs on newly deployed automated test machines. Have talked with a couple of folks who work on Chrome's scheduler, which decides when to fire requestAnimationFrame callbacks, among other things. Some observations but no firm conclusions yet. I'd like to avoid posting my half-baked thoughts here, so let me continue to discuss with these folks off-list and we'll post some conclusions afterward. Thanks, -Ken On Sun, Jun 7, 2015 at 1:33 AM, Florian B?sch wrote: > Oh, also if the browser doesn't do even frame division stepping, then > 60fps is the only synchronized display frequency. So even if you skip rAFs, > you will not be 30fps synchronized, and so you'll get a lot of > microstuttering/jittering/frame-tearing. Aiming at 60fps is really the only > method to get even a chance to avoid all that. > > On Sun, Jun 7, 2015 at 9:52 AM, Ben Adams > wrote: > >> Could you could throttle to 30fps by skipping any work in a rAF that is < >> 30ms of the end of previous rAF? >> >> >> On 7 June 2015 at 08:43, Florian B?sch wrote: >> >>> Investigating this issue a bit more I came to some conclusions. I've >>> also extended the test tool to measure/display both interframe time (grey) >>> and intraframe time (red) and added options for different synchronizing >>> methods. The conclusions first, the observational evidence after. >>> >>> - In order to avoid going below 60fps where all the microstepping >>> and degradation dragons live, it's required to know when that would happen. >>> - I have proposed to solve that problem with an API, but the >>> resonance from UA vendors is neglible, and so I have to assume it's going >>> to take considerable time (if ever) when that issue gets addressed (wtg >>> here WebGL, competing with native platforms, naaat) >>> - In lieu of a solution emerging, it's up to JS app developers to >>> get around that problem somehow >>> - The "getting around it" part is degrading performance and force a >>> synchronize start and end of a frame, so as to get a measure how close we >>> are to stepping below 60fps. >>> - Unfortunately, forcing a synchronize (proverbially gl.finish) >>> doesn't work in every user-agent, and so we'll have to find methods to do >>> that which UAs haven't borked up. >>> - If you are on google chrome or IE, insert a gl.readPixels at the >>> start and end of a frame. Don't use gl.finish, it doesn't do anything. >>> - If you are on firefox or safari, never use gl.readPixels, it >>> seriously degrades everything. However gl.finish works as intended. >>> - Even if we find a solution to consistently across browsers >>> synchronize, it's going to cost us considerable performance. However if >>> given a choice to ridiculously undershoot hardware capabilities (by a >>> factor of say 10000%) in order not to fall below 60fps, or sacrifice ~30% >>> of performance to get a smooth/jitter-free application, or live with >>> ridiculously low framerates and lots of jittering for a sizable percentage >>> of our users, it's not really that much of a contest. >>> >>> *Chrome on windows* >>> >>> Here is where we want to be (ideally). This is a rising JS load test (no >>> webgl) in chrome which nicely shows how well behaved this can be (and what >>> we want to get out of UAs). >>> >>> [image: Inline image 1] >>> >>> Of course if we toggle to a WebGL load test without any synchronization >>> it looks like this, no indication whatsoever when we're going to drive into >>> a wall. >>> >>> [image: Inline image 2] >>> >>> Unfortunately, the same is true in chrome when calling gl.finish as well: >>> >>> [image: Inline image 3] >>> >>> I have tried various other methods (flush, texImage2D, bufferData) and >>> they don't have any appreciatable effect. The only two that do have an >>> effect is readPixels and getError. Get error is not very helpful however. >>> >>> [image: Inline image 4] >>> >>> So the last command to synchronize things that can work is readPixels, >>> and low and behold, it does work as intended. However this costs us roughly >>> 30% of performance. >>> >>> [image: Inline image 7] >>> >>> *Internet Explorer* >>> >>> Internet explorer doesn't implement even frame division stepping. So at >>> a rising load and no finish no attempt at FPS stepping is evident (other >>> than the 60fps clamping). >>> >>> [image: Inline image 8] >>> >>> And like in Chrome, gl.finish doesn't seem to do a whole lot (though it >>> does a little more than in Chrome). >>> >>> [image: Inline image 9] >>> >>> Also like in Chrome, gl.readPixels is about the only solution left: >>> >>> [image: Inline image 10] >>> >>> *Firefox on windows* >>> >>> Firefox also doesn't implement even frame division stepping. And like >>> IE, after the 60fps clamping, interframe times just keep rising. Unlike >>> chrome, firefox seems to spend a considerable amount of time in JS for a >>> few simple loops. >>> [image: Inline image 11] >>> >>> Here however readPixels seriously mucks things up. >>> >>> [image: Inline image 12] >>> >>> Luckily, gl.finish is much better behaved: >>> >>> [image: Inline image 13] >>> >>> >>> I have run these tests on Linux so far also comparing UAs, and have >>> arrived at similar results. It's possible this is different on OSX, and it >>> might also depend on the GPU. >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-finish.png Type: image/png Size: 23858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-geterror.png Type: image/png Size: 37302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-finish.png Type: image/png Size: 33506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-no-finish.png Type: image/png Size: 20432 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-finish.png Type: image/png Size: 15888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-readpixels.png Type: image/png Size: 25220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ie-no-finish.png Type: image/png Size: 23303 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-readpixels.png Type: image/png Size: 17618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-readpixels.png Type: image/png Size: 38455 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-stepping-test.png Type: image/png Size: 33185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chrome-nofinish.png Type: image/png Size: 34282 bytes Desc: not available URL: From kbr...@ Mon Jun 15 16:04:20 2015 From: kbr...@ (Kenneth Russell) Date: Mon, 15 Jun 2015 16:04:20 -0700 Subject: [Public WebGL] Error catching with getBufferSubData In-Reply-To: References: Message-ID: Thanks for catching this oversight. Amending the spec to return a boolean (and stating that the passed ArrayBuffer is unmodified in this case) sounds good. -Ken On Mon, Jun 15, 2015 at 3:34 PM, Brandon Jones wrote: > Something I noticed today while working on Chrome's implementation of this > function. The implied underlying call to glMapBufferRange may return a NULL > pointer if the call fails for some reason. This provides a way to do > efficient error handling. The WebGL function, however, passes in an > ArrayBuffer to be populated and returns nothing, which means the only way to > communicate a failure is via getError. It's poor API design to require > getError calls after an otherwise valid API call just to ensure it worked. > > I propose we update the spec to have getBufferSubData return a GLboolean or > similar to indicate whether or not the mapping succeeded. That way getError > calls can be avoided unless we know the mapping failed. Any concerns with > this approach? > > --Brandon ----------------------------------------------------------- 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 cep...@ Mon Jun 15 16:42:30 2015 From: cep...@ (John Kessenich) Date: Mon, 15 Jun 2015 17:42:30 -0600 Subject: [Public WebGL] WebGL vs Khronos GLSL compiler: illegal chars in inactive #if / #endif blocks In-Reply-To: References: Message-ID: <557F62E6.1000407@frii.com> The early specs say it in terms of "...character set used for the OpenGL ES shading languages...". The ambiguity here is that the "shading language" is arguably what's left after preprocessing, not before. It doesn't say "$" is disallowed from shaders, only that is not a valid character in the shading language, which is arguably a different language than the C++ preprocessor language. ES 3.1 resolved this ambiguity (as did desktop) by saying "The source character set used for the OpenGL ES shading languages is Unicode in the UTF-8 encoding scheme. Invalid UTF-8 characters are ignored. After preprocessing, only the following characters are allowed in the resulting stream of GLSL tokens:..." That may leave things to the practical problem of how existing drivers interpreted the early specs, but it's clear what the long term view is. JohnK On 6/15/2015 2:56 PM, Kenneth Russell wrote: > First, sorry about the poor error message -- for Chrome at least, > please feel free to file a bug with a test case about it. It should at > least state that the string doesn't conform to the ASCII subset > allowed by GLSL ES. > > The restriction is correct, and comes from section 3.1 "Character Set" > in the GLSL ES 1.0.17 spec. "$" isn't a legal character in any GLSL ES > shader, regardless of whether it's in an #if block that's compiled > out. WebGL inherits this behavior from GLSL ES. I agree that > https://www.khronos.org/registry/webgl/specs/1.0/#6.19 could be > clearer. We don't want to unnecessarily replicate the table from the > GLSL ES spec, but perhaps there could be a more explicit mention of > the GLSL ES rules. > > -Ken > > > > On Sat, Jun 13, 2015 at 3:47 AM, Floh wrote: >> Hi, >> >> I just noticed that the WebGL compilers at least in Firefox, Chrome >> and Safari on OSX reject shader source code when #if/#endif blocks >> that are not taken contain illegal characters (in my case a '$'), >> while the Khronos reference compiler doesn't complain about this. Now >> I know that WebGL might do additional shader validation that the >> Khronos compiler doesn't know/care about, but when looking for similar >> bugs in the FF and Chrome bug trackers I found that a similar problem >> existed a few years ago with illegal characters in comments. >> >> My question is whether shader source in inactive #if/#endif blocks >> should be treated like a comment and not be included in the validation >> (for instance the code in inactive #if/#endif blocks could be meant >> for other platforms, if the shader source was generated and contains >> conditionally compiled code for multiple platforms). Basically, >> whether the current behaviour is an implementation bug (which I'm >> happy to write tickets for), or whether it 'works as intended'? >> >> The WebGL spec is not very clear, and only mentions comments, and >> non-ASCII characters (but a '$' is clearly a valid ASCII character): >> >> https://www.khronos.org/registry/webgl/specs/1.0/#6.19 >> >> Also, the error reporting could be better. Chrome and Safari just say >> "WebGL: INVALID_VALUE: shaderSource: string not ASCII" in the JS >> console, Firefox at least tells me the ASCII code of the character I >> should look for: "Error: WebGL: shaderSource: String contains the >> illegal character '36'", but both don't tell me the location in the >> shader source code where the problems occurs. >> >> Cheers, >> -Floh. >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From flo...@ Tue Jun 16 08:26:55 2015 From: flo...@ (Floh) Date: Tue, 16 Jun 2015 17:26:55 +0200 Subject: [Public WebGL] WebGL vs Khronos GLSL compiler: illegal chars in inactive #if / #endif blocks In-Reply-To: <557F62E6.1000407@frii.com> References: <557F62E6.1000407@frii.com> Message-ID: Thanks for clearing that up! Since I'm doing my own preprocessing on the shader sources during the build process I think I will simply add a check for invalid characters there (in addition to invoking the Khronos reference compiler which is really doing a wonderful job of catching errors for the different GLSL versions). Cheers, -Floh. On Tue, Jun 16, 2015 at 1:42 AM, John Kessenich wrote: > The early specs say it in terms of "...character set used for the OpenGL ES > shading languages...". > > The ambiguity here is that the "shading language" is arguably what's left > after preprocessing, not before. It doesn't say "$" is disallowed from > shaders, only that is not a valid character in the shading language, which > is arguably a different language than the C++ preprocessor language. > > ES 3.1 resolved this ambiguity (as did desktop) by saying > > "The source character set used for the OpenGL ES shading languages is > Unicode in the UTF-8 encoding scheme. Invalid UTF-8 characters are ignored. > After preprocessing, only the following characters are allowed in the > resulting stream of GLSL tokens:..." > > That may leave things to the practical problem of how existing drivers > interpreted the early specs, but it's clear what the long term view is. > > JohnK > > > On 6/15/2015 2:56 PM, Kenneth Russell wrote: > > First, sorry about the poor error message -- for Chrome at least, > please feel free to file a bug with a test case about it. It should at > least state that the string doesn't conform to the ASCII subset > allowed by GLSL ES. > > The restriction is correct, and comes from section 3.1 "Character Set" > in the GLSL ES 1.0.17 spec. "$" isn't a legal character in any GLSL ES > shader, regardless of whether it's in an #if block that's compiled > out. WebGL inherits this behavior from GLSL ES. I agree that > https://www.khronos.org/registry/webgl/specs/1.0/#6.19 could be > clearer. We don't want to unnecessarily replicate the table from the > GLSL ES spec, but perhaps there could be a more explicit mention of > the GLSL ES rules. > > -Ken > > > > On Sat, Jun 13, 2015 at 3:47 AM, Floh wrote: > > Hi, > > I just noticed that the WebGL compilers at least in Firefox, Chrome > and Safari on OSX reject shader source code when #if/#endif blocks > that are not taken contain illegal characters (in my case a '$'), > while the Khronos reference compiler doesn't complain about this. Now > I know that WebGL might do additional shader validation that the > Khronos compiler doesn't know/care about, but when looking for similar > bugs in the FF and Chrome bug trackers I found that a similar problem > existed a few years ago with illegal characters in comments. > > My question is whether shader source in inactive #if/#endif blocks > should be treated like a comment and not be included in the validation > (for instance the code in inactive #if/#endif blocks could be meant > for other platforms, if the shader source was generated and contains > conditionally compiled code for multiple platforms). Basically, > whether the current behaviour is an implementation bug (which I'm > happy to write tickets for), or whether it 'works as intended'? > > The WebGL spec is not very clear, and only mentions comments, and > non-ASCII characters (but a '$' is clearly a valid ASCII character): > > https://www.khronos.org/registry/webgl/specs/1.0/#6.19 > > Also, the error reporting could be better. Chrome and Safari just say > "WebGL: INVALID_VALUE: shaderSource: string not ASCII" in the JS > console, Firefox at least tells me the ASCII code of the character I > should look for: "Error: WebGL: shaderSource: String contains the > illegal character '36'", but both don't tell me the location in the > shader source code where the problems occurs. > > Cheers, > -Floh. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Jun 16 15:01:21 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 16 Jun 2015 15:01:21 -0700 Subject: [Public WebGL] WebGL vs Khronos GLSL compiler: illegal chars in inactive #if / #endif blocks In-Reply-To: References: <557F62E6.1000407@frii.com> Message-ID: Thanks John for the clarification. Floh, if it isn't that much trouble for you to eliminate the invalid characters then it would be easiest to leave the current, tested, behavior as is. It's not trivial for WebGL implementations to run the preprocessor separately from shader compilation and thereby eliminate invalid characters that would be in #if blocks eliminated during preprocessing. -Ken On Tue, Jun 16, 2015 at 8:26 AM, Floh wrote: > > Thanks for clearing that up! Since I'm doing my own preprocessing on > the shader sources during the build process I think I will simply add > a check for invalid characters there (in addition to invoking the > Khronos reference compiler which is really doing a wonderful job of > catching errors for the different GLSL versions). > > Cheers, > -Floh. > > On Tue, Jun 16, 2015 at 1:42 AM, John Kessenich wrote: >> The early specs say it in terms of "...character set used for the OpenGL ES >> shading languages...". >> >> The ambiguity here is that the "shading language" is arguably what's left >> after preprocessing, not before. It doesn't say "$" is disallowed from >> shaders, only that is not a valid character in the shading language, which >> is arguably a different language than the C++ preprocessor language. >> >> ES 3.1 resolved this ambiguity (as did desktop) by saying >> >> "The source character set used for the OpenGL ES shading languages is >> Unicode in the UTF-8 encoding scheme. Invalid UTF-8 characters are ignored. >> After preprocessing, only the following characters are allowed in the >> resulting stream of GLSL tokens:..." >> >> That may leave things to the practical problem of how existing drivers >> interpreted the early specs, but it's clear what the long term view is. >> >> JohnK >> >> >> On 6/15/2015 2:56 PM, Kenneth Russell wrote: >> >> First, sorry about the poor error message -- for Chrome at least, >> please feel free to file a bug with a test case about it. It should at >> least state that the string doesn't conform to the ASCII subset >> allowed by GLSL ES. >> >> The restriction is correct, and comes from section 3.1 "Character Set" >> in the GLSL ES 1.0.17 spec. "$" isn't a legal character in any GLSL ES >> shader, regardless of whether it's in an #if block that's compiled >> out. WebGL inherits this behavior from GLSL ES. I agree that >> https://www.khronos.org/registry/webgl/specs/1.0/#6.19 could be >> clearer. We don't want to unnecessarily replicate the table from the >> GLSL ES spec, but perhaps there could be a more explicit mention of >> the GLSL ES rules. >> >> -Ken >> >> >> >> On Sat, Jun 13, 2015 at 3:47 AM, Floh wrote: >> >> Hi, >> >> I just noticed that the WebGL compilers at least in Firefox, Chrome >> and Safari on OSX reject shader source code when #if/#endif blocks >> that are not taken contain illegal characters (in my case a '$'), >> while the Khronos reference compiler doesn't complain about this. Now >> I know that WebGL might do additional shader validation that the >> Khronos compiler doesn't know/care about, but when looking for similar >> bugs in the FF and Chrome bug trackers I found that a similar problem >> existed a few years ago with illegal characters in comments. >> >> My question is whether shader source in inactive #if/#endif blocks >> should be treated like a comment and not be included in the validation >> (for instance the code in inactive #if/#endif blocks could be meant >> for other platforms, if the shader source was generated and contains >> conditionally compiled code for multiple platforms). Basically, >> whether the current behaviour is an implementation bug (which I'm >> happy to write tickets for), or whether it 'works as intended'? >> >> The WebGL spec is not very clear, and only mentions comments, and >> non-ASCII characters (but a '$' is clearly a valid ASCII character): >> >> https://www.khronos.org/registry/webgl/specs/1.0/#6.19 >> >> Also, the error reporting could be better. Chrome and Safari just say >> "WebGL: INVALID_VALUE: shaderSource: string not ASCII" in the JS >> console, Firefox at least tells me the ASCII code of the character I >> should look for: "Error: WebGL: shaderSource: String contains the >> illegal character '36'", but both don't tell me the location in the >> shader source code where the problems occurs. >> >> Cheers, >> -Floh. >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Tue Jun 16 15:18:30 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 16 Jun 2015 15:18:30 -0700 Subject: [Public WebGL] Error catching with getBufferSubData In-Reply-To: References: Message-ID: I disagree: 1) This is inconsistent with the rest of the API. (This is how ReadPixels works) (Not that I like the current API's handling of errors!) 2) This causes getBufferSubData to drift from any previous iteration of glGetBufferSubData in the GL specs. 3) The mapping can only fail for garbage-in-garbage-out reasons, or GL_OOM. We don't give any other GL_OOM sources this same benefit. 4) This forces synchronization between WebGL content calls and the actual driver calls. (Shouldn't this be particularly bad in Chrome's arch?) On Mon, Jun 15, 2015 at 4:04 PM, Kenneth Russell wrote: > > Thanks for catching this oversight. Amending the spec to return a > boolean (and stating that the passed ArrayBuffer is unmodified in this > case) sounds good. > > -Ken > > > On Mon, Jun 15, 2015 at 3:34 PM, Brandon Jones wrote: > > Something I noticed today while working on Chrome's implementation of > this > > function. The implied underlying call to glMapBufferRange may return a > NULL > > pointer if the call fails for some reason. This provides a way to do > > efficient error handling. The WebGL function, however, passes in an > > ArrayBuffer to be populated and returns nothing, which means the only > way to > > communicate a failure is via getError. It's poor API design to require > > getError calls after an otherwise valid API call just to ensure it > worked. > > > > I propose we update the spec to have getBufferSubData return a GLboolean > or > > similar to indicate whether or not the mapping succeeded. That way > getError > > calls can be avoided unless we know the mapping failed. Any concerns with > > this approach? > > > > --Brandon > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 17 00:52:30 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 17 Jun 2015 09:52:30 +0200 Subject: [Public WebGL] Error catching with getBufferSubData In-Reply-To: References: Message-ID: Referencing https://www.khronos.org/opengles/sdk/docs/man3/ : *If an error occurs, glMapBufferRange returns a NULL pointer.* Looking at errors: - *GL_INVALID_VALUE is generated if either of offset or length is negative, or if offset + length is greater than the value of GL_BUFFER_SIZE. * - *GL_INVALID_VALUE is generated if access has any bits set other than those defined above. * - *GL_INVALID_OPERATION is generated for any of the following conditions: * - *The buffer is already in a mapped state.* - *Neither GL_MAP_READ_BIT or GL_MAP_WRITE_BIT is set.* - *GL_MAP_READ_BIT is set and any of GL_MAP_INVALIDATE_RANGE_BIT, GL_MAP_INVALIDATE_BUFFER_BIT, or GL_MAP_UNSYNCHRONIZED_BIT is set.* - *GL_MAP_FLUSH_EXPLICIT_BIT is set and GL_MAP_WRITE_BIT is not set.* - *GL_OUT_OF_MEMORY is generated if glMapBufferRange fails because memory for the mapping could not be obtained.* All of these errors indicate that your program is faulty. When using gl.mapBufferRange there are two use-cases. Either you are checking for errors, or you are not. 1. If you are checking for errors, you are doing so using gl.getError. This will reliably indicate an error in your invocation of gl.mapBufferRange without consulting a hypothetical return boolean. 2. If you are not checking for errors, you are not using gl.getError, and you will also not consult the hypothetical gl.mapBufferRange return boolean. Since neither usecase would rely as a best practice on the gl.mapBufferRange return value, I conclude that this return value would be superfluous and not necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 17 01:02:12 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 17 Jun 2015 10:02:12 +0200 Subject: [Public WebGL] Error catching with getBufferSubData In-Reply-To: References: Message-ID: On Wed, Jun 17, 2015 at 9:52 AM, Florian B?sch wrote: > > - *GL_OUT_OF_MEMORY is generated if glMapBufferRange fails because > memory for the mapping could not be obtained.* > > All of these errors indicate that your program is faulty. > That wasn't entirely correct, your program can be correct and you can still run into this error. A case could be made that code like this: if(!gl.mapBufferRange(...)){ gl.getError(); } Is a valid usecase of the boolean return value, because it only synchronizes (gl.getError()) if an error occured as opposed to: gl.mapBufferRange(...); gl.getError(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Wed Jun 17 10:07:27 2015 From: baj...@ (Brandon Jones) Date: Wed, 17 Jun 2015 17:07:27 +0000 Subject: [Public WebGL] Error catching with getBufferSubData In-Reply-To: References: Message-ID: I feel like the argument that my proposal diverges from glGetBufferSubData is a significant one, even if that function hasn't made it's way to OpenGL ES (and possibly never will, at this point.) The fact that it is an existing OpenGL function means we should stick to it's definition where reasonable. As such I'm dropping the proposal unless someone else on the list feels strongly about it. --Brandon On Wed, Jun 17, 2015 at 1:02 AM Florian B?sch wrote: > On Wed, Jun 17, 2015 at 9:52 AM, Florian B?sch wrote: > >> >> - *GL_OUT_OF_MEMORY is generated if glMapBufferRange fails because >> memory for the mapping could not be obtained.* >> >> All of these errors indicate that your program is faulty. >> > That wasn't entirely correct, your program can be correct and you can > still run into this error. > > A case could be made that code like this: > > if(!gl.mapBufferRange(...)){ > gl.getError(); > } > > > Is a valid usecase of the boolean return value, because it only > synchronizes (gl.getError()) if an error occured as opposed to: > > gl.mapBufferRange(...); > gl.getError(); > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 02:29:31 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 19 Jun 2015 11:29:31 +0200 Subject: [Public WebGL] IE extension tickets Message-ID: It has recently come to my attention that all IE feedback tickets pertaining to implement WebGL extensions where closed on the IE feedback site. Tickets affected that I know about: - https://connect.microsoft.com/IE/feedback/details/1116140/webgl-extension-webgl-compressed-texture-es3-may-be-implemented - https://connect.microsoft.com/IE/feedback/details/1114829/webgl-extension-ext-color-buffer-float-may-be-implemented - https://connect.microsoft.com/IE/feedback/details/1114887/webgl-extension-oes-fbo-render-mipmap-may-be-implemented Each instance of these demands that these issues are tracked as a feature suggestion on https://wpdev.uservoice.com/forums/257854-internet-explorer-platform I have some misgivings about shunting WebGL extension requests trough that procedure. At the very least I'd suggest to introduce a WebGL category so they can be properly filtered. Already present: - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6263719-webgl-shared-resources - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6679657-webgl-webgl-draw-buffers - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6517037-webgl-2-0 - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6509390-accessing-webgl-context-from-webworker - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6559203-shader-debug - https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/2543957-support-for-webgl New suggestions I entered for all extensions not currently implemented by IE that may be implemented. - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480731-implement-webgl-oes-texture-half-float - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480752-implement-webgl-extension-oes-texture-half-float-l - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480770-implement-webgl-extension-webgl-color-buffer-float - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480785-implement-webgl-extension-ext-color-buffer-half-fl - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480806-implement-webgl-2-extension-ext-color-buffer-float - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480815-implement-webgl-extension-webgl-compressed-texture - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480818-implement-webgl-extension-webgl-compressed-texture - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480836-implement-webgl-extension-webgl-compressed-texture - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480854-implement-webgl-extension-webgl-depth-texture - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480869-implement-webgl-extension-ext-srgb - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480884-implement-webgl-extension-ext-shader-texture-lod - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480887-implement-webgl-extension-oes-fbo-render-mipmap - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480923-implement-webgl-extension-ext-frag-depth - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480938-implement-webgl-extension-ext-blend-minmax - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480959-implement-webgl-extension-oes-vertex-array-object - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480983-implement-webgl-extension-webgl-lose-context - https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480995-implement-webgl-extension-ext-disjoint-timer-query You can see all of those here: https://wpdev.uservoice.com/users/82180798-florian-b%C3%B6sch -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Fri Jun 19 10:44:45 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 19 Jun 2015 17:44:45 +0000 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Thank you very much for your feedback, Florian. ?User voice? is the best place to put feature requests. Please keep them coming and have your friends vote. Connect is for specific bug reports. EXT_frag_depth and WEBGL_depth_texture are implemented in Microsoft Edge and will be part of the Windows 10 release. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Florian B?sch Sent: Friday, June 19, 2015 2:30 AM To: Frank Olivier; public webgl Subject: [Public WebGL] IE extension tickets It has recently come to my attention that all IE feedback tickets pertaining to implement WebGL extensions where closed on the IE feedback site. Tickets affected that I know about: * https://connect.microsoft.com/IE/feedback/details/1116140/webgl-extension-webgl-compressed-texture-es3-may-be-implemented * https://connect.microsoft.com/IE/feedback/details/1114829/webgl-extension-ext-color-buffer-float-may-be-implemented * https://connect.microsoft.com/IE/feedback/details/1114887/webgl-extension-oes-fbo-render-mipmap-may-be-implemented Each instance of these demands that these issues are tracked as a feature suggestion on https://wpdev.uservoice.com/forums/257854-internet-explorer-platform I have some misgivings about shunting WebGL extension requests trough that procedure. At the very least I'd suggest to introduce a WebGL category so they can be properly filtered. Already present: * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6263719-webgl-shared-resources * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6679657-webgl-webgl-draw-buffers * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6517037-webgl-2-0 * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6509390-accessing-webgl-context-from-webworker * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6559203-shader-debug * https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/2543957-support-for-webgl New suggestions I entered for all extensions not currently implemented by IE that may be implemented. * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480731-implement-webgl-oes-texture-half-float * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480752-implement-webgl-extension-oes-texture-half-float-l * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480770-implement-webgl-extension-webgl-color-buffer-float * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480785-implement-webgl-extension-ext-color-buffer-half-fl * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480806-implement-webgl-2-extension-ext-color-buffer-float * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480815-implement-webgl-extension-webgl-compressed-texture * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480818-implement-webgl-extension-webgl-compressed-texture * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480836-implement-webgl-extension-webgl-compressed-texture * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480854-implement-webgl-extension-webgl-depth-texture * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480869-implement-webgl-extension-ext-srgb * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480884-implement-webgl-extension-ext-shader-texture-lod * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480887-implement-webgl-extension-oes-fbo-render-mipmap * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480923-implement-webgl-extension-ext-frag-depth * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480938-implement-webgl-extension-ext-blend-minmax * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480959-implement-webgl-extension-oes-vertex-array-object * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480983-implement-webgl-extension-webgl-lose-context * https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/8480995-implement-webgl-extension-ext-disjoint-timer-query You can see all of those here: https://wpdev.uservoice.com/users/82180798-florian-b%C3%B6sch -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 10:49:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 19 Jun 2015 19:49:05 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 7:44 PM, Rafael Cintron < Rafael.Cintron...@> wrote: > EXT_frag_depth and WEBGL_depth_texture are implemented in Microsoft Edge > and will be part of the Windows 10 release. > Do you intend to implement EXT_frag_depth and WEBGL_depth_texture on IE and other windows as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Fri Jun 19 10:55:25 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 19 Jun 2015 17:55:25 +0000 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: At the moment, there are no plans to make them available for IE or other versions of Windows. From: Florian B?sch [mailto:pyalot...@] Sent: Friday, June 19, 2015 10:49 AM To: Rafael Cintron Cc: Frank Olivier; public webgl Subject: Re: [Public WebGL] IE extension tickets On Fri, Jun 19, 2015 at 7:44 PM, Rafael Cintron > wrote: EXT_frag_depth and WEBGL_depth_texture are implemented in Microsoft Edge and will be part of the Windows 10 release. Do you intend to implement EXT_frag_depth and WEBGL_depth_texture on IE and other windows as well? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 11:07:23 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 19 Jun 2015 20:07:23 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: I'm sure you'll agree that I can't consider a feature implemented till you managed to effectively retire the software you've EOLed for all intends and purposes. It's perhaps for the best that IE11 has never reached the market share that 6, 7, 8, 9 or 10 did, for it'll be quicker to retire (at least in theory). Although 8, 9 and 10 still hold more than 2% market share each with no sign of going the way of 6 or 7 anytime soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Fri Jun 19 11:41:44 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 19 Jun 2015 18:41:44 +0000 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Microsoft values the importance of getting everyone current with the latest version of the platform. It?s better for us as well as for you. With Windows 10, we?re going to make upgrading be as painless as possible for as many people as we can. However, there will be people who won?t upgrade for business reasons, or because their computer is too old or because they just don?t want to. We don?t have a magic wand that zaps away old browsers, unfortunately. ? In the meantime, we will continue to improve Microsoft Edge. From: Florian B?sch [mailto:pyalot...@] Sent: Friday, June 19, 2015 11:07 AM To: Rafael Cintron Cc: Frank Olivier; public webgl Subject: Re: [Public WebGL] IE extension tickets I'm sure you'll agree that I can't consider a feature implemented till you managed to effectively retire the software you've EOLed for all intends and purposes. It's perhaps for the best that IE11 has never reached the market share that 6, 7, 8, 9 or 10 did, for it'll be quicker to retire (at least in theory). Although 8, 9 and 10 still hold more than 2% market share each with no sign of going the way of 6 or 7 anytime soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 11:50:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 19 Jun 2015 20:50:05 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 8:41 PM, Rafael Cintron < Rafael.Cintron...@> wrote: > We don?t have a magic wand that zaps away old browsers, unfortunately. > I'd be remiss of me not to point out that Mozilla and Google do have their magic wands to zap away old browsers. Coupled with their willingness to ship their browser to whichever OS is around, I'm pretty sure that accounts for their sustained or growing market shares. I'd rather see a somewhat balanced ecosystem of browsers around, and in that habitat I see IE/Edge as an endangered species. I'd rather not see IE/Edges market share slip further (or Firefoxes for that matter). -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 12:54:46 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 19 Jun 2015 21:54:46 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: I should also perhaps point out this feedback here: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6509607-auto-update-older-ie-versions Auto Update Older IE Versions > Force older versions of Internet Explorer to automatically update. Which is the top-rated feedback on the Edge feedback site. And this didn't mean that updating "the latest supported version of Internet Explorer for that platform". That's an interpretation of update that's not shared by neither users nor developers. Update means you'll magicwand zap all those older versions with Edge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Jun 19 13:25:08 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 19 Jun 2015 13:25:08 -0700 Subject: [Public WebGL] Firefox's "Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info" discussion Message-ID: We're having the proposal feedback discussion over on dev-platform...@, if anyone has additional input. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Fri Jun 19 14:07:06 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Sat, 20 Jun 2015 00:07:06 +0300 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Sorry for asking if I've missed public knowledge here, but I can't recall having read about this: will Edge be available to Windows 8.1? or is it Windows 10 only? Upgrading from, say, Firefox 37 to 38 is easy and very transparent to the user. That is the magic wand. Requiring users to upgrade their OS in order to upgrade the browser is what makes the magic wand go away :( If users need to do that (no matter if the OS upgrade is free or not), then migration will be much slower. Since graphics and audio needs often go hand in hand, especially for games, I wonder, if Edge won't be available in Win8.1, will IE11 have Web Audio support? Or is development on new features for IE11 effectively frozen at this point of time? 2015-06-19 22:54 GMT+03:00 Florian B?sch : > I should also perhaps point out this feedback here: > https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6509607-auto-update-older-ie-versions > > Auto Update Older IE Versions >> Force older versions of Internet Explorer to automatically update. > > > Which is the top-rated feedback on the Edge feedback site. And this didn't > mean that updating "the latest supported version of Internet Explorer for > that platform". That's an interpretation of update that's not shared by > neither users nor developers. Update means you'll magicwand zap all those > older versions with Edge. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thu...@ Fri Jun 19 14:39:48 2015 From: thu...@ (Ben Adams) Date: Fri, 19 Jun 2015 22:39:48 +0100 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Paraphrasing wrongly I'm sure: http://blogs.msdn.com/b/ie/archive/2015/02/26/a-break-from-the-past-the-birth-of-microsoft-s-new-web-rendering-engine.aspx As detailed in Jacob Rossi?s article for Smashing Magazine , the new engine began as a fork of MSHTML.dll but has since diverged very quickly. By making this split, we were able to keep the major subsystem investments made over the last several years, while allowing us to remove document modes and other legacy IE behaviors from the new engine. On the other hand, *our legacy engine (MSHTML.dll) can remain largely unchanged (outside of security and other high priority fixes) to help guarantee legacy compatibility for our enterprise customers*. For users that *upgrade to Windows 10, the engine will be evergreen, meaning that it will be kept current* Though it also sounds like IE11's backwards comparability has and is being improved to help customers with apps that depend on IE5 - IE10 work better when using IE11 in Windows 10 and both IE11 and Edge ship with Windows 10 - though Edge is the default and IE11 is hidden away; was what I took away from the "Microsoft Edge and IE11 for IT Professionals" talk at the Microsoft Edge Web Summit 2015: https://channel9.msdn.com/Events/WebPlatformSummit/2015/Microsoft-Edge-and-IE11-for-IT-Professionals And consumers on Win7, Win8, Win8.1 get free upgrade to Win10. Don't have any special knowledge; or speak for MS; just what I've seen publicly - so I may understand it totally wrong... On 19 June 2015 at 22:07, Jukka Jyl?nki wrote: > Sorry for asking if I've missed public knowledge here, but I can't recall > having read about this: will Edge be available to Windows 8.1? or is it > Windows 10 only? > > Upgrading from, say, Firefox 37 to 38 is easy and very transparent to the > user. That is the magic wand. Requiring users to upgrade their OS in order > to upgrade the browser is what makes the magic wand go away :( If users > need to do that (no matter if the OS upgrade is free or not), then > migration will be much slower. > > Since graphics and audio needs often go hand in hand, especially for > games, I wonder, if Edge won't be available in Win8.1, will IE11 have Web > Audio support? Or is development on new features for IE11 effectively > frozen at this point of time? > > 2015-06-19 22:54 GMT+03:00 Florian B?sch : > >> I should also perhaps point out this feedback here: >> https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6509607-auto-update-older-ie-versions >> >> Auto Update Older IE Versions >>> Force older versions of Internet Explorer to automatically update. >> >> >> Which is the top-rated feedback on the Edge feedback site. And this >> didn't mean that updating "the latest supported version of Internet >> Explorer for that platform". That's an interpretation of update that's not >> shared by neither users nor developers. Update means you'll magicwand zap >> all those older versions with Edge. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 14:50:23 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 19 Jun 2015 23:50:23 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: I'm sure the free 10 upgrade helps, somewhat. However over 50% of users are still using Win7, 16% are using Win8.1, 10% are using WinXP and 3% are using Vista, and those are absolute numbers for desktops. Relative to windows users it'd be more. Operating systems tend not to be updated by users very often and tend to be clingy. Before Win7 users just didn't give up WinXP (certainly not for Vista) and it took until 3 years after the introduction of Win7 that XP wasn't the most used windows anymore. It just seems to me to be overly optimistic to expect OS upgrades (even if free) to solve all browser upgrade woes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thu...@ Fri Jun 19 14:59:45 2015 From: thu...@ (Ben Adams) Date: Fri, 19 Jun 2015 22:59:45 +0100 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Windows Vista was released 8 years ago? Are the Windows XP users likely to be able to run WebGL with any performance or at all? Windows 7 was 6 years ago; which is probably asks the same about Vista users. On 19 June 2015 at 22:50, Florian B?sch wrote: > I'm sure the free 10 upgrade helps, somewhat. However over 50% of users > are still using Win7, 16% are using Win8.1, 10% are using WinXP and 3% are > using Vista, and those are absolute numbers for desktops. Relative to > windows users it'd be more. > > Operating systems tend not to be updated by users very often and tend to > be clingy. Before Win7 users just didn't give up WinXP (certainly not for > Vista) and it took until 3 years after the introduction of Win7 that XP > wasn't the most used windows anymore. > > It just seems to me to be overly optimistic to expect OS upgrades (even if > free) to solve all browser upgrade woes. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jun 19 15:02:15 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 20 Jun 2015 00:02:15 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Point was to illustrate that OS'es are clingy. Win7 has steadfastly failed to buckle by both the introduction of Win8 and Win8.1. Win8 canibalized XP and Win8.1 canibalized XP and Win8, but they didn't make even a dent in Win7. On Fri, Jun 19, 2015 at 11:59 PM, Ben Adams wrote: > Windows Vista was released 8 years ago? Are the Windows XP users likely to > be able to run WebGL with any performance or at all? Windows 7 was 6 years > ago; which is probably asks the same about Vista users. > > > On 19 June 2015 at 22:50, Florian B?sch wrote: > >> I'm sure the free 10 upgrade helps, somewhat. However over 50% of users >> are still using Win7, 16% are using Win8.1, 10% are using WinXP and 3% are >> using Vista, and those are absolute numbers for desktops. Relative to >> windows users it'd be more. >> >> Operating systems tend not to be updated by users very often and tend to >> be clingy. Before Win7 users just didn't give up WinXP (certainly not for >> Vista) and it took until 3 years after the introduction of Win7 that XP >> wasn't the most used windows anymore. >> >> It just seems to me to be overly optimistic to expect OS upgrades (even >> if free) to solve all browser upgrade woes. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thu...@ Fri Jun 19 15:17:03 2015 From: thu...@ (Ben Adams) Date: Fri, 19 Jun 2015 23:17:03 +0100 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: That may also have something to do with some people's fundamental objections to Win8 and its redesign; and their insistence to install Win7 on top of Win8 rather than anything else. Hopefully Windows 10 will go better. Its a common problem with OS tied browsers; Apple has it with Safari (though they are better at getting people to upgrade); the Andorid browser and IE. Edge appears to be decoupled from OS updates (post Win10); like Chrome now is on Android (via Store) so hopefully things should be better moving forward. On 19 June 2015 at 23:02, Florian B?sch wrote: > Point was to illustrate that OS'es are clingy. Win7 has steadfastly failed > to buckle by both the introduction of Win8 and Win8.1. Win8 canibalized XP > and Win8.1 canibalized XP and Win8, but they didn't make even a dent in > Win7. > > On Fri, Jun 19, 2015 at 11:59 PM, Ben Adams > wrote: > >> Windows Vista was released 8 years ago? Are the Windows XP users likely >> to be able to run WebGL with any performance or at all? Windows 7 was 6 >> years ago; which is probably asks the same about Vista users. >> >> >> On 19 June 2015 at 22:50, Florian B?sch wrote: >> >>> I'm sure the free 10 upgrade helps, somewhat. However over 50% of users >>> are still using Win7, 16% are using Win8.1, 10% are using WinXP and 3% are >>> using Vista, and those are absolute numbers for desktops. Relative to >>> windows users it'd be more. >>> >>> Operating systems tend not to be updated by users very often and tend to >>> be clingy. Before Win7 users just didn't give up WinXP (certainly not for >>> Vista) and it took until 3 years after the introduction of Win7 that XP >>> wasn't the most used windows anymore. >>> >>> It just seems to me to be overly optimistic to expect OS upgrades (even >>> if free) to solve all browser upgrade woes. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Fri Jun 19 16:50:59 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 19 Jun 2015 23:50:59 +0000 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: As for updating older versions of IE, we?ve been doing exactly that over the years with IE11 on Win7 through Windows Update. I have a Win7 machine at home. One day, I discovered IE11 had been installed as part the normal course of doing updates. I never went to a download page to get it. Much of IE?s functionality is closely tied to APIs the operating system directly provides, more so than other browsers. We rely folks in other parts of windows to provide us with image decoders, video decoders, audio decoders, touch APIs, networking features, text rendering, an animation engine, and all of the rendering bells and whistles needed to do SVG: lines, curves, blending, blurs, convolutions, etc. The upside is that since they come with the OS, other applications can leverage them the same as the browser does. If the web can do it, your application can do it natively. The downside for the browser is there?s a significant cost that comes with supporting 6, 10, 15 year old operating systems. Features have to either be done a different, equivalent manner or not light up at all. The latter case is especially bad for web developers. In the recent past, we?ve chosen to support the current Windows version as well as the N-1 version. IE9 came out during the Win7 timeframe so we supported Win7 and Vista. IE10 supported Win8 and Win7. IE11 supported Win8.1, and Win 7. Edge will be the first time we?ve only supported the latest and greatest operating system. It?s certainly a gamble and we?re betting Win10 will be popular in the ways previous popular versions of Windows have been. --Rafael From: Ben Adams [mailto:thundercat...@] Sent: Friday, June 19, 2015 3:17 PM To: Florian B?sch Cc: Jukka Jyl?nki; Rafael Cintron; Frank Olivier; public webgl Subject: Re: [Public WebGL] IE extension tickets That may also have something to do with some people's fundamental objections to Win8 and its redesign; and their insistence to install Win7 on top of Win8 rather than anything else. Hopefully Windows 10 will go better. Its a common problem with OS tied browsers; Apple has it with Safari (though they are better at getting people to upgrade); the Andorid browser and IE. Edge appears to be decoupled from OS updates (post Win10); like Chrome now is on Android (via Store) so hopefully things should be better moving forward. On 19 June 2015 at 23:02, Florian B?sch > wrote: Point was to illustrate that OS'es are clingy. Win7 has steadfastly failed to buckle by both the introduction of Win8 and Win8.1. Win8 canibalized XP and Win8.1 canibalized XP and Win8, but they didn't make even a dent in Win7. On Fri, Jun 19, 2015 at 11:59 PM, Ben Adams > wrote: Windows Vista was released 8 years ago? Are the Windows XP users likely to be able to run WebGL with any performance or at all? Windows 7 was 6 years ago; which is probably asks the same about Vista users. On 19 June 2015 at 22:50, Florian B?sch > wrote: I'm sure the free 10 upgrade helps, somewhat. However over 50% of users are still using Win7, 16% are using Win8.1, 10% are using WinXP and 3% are using Vista, and those are absolute numbers for desktops. Relative to windows users it'd be more. Operating systems tend not to be updated by users very often and tend to be clingy. Before Win7 users just didn't give up WinXP (certainly not for Vista) and it took until 3 years after the introduction of Win7 that XP wasn't the most used windows anymore. It just seems to me to be overly optimistic to expect OS upgrades (even if free) to solve all browser upgrade woes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Sat Jun 20 03:35:21 2015 From: kos...@ (David Sheets) Date: Sat, 20 Jun 2015 11:35:21 +0100 Subject: [Public WebGL] Firefox's "Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info" discussion In-Reply-To: References: Message-ID: On Fri, Jun 19, 2015 at 9:25 PM, Jeff Gilbert wrote: > We're having the proposal feedback discussion over on > dev-platform...@, if anyone has additional input. Archive at . ----------------------------------------------------------- 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 flo...@ Sat Jun 20 06:58:57 2015 From: flo...@ (Floh) Date: Sat, 20 Jun 2015 15:58:57 +0200 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: At least in one important market (== China) WindowsXP is still the majority of PC installs, is very stable and from time to time even growing (see worldwide Unity Webplayer stats here where XP hovers around 40%: http://stats.unity3d.com/web/). If MS allows free upgrades of these XP installs to Windows 10 that may finally change slowly but in my opinion it is important to not forget about Windows XP just yet (even though MS itself and some (all?) GPU vendors don't support it any longer). Cheers, -Andre. On Sat, Jun 20, 2015 at 12:17 AM, Ben Adams wrote: > That may also have something to do with some people's fundamental objections > to Win8 and its redesign; and their insistence to install Win7 on top of > Win8 rather than anything else. Hopefully Windows 10 will go better. > > Its a common problem with OS tied browsers; Apple has it with Safari (though > they are better at getting people to upgrade); the Andorid browser and IE. > > Edge appears to be decoupled from OS updates (post Win10); like Chrome now > is on Android (via Store) so hopefully things should be better moving > forward. > > > On 19 June 2015 at 23:02, Florian B?sch wrote: >> >> Point was to illustrate that OS'es are clingy. Win7 has steadfastly failed >> to buckle by both the introduction of Win8 and Win8.1. Win8 canibalized XP >> and Win8.1 canibalized XP and Win8, but they didn't make even a dent in >> Win7. >> >> On Fri, Jun 19, 2015 at 11:59 PM, Ben Adams >> wrote: >>> >>> Windows Vista was released 8 years ago? Are the Windows XP users likely >>> to be able to run WebGL with any performance or at all? Windows 7 was 6 >>> years ago; which is probably asks the same about Vista users. >>> >>> >>> On 19 June 2015 at 22:50, Florian B?sch wrote: >>>> >>>> I'm sure the free 10 upgrade helps, somewhat. However over 50% of users >>>> are still using Win7, 16% are using Win8.1, 10% are using WinXP and 3% are >>>> using Vista, and those are absolute numbers for desktops. Relative to >>>> windows users it'd be more. >>>> >>>> Operating systems tend not to be updated by users very often and tend to >>>> be clingy. Before Win7 users just didn't give up WinXP (certainly not for >>>> Vista) and it took until 3 years after the introduction of Win7 that XP >>>> wasn't the most used windows anymore. >>>> >>>> It just seems to me to be overly optimistic to expect OS upgrades (even >>>> if free) to solve all browser upgrade woes. >>> >>> >> > ----------------------------------------------------------- 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 thu...@ Sat Jun 20 09:10:06 2015 From: thu...@ (Ben Adams) Date: Sat, 20 Jun 2015 17:10:06 +0100 Subject: [Public WebGL] IE extension tickets In-Reply-To: References: Message-ID: Chrome ends updates for Windows XP at the end of this year: http://chrome.blogspot.se/2015/04/providing-updates-for-chrome-for-xp.html so at the point is only Firefox that supports it. On 20 June 2015 at 14:58, Floh wrote: > At least in one important market (== China) WindowsXP is still the > majority of PC installs, is very stable and from time to time even > growing (see worldwide Unity Webplayer stats here where XP hovers > around 40%: http://stats.unity3d.com/web/). > > If MS allows free upgrades of these XP installs to Windows 10 that may > finally change slowly but in my opinion it is important to not forget > about Windows XP just yet (even though MS itself and some (all?) GPU > vendors don't support it any longer). > > Cheers, > -Andre. > > On Sat, Jun 20, 2015 at 12:17 AM, Ben Adams > wrote: > > That may also have something to do with some people's fundamental > objections > > to Win8 and its redesign; and their insistence to install Win7 on top of > > Win8 rather than anything else. Hopefully Windows 10 will go better. > > > > Its a common problem with OS tied browsers; Apple has it with Safari > (though > > they are better at getting people to upgrade); the Andorid browser and > IE. > > > > Edge appears to be decoupled from OS updates (post Win10); like Chrome > now > > is on Android (via Store) so hopefully things should be better moving > > forward. > > > > > > On 19 June 2015 at 23:02, Florian B?sch wrote: > >> > >> Point was to illustrate that OS'es are clingy. Win7 has steadfastly > failed > >> to buckle by both the introduction of Win8 and Win8.1. Win8 canibalized > XP > >> and Win8.1 canibalized XP and Win8, but they didn't make even a dent in > >> Win7. > >> > >> On Fri, Jun 19, 2015 at 11:59 PM, Ben Adams > >> wrote: > >>> > >>> Windows Vista was released 8 years ago? Are the Windows XP users likely > >>> to be able to run WebGL with any performance or at all? Windows 7 was 6 > >>> years ago; which is probably asks the same about Vista users. > >>> > >>> > >>> On 19 June 2015 at 22:50, Florian B?sch wrote: > >>>> > >>>> I'm sure the free 10 upgrade helps, somewhat. However over 50% of > users > >>>> are still using Win7, 16% are using Win8.1, 10% are using WinXP and > 3% are > >>>> using Vista, and those are absolute numbers for desktops. Relative to > >>>> windows users it'd be more. > >>>> > >>>> Operating systems tend not to be updated by users very often and tend > to > >>>> be clingy. Before Win7 users just didn't give up WinXP (certainly not > for > >>>> Vista) and it took until 3 years after the introduction of Win7 that > XP > >>>> wasn't the most used windows anymore. > >>>> > >>>> It just seems to me to be overly optimistic to expect OS upgrades > (even > >>>> if free) to solve all browser upgrade woes. > >>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 24 07:30:22 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 24 Jun 2015 16:30:22 +0200 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> Message-ID: Rendering to multiple canvases from one WebGL context is still an unsolved problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 30 02:51:56 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 30 Jun 2015 11:51:56 +0200 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> Message-ID: I believe that an excellent opportunity to address this issue conclusively is being wasted by not incorporating appropriate APIs into WebGL2. On Wed, Jun 24, 2015 at 4:30 PM, Florian B?sch wrote: > Rendering to multiple canvases from one WebGL context is still an unsolved > problem. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Jun 30 11:26:53 2015 From: din...@ (Dean Jackson) Date: Wed, 1 Jul 2015 04:26:53 +1000 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> Message-ID: <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> I agree this is an important use case, and that we should address it now. The most obvious example would be a dashboard application of some sort with lots of little widgets - having a separate context for each widget is unreasonable and wasteful. Dean > On 30 Jun 2015, at 7:51 PM, Florian B?sch wrote: > > I believe that an excellent opportunity to address this issue conclusively is being wasted by not incorporating appropriate APIs into WebGL2. > > On Wed, Jun 24, 2015 at 4:30 PM, Florian B?sch > wrote: > Rendering to multiple canvases from one WebGL context is still an unsolved problem. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Jun 30 11:32:34 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 30 Jun 2015 11:32:34 -0700 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> Message-ID: I also agree that this is an important use case and that the upgrade to WebGL 2.0 is an excellent opportunity to address it. Apologies for not being more vocal on the topic, but am pretty swamped. The API proposal at https://wiki.whatwg.org/wiki/OffscreenCanvas should hopefully address this use case and a couple of others, and isn't tied directly to the WebGL API. Feedback on the proposal would be appreciated. I have some outstanding work to do on it including putting together example code. Firefox is prototyping some of the API in https://bugzilla.mozilla.org/show_bug.cgi?id=709490 , and the Chrome team intends to start a prototype soon. On Tue, Jun 30, 2015 at 11:26 AM, Dean Jackson wrote: > I agree this is an important use case, and that we should address it now. > The most obvious example would be a dashboard application of some sort with > lots of little widgets - having a separate context for each widget is > unreasonable and wasteful. > > Dean > > On 30 Jun 2015, at 7:51 PM, Florian B?sch wrote: > > I believe that an excellent opportunity to address this issue conclusively > is being wasted by not incorporating appropriate APIs into WebGL2. > > On Wed, Jun 24, 2015 at 4:30 PM, Florian B?sch wrote: >> >> Rendering to multiple canvases from one WebGL context is still an unsolved >> problem. > > > ----------------------------------------------------------- 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...@ Tue Jun 30 12:39:37 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 30 Jun 2015 21:39:37 +0200 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> Message-ID: A few example uses of the the proposed API would help. Far as I understand this proposal an offscreen canvas is used to obtain a context and then you can transfer whatever is in the offscreen canvas to another canvas (either all on the main thread or from a worker). I'm not quite clear how it should work to define several backing stores with different settings for antialias, stencil, depth and size that serve as the target to render into. It seems to me that you're pretty much frozen into whatever you setup the offscreen canvas to be. On Tue, Jun 30, 2015 at 8:32 PM, Kenneth Russell wrote: > I also agree that this is an important use case and that the upgrade > to WebGL 2.0 is an excellent opportunity to address it. Apologies for > not being more vocal on the topic, but am pretty swamped. The API > proposal at https://wiki.whatwg.org/wiki/OffscreenCanvas should > hopefully address this use case and a couple of others, and isn't tied > directly to the WebGL API. Feedback on the proposal would be > appreciated. I have some outstanding work to do on it including > putting together example code. Firefox is prototyping some of the API > in https://bugzilla.mozilla.org/show_bug.cgi?id=709490 , and the > Chrome team intends to start a prototype soon. > > > On Tue, Jun 30, 2015 at 11:26 AM, Dean Jackson wrote: > > I agree this is an important use case, and that we should address it now. > > The most obvious example would be a dashboard application of some sort > with > > lots of little widgets - having a separate context for each widget is > > unreasonable and wasteful. > > > > Dean > > > > On 30 Jun 2015, at 7:51 PM, Florian B?sch wrote: > > > > I believe that an excellent opportunity to address this issue > conclusively > > is being wasted by not incorporating appropriate APIs into WebGL2. > > > > On Wed, Jun 24, 2015 at 4:30 PM, Florian B?sch wrote: > >> > >> Rendering to multiple canvases from one WebGL context is still an > unsolved > >> problem. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Jun 30 12:41:35 2015 From: din...@ (Dean Jackson) Date: Wed, 1 Jul 2015 05:41:35 +1000 Subject: [Public WebGL] using the same context with multiple canvases In-Reply-To: References: <1323262007.46206883.1359598185356.JavaMail.root@mozilla.com> <5114B8F1.9040706@jetbrains.com> <96CD2494-528E-41F1-BABC-8874E5C28609@apple.com> Message-ID: <19857AD9-000A-40CF-807C-526BCB978DDC@apple.com> [culling the CC list] > On 1 Jul 2015, at 5:39 AM, Florian B?sch wrote: > > A few example uses of the the proposed API would help. Far as I understand this proposal an offscreen canvas is used to obtain a context and then you can transfer whatever is in the offscreen canvas to another canvas (either all on the main thread or from a worker). > > I'm not quite clear how it should work to define several backing stores with different settings for antialias, stencil, depth and size that serve as the target to render into. It seems to me that you're pretty much frozen into whatever you setup the offscreen canvas to be. Yeah, I was trying to work out how it would look actually using this API to draw into, say, 10 canvases in the main page. Examples would be great. I'd suggest a one to many, and a worker example. Dean > > > > On Tue, Jun 30, 2015 at 8:32 PM, Kenneth Russell > wrote: > I also agree that this is an important use case and that the upgrade > to WebGL 2.0 is an excellent opportunity to address it. Apologies for > not being more vocal on the topic, but am pretty swamped. The API > proposal at https://wiki.whatwg.org/wiki/OffscreenCanvas should > hopefully address this use case and a couple of others, and isn't tied > directly to the WebGL API. Feedback on the proposal would be > appreciated. I have some outstanding work to do on it including > putting together example code. Firefox is prototyping some of the API > in https://bugzilla.mozilla.org/show_bug.cgi?id=709490 , and the > Chrome team intends to start a prototype soon. > > > On Tue, Jun 30, 2015 at 11:26 AM, Dean Jackson > wrote: > > I agree this is an important use case, and that we should address it now. > > The most obvious example would be a dashboard application of some sort with > > lots of little widgets - having a separate context for each widget is > > unreasonable and wasteful. > > > > Dean > > > > On 30 Jun 2015, at 7:51 PM, Florian B?sch > wrote: > > > > I believe that an excellent opportunity to address this issue conclusively > > is being wasted by not incorporating appropriate APIs into WebGL2. > > > > On Wed, Jun 24, 2015 at 4:30 PM, Florian B?sch > wrote: > >> > >> Rendering to multiple canvases from one WebGL context is still an unsolved > >> problem. > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: