From kbr...@ Mon Nov 2 17:03:04 2015 From: kbr...@ (Kenneth Russell) Date: Tue, 3 Nov 2015 10:03:04 +0900 Subject: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior In-Reply-To: References: Message-ID: Thanks for proposing this and sorry for the delay reviewing it. This change sounds good to me. It's hard to imagine that applications are relying on the behavior of returning zero for out-of-bounds pixels during reads. Changing this for both WebGL 1.0 and 2.0 at the same time sounds fine to me; no reason to make the specs diverge further. Any other feedback from implementers? There aren't that many conformance tests for this behavior, so it should be straightforward to update the spec and those tests, and remove the invalidated tests from earlier versions of the conformance suite. Assuming no objections, would you be willing to assemble a pull request for both the spec and conformance test changes? Thanks, -Ken On Fri, Oct 30, 2015 at 6:03 AM, Jeff Gilbert wrote: > > We standardized this to read zeros in WebGL 1. However, this is > trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore > options. > > I propose that we change this (at least for WebGL 2) to "Out-of-bounds > pixels are not written to the destination during reads from a > framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the > destination buffer unchanged. Partially-out-of-bounds reads will only > write in-bounds pixels to the destination buffer." > > This should be at easy or easier to implement, and be much more > performant, since implementations can just restrict the size of their > read and draw rects for these operations. > > I would really rather make out-of-bounds reads of this sort an > INVALID_OPERATION, but a change to an error is more likely to be > breaking in terms of existing content. While it's also a breaking > change from OpenGL, I don't believe it is a porting concern, since > porting can be fixed by changing its behavior to match what I outline > above at the Emscripten (or other) level, though. > > ----------------------------------------------------------- > 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 Raf...@ Mon Nov 2 18:08:02 2015 From: Raf...@ (Rafael Cintron) Date: Tue, 3 Nov 2015 02:08:02 +0000 Subject: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior In-Reply-To: References: Message-ID: I am good with this. I wish we had done it sooner as it would have saved me from writing a bunch of (now) unnecessary code. From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell Sent: Monday, November 2, 2015 5:03 PM To: Jeff Gilbert Cc: webgl, public Subject: Re: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior Thanks for proposing this and sorry for the delay reviewing it. This change sounds good to me. It's hard to imagine that applications are relying on the behavior of returning zero for out-of-bounds pixels during reads. Changing this for both WebGL 1.0 and 2.0 at the same time sounds fine to me; no reason to make the specs diverge further. Any other feedback from implementers? There aren't that many conformance tests for this behavior, so it should be straightforward to update the spec and those tests, and remove the invalidated tests from earlier versions of the conformance suite. Assuming no objections, would you be willing to assemble a pull request for both the spec and conformance test changes? Thanks, -Ken On Fri, Oct 30, 2015 at 6:03 AM, Jeff Gilbert > wrote: We standardized this to read zeros in WebGL 1. However, this is trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore options. I propose that we change this (at least for WebGL 2) to "Out-of-bounds pixels are not written to the destination during reads from a framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the destination buffer unchanged. Partially-out-of-bounds reads will only write in-bounds pixels to the destination buffer." This should be at easy or easier to implement, and be much more performant, since implementations can just restrict the size of their read and draw rects for these operations. I would really rather make out-of-bounds reads of this sort an INVALID_OPERATION, but a change to an error is more likely to be breaking in terms of existing content. While it's also a breaking change from OpenGL, I don't believe it is a porting concern, since porting can be fixed by changing its behavior to match what I outline above at the Emscripten (or other) level, though. ----------------------------------------------------------- You are currently subscribed to public_webgl...@. To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Nov 2 21:34:56 2015 From: jgi...@ (Jeff Gilbert) Date: Mon, 2 Nov 2015 21:34:56 -0800 Subject: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior In-Reply-To: References: Message-ID: Same here, unfortunately. I do enjoy deleting code though. :) I can do the PR for this. On Mon, Nov 2, 2015 at 6:08 PM, Rafael Cintron wrote: > I am good with this. I wish we had done it sooner as it would have saved me > from writing a bunch of (now) unnecessary code. > > > > From: owners-public_webgl...@ > [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell > Sent: Monday, November 2, 2015 5:03 PM > To: Jeff Gilbert > Cc: webgl, public > Subject: Re: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* > behavior > > > > Thanks for proposing this and sorry for the delay reviewing it. > > > > This change sounds good to me. It's hard to imagine that applications are > relying on the behavior of returning zero for out-of-bounds pixels during > reads. Changing this for both WebGL 1.0 and 2.0 at the same time sounds fine > to me; no reason to make the specs diverge further. > > > > Any other feedback from implementers? There aren't that many conformance > tests for this behavior, so it should be straightforward to update the spec > and those tests, and remove the invalidated tests from earlier versions of > the conformance suite. > > > > Assuming no objections, would you be willing to assemble a pull request for > both the spec and conformance test changes? > > > > Thanks, > > > > -Ken > > > > > > On Fri, Oct 30, 2015 at 6:03 AM, Jeff Gilbert wrote: > > > We standardized this to read zeros in WebGL 1. However, this is > trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore > options. > > I propose that we change this (at least for WebGL 2) to "Out-of-bounds > pixels are not written to the destination during reads from a > framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the > destination buffer unchanged. Partially-out-of-bounds reads will only > write in-bounds pixels to the destination buffer." > > This should be at easy or easier to implement, and be much more > performant, since implementations can just restrict the size of their > read and draw rects for these operations. > > I would really rather make out-of-bounds reads of this sort an > INVALID_OPERATION, but a change to an error is more likely to be > breaking in terms of existing content. While it's also a breaking > change from OpenGL, I don't believe it is a porting concern, since > porting can be fixed by changing its behavior to match what I outline > above at the Emscripten (or other) level, though. > > ----------------------------------------------------------- > 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 Nov 3 15:17:16 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 3 Nov 2015 15:17:16 -0800 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 Message-ID: Unpack gets a lot trickier in WebGL 2 with the addition of settings for unpacking a subrect from a buffer, and there are a ton of new formats as well. FLIP_Y and PREMULTIPLY_ALPHA for ArrayBufferViews do not provide new functionality to users, since they can (and should) be marshaling their data into the format they actually want before passing it to us. They should not ask us to do costly transformations on their data before actually doing the upload. These functionalities can be handled completely with existing JS, and could even be retrofitted onto the WebGL prototype via monkey-patching. It's also not clear exactly how FLIP_Y interacts with the subrect selection UNPACK_ options, which would need to be speced, and will likely be confusing for users regardless. Further, compressedTex(Sub)Image doesn't and won't support these, so users are already forced to have their orientation and alpha-premultiplied status pre-marshaled when using these APIs. Lastly, these are slow paths, and as such are performance foot-guns, even if we can (and do) warn when users use this functionality. WebGL 2 gives us the opportunity to not-quite-maintain backwards compatibility, and I believe we should leverage this here. ----------------------------------------------------------- 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 Nov 3 22:36:45 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 4 Nov 2015 07:36:45 +0100 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: Message-ID: If you take a WebGL1 application and run it in WebGL2, will it break because of that? On Wed, Nov 4, 2015 at 12:17 AM, Jeff Gilbert wrote: > > Unpack gets a lot trickier in WebGL 2 with the addition of settings > for unpacking a subrect from a buffer, and there are a ton of new > formats as well. > > FLIP_Y and PREMULTIPLY_ALPHA for ArrayBufferViews do not provide new > functionality to users, since they can (and should) be marshaling > their data into the format they actually want before passing it to us. > They should not ask us to do costly transformations on their data > before actually doing the upload. These functionalities can be handled > completely with existing JS, and could even be retrofitted onto the > WebGL prototype via monkey-patching. > > It's also not clear exactly how FLIP_Y interacts with the subrect > selection UNPACK_ options, which would need to be speced, and will > likely be confusing for users regardless. > > Further, compressedTex(Sub)Image doesn't and won't support these, so > users are already forced to have their orientation and > alpha-premultiplied status pre-marshaled when using these APIs. > > Lastly, these are slow paths, and as such are performance foot-guns, > even if we can (and do) warn when users use this functionality. > > WebGL 2 gives us the opportunity to not-quite-maintain backwards > compatibility, and I believe we should leverage this here. > > ----------------------------------------------------------- > 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 ash...@ Wed Nov 4 10:11:29 2015 From: ash...@ (Ashley Gullen) Date: Wed, 4 Nov 2015 18:11:29 +0000 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: Message-ID: AFAIK all other JS APIs deal with unpremultipied image data, for example canvas2d's getImageData() returns an ImageData with an ArrayBuffer based on unpremultiplied data. It is convenient for developers if this type of data can be passed directly to WebGL simply by specifying a flag. Additionally given this fact I would anticipate it is used a lot and this change would break a lot of existing content. Our own WebGL 2D game engine relies on PREMULTIPLY_ALPHA for this reason, and I suspect many others do too. A bigger problem is PREMULTIPLY_ALPHA is also necessary in some cases when passing a HTMLImageElement. Converting HTMLImageElement to an ImageData for premultiplication, with current JS APIs, often forces a synchronous image decode on the main thread, responsible for 100ms+ jank and unable to use multiple CPU cores to increase throughput. Async image encoding/decoding is currently a weak point on the web platform, and I've drafted a spec to mitigate this, which so far I don't believe has any implementation work going on: http://wicg.github.io/img-conversion/ Forcing the marshaling to happen in JS code could exacerbate this weakness and significantly increase loading times and loading jank, so it could actually significantly degrade the performance situation. I'm also not sure JS code can reach the same level of performance as the browser's native code in premultiplying large amounts of data. This is the kind of thing direct memory access, SIMD and parallelisation can presumably help optimise (which JS/WebAssembly is gradually approaching, but not there yet). I would suggest maintaining the options for backwards compatibility and performance reasons, but perhaps specifying that they are only applied for the cases they are currently applied in WebGL 1, and none of the new cases that apply with WebGL 2 if the prove particularly difficult to implement. I don't think the functionality should be removed until it is both plausible to deploy a WebAssembly-compiled library that can do the same work at close to the same performance, and when JS APIs to asynchronously decode images are available. Otherwise loading a large WebGL app will be a slow and janky hell. On 4 November 2015 at 06:36, Florian B?sch wrote: > If you take a WebGL1 application and run it in WebGL2, will it break > because of that? > > On Wed, Nov 4, 2015 at 12:17 AM, Jeff Gilbert > wrote: > >> >> Unpack gets a lot trickier in WebGL 2 with the addition of settings >> for unpacking a subrect from a buffer, and there are a ton of new >> formats as well. >> >> FLIP_Y and PREMULTIPLY_ALPHA for ArrayBufferViews do not provide new >> functionality to users, since they can (and should) be marshaling >> their data into the format they actually want before passing it to us. >> They should not ask us to do costly transformations on their data >> before actually doing the upload. These functionalities can be handled >> completely with existing JS, and could even be retrofitted onto the >> WebGL prototype via monkey-patching. >> >> It's also not clear exactly how FLIP_Y interacts with the subrect >> selection UNPACK_ options, which would need to be speced, and will >> likely be confusing for users regardless. >> >> Further, compressedTex(Sub)Image doesn't and won't support these, so >> users are already forced to have their orientation and >> alpha-premultiplied status pre-marshaled when using these APIs. >> >> Lastly, these are slow paths, and as such are performance foot-guns, >> even if we can (and do) warn when users use this functionality. >> >> WebGL 2 gives us the opportunity to not-quite-maintain backwards >> compatibility, and I believe we should leverage this here. >> >> ----------------------------------------------------------- >> 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 emm...@ Thu Nov 5 05:50:25 2015 From: emm...@ (Helmut Emmelmann) Date: Thu, 05 Nov 2015 14:50:25 +0100 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: Message-ID: <563B5EA1.60307@taccgl.org> Also the taccgl.org library relies on the PREMULTIPLY_ALPHA option to animate certain HTML elements by drawing them on a 2D canvas and using that as parameter for texImage2D with the UNPACK_PREMULTIPLY_ALPHA option. > On Wed, Nov 4, 2015 at 12:17 AM, Jeff Gilbert jgilbert...@ > > wrote: > FLIP_Y and PREMULTIPLY_ALPHA for ArrayBufferViews do not provide new > functionality to users, since ... I am not sure if you just refer to the ArrayBufferViews versions of tex(Sub)Image2D or to the canvas and image versions as well. If its only the ArrayBufferViews versions it would not affect taccgl but still Ashley Gullen's first argument about canvas2d's getImageData() remains. > Lastly, these are slow paths, and as such are performance foot-guns, > even if we can (and do) warn when users use this functionality. On the other hand performance of texImage2D is very important, since it sometimes on slow devices and a large canvas takes longer than a frame and so causes dropped frames. Helmut Emmelmann -- ------------------------------------------------------------------------- H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim Germany | Ph:+49 621-795141 | Fax: +49 621-795161 | mailto:info...@ Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 Handelsregister: HRB 7273 | Amtsgericht Mannheim http://www.h-e-i.de | http://www.taccgl.org ------------------------------------------------------------------------- ----------------------------------------------------------- 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 ash...@ Thu Nov 5 07:18:26 2015 From: ash...@ (Ashley Gullen) Date: Thu, 5 Nov 2015 15:18:26 +0000 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: <563B5EA1.60307@taccgl.org> References: <563B5EA1.60307@taccgl.org> Message-ID: On 5 November 2015 at 13:50, Helmut Emmelmann wrote: > > > Lastly, these are slow paths, and as such are performance foot-guns, > > even if we can (and do) warn when users use this functionality. > On the other hand performance of texImage2D is very important, > since it sometimes on slow devices and a large canvas takes longer than a > frame and so causes dropped frames. This can be mitigated by uploading in chunks with texSubImage2D, possibly scheduled with something like requestIdleCallback. This only spreads out the call across frames, and doesn't really make it async (which would be great to have). I'm not sure if this impacts the question of supporting these unpack options though, it sounds like it's harder for implementers to support the sub-rectangle cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Thu Nov 5 08:45:24 2015 From: oet...@ (Olli Etuaho) Date: Thu, 5 Nov 2015 16:45:24 +0000 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: <563B5EA1.60307@taccgl.org>, Message-ID: <1446741924166.34666@nvidia.com> What's the exact use case for uploading textures from ImageData? Is the idea that the image needs to go through some changes, like color adjustments in JS before being uploaded to WebGL? Otherwise it seems simpler to just use the entry points that upload images directly, which would still have the WebGL conversion flags in Jeff's proposal. Maybe this use case should rather be solved by adding flags to getImageData() that would make it return premultiplied (or possibly flipped) data, as that would also have the benefit of avoiding the possible premultiplied -> non-premultiplied conversion when getting image data from canvas. It would still be possible to do changes to the image data in JS, and then upload to WebGL. Or do you see some issue with this alternative? -Olli ________________________________ From: owners-public_webgl...@ on behalf of Ashley Gullen Sent: Thursday, November 5, 2015 5:18 PM To: Helmut Emmelmann Cc: public_webgl...@ Subject: Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 On 5 November 2015 at 13:50, Helmut Emmelmann > wrote: > Lastly, these are slow paths, and as such are performance foot-guns, > even if we can (and do) warn when users use this functionality. On the other hand performance of texImage2D is very important, since it sometimes on slow devices and a large canvas takes longer than a frame and so causes dropped frames. This can be mitigated by uploading in chunks with texSubImage2D, possibly scheduled with something like requestIdleCallback. This only spreads out the call across frames, and doesn't really make it async (which would be great to have). I'm not sure if this impacts the question of supporting these unpack options though, it sounds like it's harder for implementers to support the sub-rectangle cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Fri Nov 6 05:18:50 2015 From: ash...@ (Ashley Gullen) Date: Fri, 6 Nov 2015 13:18:50 +0000 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: <1446741924166.34666@nvidia.com> References: <563B5EA1.60307@taccgl.org> <1446741924166.34666@nvidia.com> Message-ID: Yes, the use case is for JS to do pixel-manipulation operations before passing to WebGL. For example in texture atlases to prevent color/transparency bleed-in from outside the image area, it's useful to repeat the outer border of pixels just outside the image. Canvas is unsuitable for per-pixel operations like that, especially if the browser tries to GPU-accelerate the context. So in that case JS would obtain an ImageData, write to some entries, then pass it (in whole or in chunks) to tex{Sub}Image2D. Modifying canvas2d's getImageData() is no help, because it is the worst way of getting ImageData (often does synchronous main-thread image decoding) and needs to be replaced. Perhaps there could be a method like ImageData.premultiply()? But that doesn't help with the case of uploading other types like Image, Canvas, Video... On 5 November 2015 at 16:45, Olli Etuaho wrote: > What's the exact use case for uploading textures from ImageData? Is the > idea that the image needs to go through some changes, like color > adjustments in JS before being uploaded to WebGL? Otherwise it seems > simpler to just use the entry points that upload images directly, which > would still have the WebGL conversion flags in Jeff's proposal. Maybe this > use case should rather be solved by adding flags to getImageData() that > would make it return premultiplied (or possibly flipped) data, as that > would also have the benefit of avoiding the possible premultiplied -> > non-premultiplied conversion when getting image data from canvas. It would > still be possible to do changes to the image data in JS, and then upload to > WebGL. Or do you see some issue with this alternative? > > > -Olli > ------------------------------ > *From:* owners-public_webgl...@ > on behalf of Ashley Gullen > *Sent:* Thursday, November 5, 2015 5:18 PM > *To:* Helmut Emmelmann > *Cc:* public_webgl...@ > *Subject:* Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and > UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 > > On 5 November 2015 at 13:50, Helmut Emmelmann wrote: >> >> > Lastly, these are slow paths, and as such are performance foot-guns, >> > even if we can (and do) warn when users use this functionality. >> On the other hand performance of texImage2D is very important, >> since it sometimes on slow devices and a large canvas takes longer than a >> frame and so causes dropped frames. > > > This can be mitigated by uploading in chunks with texSubImage2D, possibly > scheduled with something like requestIdleCallback. This only spreads out > the call across frames, and doesn't really make it async (which would be > great to have). I'm not sure if this impacts the question of supporting > these unpack options though, it sounds like it's harder for implementers to > support the sub-rectangle cases. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Fri Nov 6 14:19:12 2015 From: jgi...@ (Jeff Gilbert) Date: Fri, 6 Nov 2015 14:19:12 -0800 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: <563B5EA1.60307@taccgl.org> <1446741924166.34666@nvidia.com> Message-ID: To try to pull things back on topic, my proposal only affects uploads of ArrayBufferViews. FlipY and PremultAlpha for uploads of DOM objects is more constrained and has stronger use cases. Are there any objections for why ArrayBufferViews benefit from having FlipY and PremultAlpha unpack options? This certainly isn't in GLES. Conceptually, the user should prepare the contentes of their buffer, including orienting it and premultiplying alpha (if desired) before asking GL to upload it. Mature performance-aware apps will ensure that their data is baked in a form which is as-ready-as-possible for immediate upload. We can, of course, tolerate keeping only the backwards-compatibility-necessary behavior. My main concern is the new exploding combinatorics that WebGL 2's new UNPACK_ settings and new formats brings. On Fri, Nov 6, 2015 at 5:18 AM, Ashley Gullen wrote: > Yes, the use case is for JS to do pixel-manipulation operations before > passing to WebGL. For example in texture atlases to prevent > color/transparency bleed-in from outside the image area, it's useful to > repeat the outer border of pixels just outside the image. Canvas is > unsuitable for per-pixel operations like that, especially if the browser > tries to GPU-accelerate the context. So in that case JS would obtain an > ImageData, write to some entries, then pass it (in whole or in chunks) to > tex{Sub}Image2D. > > Modifying canvas2d's getImageData() is no help, because it is the worst way > of getting ImageData (often does synchronous main-thread image decoding) and > needs to be replaced. Perhaps there could be a method like > ImageData.premultiply()? But that doesn't help with the case of uploading > other types like Image, Canvas, Video... > > > On 5 November 2015 at 16:45, Olli Etuaho wrote: >> >> What's the exact use case for uploading textures from ImageData? Is the >> idea that the image needs to go through some changes, like color adjustments >> in JS before being uploaded to WebGL? Otherwise it seems simpler to just use >> the entry points that upload images directly, which would still have the >> WebGL conversion flags in Jeff's proposal. Maybe this use case should rather >> be solved by adding flags to getImageData() that would make it return >> premultiplied (or possibly flipped) data, as that would also have the >> benefit of avoiding the possible premultiplied -> non-premultiplied >> conversion when getting image data from canvas. It would still be possible >> to do changes to the image data in JS, and then upload to WebGL. Or do you >> see some issue with this alternative? >> >> >> -Olli >> >> ________________________________ >> From: owners-public_webgl...@ on >> behalf of Ashley Gullen >> Sent: Thursday, November 5, 2015 5:18 PM >> To: Helmut Emmelmann >> Cc: public_webgl...@ >> Subject: Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and >> UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 >> >> On 5 November 2015 at 13:50, Helmut Emmelmann wrote: >>> >>> > Lastly, these are slow paths, and as such are performance foot-guns, >>> > even if we can (and do) warn when users use this functionality. >>> On the other hand performance of texImage2D is very important, >>> since it sometimes on slow devices and a large canvas takes longer than a >>> frame and so causes dropped frames. >> >> >> This can be mitigated by uploading in chunks with texSubImage2D, possibly >> scheduled with something like requestIdleCallback. This only spreads out the >> call across frames, and doesn't really make it async (which would be great >> to have). I'm not sure if this impacts the question of supporting these >> unpack options though, it sounds like it's harder for implementers to >> support the sub-rectangle cases. >> > ----------------------------------------------------------- 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...@ Sat Nov 7 03:22:58 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Nov 2015 12:22:58 +0100 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: <563B5EA1.60307@taccgl.org> <1446741924166.34666@nvidia.com> Message-ID: On Fri, Nov 6, 2015 at 11:19 PM, Jeff Gilbert wrote: > We can, of course, tolerate keeping only the > backwards-compatibility-necessary behavior. What about ES 3.0 apps compiled to JS? Do they commonly rely on the full range of of the ES 3.0 spec? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Nov 7 03:43:57 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 7 Nov 2015 12:43:57 +0100 Subject: [Public WebGL] appropriate context loss response Message-ID: I've noticed that on iOS if there's a context loss (due to memory overstep or whatever), no context loss event is issued and instead the browser auto-reloads the page which leads to another context loss. I don't think the behavior for context loss is specified, just that it's possible to issue a context loss event. Should we specify the browser behavior in the WebGL specification so that a context loss behaves the same on all platforms and the page isn't uselessly reloaded? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Sat Nov 7 06:06:27 2015 From: ash...@ (Ashley Gullen) Date: Sat, 7 Nov 2015 14:06:27 +0000 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: <563B5EA1.60307@taccgl.org> <1446741924166.34666@nvidia.com> Message-ID: I think it's acceptable if it only applies to ArrayBufferViews. The use case I described involved pixel manipulation in JS code so it's also an appropriate point to do further manipulation to marshal the pixel data. ArrayBuffer is also transferable so they can be moved to workers for processing. I would still hope the WebGL 1 cases can still be covered for backwards compatibility though. On 6 November 2015 at 22:19, Jeff Gilbert wrote: > To try to pull things back on topic, my proposal only affects uploads > of ArrayBufferViews. FlipY and PremultAlpha for uploads of DOM objects > is more constrained and has stronger use cases. > > Are there any objections for why ArrayBufferViews benefit from having > FlipY and PremultAlpha unpack options? This certainly isn't in GLES. > Conceptually, the user should prepare the contentes of their buffer, > including orienting it and premultiplying alpha (if desired) before > asking GL to upload it. > > Mature performance-aware apps will ensure that their data is baked in > a form which is as-ready-as-possible for immediate upload. > > We can, of course, tolerate keeping only the > backwards-compatibility-necessary behavior. My main concern is the new > exploding combinatorics that WebGL 2's new UNPACK_ settings and new > formats brings. > > On Fri, Nov 6, 2015 at 5:18 AM, Ashley Gullen wrote: > > Yes, the use case is for JS to do pixel-manipulation operations before > > passing to WebGL. For example in texture atlases to prevent > > color/transparency bleed-in from outside the image area, it's useful to > > repeat the outer border of pixels just outside the image. Canvas is > > unsuitable for per-pixel operations like that, especially if the browser > > tries to GPU-accelerate the context. So in that case JS would obtain an > > ImageData, write to some entries, then pass it (in whole or in chunks) to > > tex{Sub}Image2D. > > > > Modifying canvas2d's getImageData() is no help, because it is the worst > way > > of getting ImageData (often does synchronous main-thread image decoding) > and > > needs to be replaced. Perhaps there could be a method like > > ImageData.premultiply()? But that doesn't help with the case of uploading > > other types like Image, Canvas, Video... > > > > > > On 5 November 2015 at 16:45, Olli Etuaho wrote: > >> > >> What's the exact use case for uploading textures from ImageData? Is the > >> idea that the image needs to go through some changes, like color > adjustments > >> in JS before being uploaded to WebGL? Otherwise it seems simpler to > just use > >> the entry points that upload images directly, which would still have the > >> WebGL conversion flags in Jeff's proposal. Maybe this use case should > rather > >> be solved by adding flags to getImageData() that would make it return > >> premultiplied (or possibly flipped) data, as that would also have the > >> benefit of avoiding the possible premultiplied -> non-premultiplied > >> conversion when getting image data from canvas. It would still be > possible > >> to do changes to the image data in JS, and then upload to WebGL. Or do > you > >> see some issue with this alternative? > >> > >> > >> -Olli > >> > >> ________________________________ > >> From: owners-public_webgl...@ > on > >> behalf of Ashley Gullen > >> Sent: Thursday, November 5, 2015 5:18 PM > >> To: Helmut Emmelmann > >> Cc: public_webgl...@ > >> Subject: Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and > >> UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 > >> > >> On 5 November 2015 at 13:50, Helmut Emmelmann wrote: > >>> > >>> > Lastly, these are slow paths, and as such are performance > foot-guns, > >>> > even if we can (and do) warn when users use this functionality. > >>> On the other hand performance of texImage2D is very important, > >>> since it sometimes on slow devices and a large canvas takes longer > than a > >>> frame and so causes dropped frames. > >> > >> > >> This can be mitigated by uploading in chunks with texSubImage2D, > possibly > >> scheduled with something like requestIdleCallback. This only spreads > out the > >> call across frames, and doesn't really make it async (which would be > great > >> to have). I'm not sure if this impacts the question of supporting these > >> unpack options though, it sounds like it's harder for implementers to > >> support the sub-rectangle cases. > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juj...@ Mon Nov 9 08:14:56 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Mon, 9 Nov 2015 18:14:56 +0200 Subject: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior In-Reply-To: References: Message-ID: What is the native OpenGL behavior on these? 2015-11-03 7:34 GMT+02:00 Jeff Gilbert : > > Same here, unfortunately. I do enjoy deleting code though. :) > > I can do the PR for this. > > On Mon, Nov 2, 2015 at 6:08 PM, Rafael Cintron > wrote: > > I am good with this. I wish we had done it sooner as it would have > saved me > > from writing a bunch of (now) unnecessary code. > > > > > > > > From: owners-public_webgl...@ > > [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell > > Sent: Monday, November 2, 2015 5:03 PM > > To: Jeff Gilbert > > Cc: webgl, public > > Subject: Re: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* > > behavior > > > > > > > > Thanks for proposing this and sorry for the delay reviewing it. > > > > > > > > This change sounds good to me. It's hard to imagine that applications are > > relying on the behavior of returning zero for out-of-bounds pixels during > > reads. Changing this for both WebGL 1.0 and 2.0 at the same time sounds > fine > > to me; no reason to make the specs diverge further. > > > > > > > > Any other feedback from implementers? There aren't that many conformance > > tests for this behavior, so it should be straightforward to update the > spec > > and those tests, and remove the invalidated tests from earlier versions > of > > the conformance suite. > > > > > > > > Assuming no objections, would you be willing to assemble a pull request > for > > both the spec and conformance test changes? > > > > > > > > Thanks, > > > > > > > > -Ken > > > > > > > > > > > > On Fri, Oct 30, 2015 at 6:03 AM, Jeff Gilbert > wrote: > > > > > > We standardized this to read zeros in WebGL 1. However, this is > > trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore > > options. > > > > I propose that we change this (at least for WebGL 2) to "Out-of-bounds > > pixels are not written to the destination during reads from a > > framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the > > destination buffer unchanged. Partially-out-of-bounds reads will only > > write in-bounds pixels to the destination buffer." > > > > This should be at easy or easier to implement, and be much more > > performant, since implementations can just restrict the size of their > > read and draw rects for these operations. > > > > I would really rather make out-of-bounds reads of this sort an > > INVALID_OPERATION, but a change to an error is more likely to be > > breaking in terms of existing content. While it's also a breaking > > change from OpenGL, I don't believe it is a porting concern, since > > porting can be fixed by changing its behavior to match what I outline > > above at the Emscripten (or other) level, though. > > > > ----------------------------------------------------------- > > 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 jgi...@ Mon Nov 9 13:15:28 2015 From: jgi...@ (Jeff Gilbert) Date: Mon, 9 Nov 2015 13:15:28 -0800 Subject: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* behavior In-Reply-To: References: Message-ID: The values read are undefined in the GLES spec. On Mon, Nov 9, 2015 at 8:14 AM, Jukka Jyl?nki wrote: > What is the native OpenGL behavior on these? > > 2015-11-03 7:34 GMT+02:00 Jeff Gilbert : >> >> >> Same here, unfortunately. I do enjoy deleting code though. :) >> >> I can do the PR for this. >> >> On Mon, Nov 2, 2015 at 6:08 PM, Rafael Cintron >> wrote: >> > I am good with this. I wish we had done it sooner as it would have >> > saved me >> > from writing a bunch of (now) unnecessary code. >> > >> > >> > >> > From: owners-public_webgl...@ >> > [mailto:owners-public_webgl...@] On Behalf Of Kenneth Russell >> > Sent: Monday, November 2, 2015 5:03 PM >> > To: Jeff Gilbert >> > Cc: webgl, public >> > Subject: Re: [Public WebGL] Out-of-bounds ReadPixels and CopyTex*Image* >> > behavior >> > >> > >> > >> > Thanks for proposing this and sorry for the delay reviewing it. >> > >> > >> > >> > This change sounds good to me. It's hard to imagine that applications >> > are >> > relying on the behavior of returning zero for out-of-bounds pixels >> > during >> > reads. Changing this for both WebGL 1.0 and 2.0 at the same time sounds >> > fine >> > to me; no reason to make the specs diverge further. >> > >> > >> > >> > Any other feedback from implementers? There aren't that many conformance >> > tests for this behavior, so it should be straightforward to update the >> > spec >> > and those tests, and remove the invalidated tests from earlier versions >> > of >> > the conformance suite. >> > >> > >> > >> > Assuming no objections, would you be willing to assemble a pull request >> > for >> > both the spec and conformance test changes? >> > >> > >> > >> > Thanks, >> > >> > >> > >> > -Ken >> > >> > >> > >> > >> > >> > On Fri, Oct 30, 2015 at 6:03 AM, Jeff Gilbert >> > wrote: >> > >> > >> > We standardized this to read zeros in WebGL 1. However, this is >> > trickier in WebGL 2 because of PBOs and the new PACK_ pixelstore >> > options. >> > >> > I propose that we change this (at least for WebGL 2) to "Out-of-bounds >> > pixels are not written to the destination during reads from a >> > framebuffer (ReadPixels or CopyTex*Image*), leaving the values in the >> > destination buffer unchanged. Partially-out-of-bounds reads will only >> > write in-bounds pixels to the destination buffer." >> > >> > This should be at easy or easier to implement, and be much more >> > performant, since implementations can just restrict the size of their >> > read and draw rects for these operations. >> > >> > I would really rather make out-of-bounds reads of this sort an >> > INVALID_OPERATION, but a change to an error is more likely to be >> > breaking in terms of existing content. While it's also a breaking >> > change from OpenGL, I don't believe it is a porting concern, since >> > porting can be fixed by changing its behavior to match what I outline >> > above at the Emscripten (or other) level, though. >> > >> > ----------------------------------------------------------- >> > 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 Nov 10 14:05:49 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 10 Nov 2015 14:05:49 -0800 Subject: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2 In-Reply-To: References: <563B5EA1.60307@taccgl.org> <1446741924166.34666@nvidia.com> Message-ID: While we have erected some barriers to this already, this case shouldn't effect ES3 apps. (these enums are WebGL-only) On Sat, Nov 7, 2015 at 3:22 AM, Florian B?sch wrote: > On Fri, Nov 6, 2015 at 11:19 PM, Jeff Gilbert wrote: >> >> We can, of course, tolerate keeping only the >> backwards-compatibility-necessary behavior. > > What about ES 3.0 apps compiled to JS? Do they commonly rely on the full > range of of the ES 3.0 spec? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From din...@ Wed Nov 11 09:10:54 2015 From: din...@ (Dean Jackson) Date: Wed, 11 Nov 2015 09:10:54 -0800 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: Message-ID: > On Nov 7, 2015, at 3:43 AM, Florian B?sch wrote: > > I've noticed that on iOS if there's a context loss (due to memory overstep or whatever), no context loss event is issued and instead the browser auto-reloads the page which leads to another context loss. This could be because we detected a GPU issue from which we could not recover gracefully, so we killed the process (which caused the page to be reloaded). Another way to say that is that this behaviour is a bug in iOS that we'll try to fix. Dean > > I don't think the behavior for context loss is specified, just that it's possible to issue a context loss event. > > Should we specify the browser behavior in the WebGL specification so that a context loss behaves the same on all platforms and the page isn't uselessly reloaded? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Nov 11 09:27:49 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Nov 2015 18:27:49 +0100 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: Message-ID: Yes, but what I mean is, how do you know it's a bug and not a feature? Afaik it's not specified that this isn't an appropriate response to a context loss... On Wed, Nov 11, 2015 at 6:10 PM, Dean Jackson wrote: > > > On Nov 7, 2015, at 3:43 AM, Florian B?sch wrote: > > > > I've noticed that on iOS if there's a context loss (due to memory > overstep or whatever), no context loss event is issued and instead the > browser auto-reloads the page which leads to another context loss. > > This could be because we detected a GPU issue from which we could not > recover gracefully, so we killed the process (which caused the page to be > reloaded). Another way to say that is that this behaviour is a bug in iOS > that we'll try to fix. > > Dean > > > > > I don't think the behavior for context loss is specified, just that it's > possible to issue a context loss event. > > > > Should we specify the browser behavior in the WebGL specification so > that a context loss behaves the same on all platforms and the page isn't > uselessly reloaded? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Wed Nov 11 09:39:15 2015 From: din...@ (Dean Jackson) Date: Wed, 11 Nov 2015 09:39:15 -0800 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: Message-ID: > On 11 Nov 2015, at 9:27 AM, Florian B?sch wrote: > > Yes, but what I mean is, how do you know it's a bug and not a feature? Afaik it's not specified that this isn't an appropriate response to a context loss... Yeah, I get that's what you're trying to clarify. I do think it should (must?) be "acceptable" to kill the process/page completely if necessary. Obviously detecting that the context is broken and firing a context lost event is the preferred option, but I don't think we can require all implementations to always recover gracefully. Dean > > On Wed, Nov 11, 2015 at 6:10 PM, Dean Jackson > wrote: > > > On Nov 7, 2015, at 3:43 AM, Florian B?sch > wrote: > > > > I've noticed that on iOS if there's a context loss (due to memory overstep or whatever), no context loss event is issued and instead the browser auto-reloads the page which leads to another context loss. > > This could be because we detected a GPU issue from which we could not recover gracefully, so we killed the process (which caused the page to be reloaded). Another way to say that is that this behaviour is a bug in iOS that we'll try to fix. > > Dean > > > > > I don't think the behavior for context loss is specified, just that it's possible to issue a context loss event. > > > > Should we specify the browser behavior in the WebGL specification so that a context loss behaves the same on all platforms and the page isn't uselessly reloaded? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Nov 11 09:51:41 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Nov 2015 18:51:41 +0100 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: Message-ID: On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson wrote: > I do think it should (must?) be "acceptable" to kill the process/page > completely if necessary. > Obviously detecting that the context is broken and firing a context lost > event is the preferred option, but I don't think we can require all > implementations to always recover gracefully. > The issue is that if you kill the whole page, a reload will just kill it again in an endless loop (or however many auto-reloads iOS safari does by itself). It's night impossible to use iOS safari if it does that (closing the tab manually becomes quite challenging etc.). It also leaves the JS on the page with no clue that it did something bad (munch too much vram or whatever) and so no avenue to rectify/address the "bad" behavior. On the whole it's just really, really bad, is why I think it'd make a fairly good requirement for a specification. -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Wed Nov 11 09:55:53 2015 From: din...@ (Dean Jackson) Date: Wed, 11 Nov 2015 09:55:53 -0800 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: Message-ID: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> > On 11 Nov 2015, at 9:51 AM, Florian B?sch wrote: > > On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson > wrote: > I do think it should (must?) be "acceptable" to kill the process/page completely if necessary. > Obviously detecting that the context is broken and firing a context lost event is the preferred option, but I don't think we can require all implementations to always recover gracefully. > > The issue is that if you kill the whole page, a reload will just kill it again in an endless loop (or however many auto-reloads iOS safari does by itself). It's night impossible to use iOS safari if it does that (closing the tab manually becomes quite challenging etc.). It also leaves the JS on the page with no clue that it did something bad (munch too much vram or whatever) and so no avenue to rectify/address the "bad" behavior. On the whole it's just really, really bad, is why I think it'd make a fairly good requirement for a specification. Safari should only reload the page twice and then give up. It's definitely a bug if it reloads constantly. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Nov 11 10:01:11 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Nov 2015 19:01:11 +0100 Subject: [Public WebGL] appropriate context loss response In-Reply-To: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> References: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> Message-ID: As more JS/Canvas/WebGL is being embedded on third party pages around the mobile web (because no flash), it becomes quite a bit of a problem if iOS safari throws a hissing fit everytime an iFrame or WebGL context on a page exceeds its (unknown and unknowable) resource limit and therefore borks the whole page. But this is the WebGL specification ML, we can't mandate that browsers behave nicely for everything, we could mandate they don't throw hissing fits if WebGL is being used in fashion that exceeds invisible resource limit border. On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson wrote: > > On 11 Nov 2015, at 9:51 AM, Florian B?sch wrote: > > On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson wrote: > >> I do think it should (must?) be "acceptable" to kill the process/page >> completely if necessary. >> > Obviously detecting that the context is broken and firing a context lost >> event is the preferred option, but I don't think we can require all >> implementations to always recover gracefully. >> > > The issue is that if you kill the whole page, a reload will just kill it > again in an endless loop (or however many auto-reloads iOS safari does by > itself). It's night impossible to use iOS safari if it does that (closing > the tab manually becomes quite challenging etc.). It also leaves the JS on > the page with no clue that it did something bad (munch too much vram or > whatever) and so no avenue to rectify/address the "bad" behavior. On the > whole it's just really, really bad, is why I think it'd make a fairly good > requirement for a specification. > > > Safari should only reload the page twice and then give up. It's definitely > a bug if it reloads constantly. > > Dean > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elf...@ Wed Nov 11 10:53:59 2015 From: elf...@ (Francisco Avila) Date: Wed, 11 Nov 2015 10:53:59 -0800 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> Message-ID: +1 a proper response would allow us to at least show a message to the user. -Frank On Wed, Nov 11, 2015 at 10:01 AM, Florian B?sch wrote: > As more JS/Canvas/WebGL is being embedded on third party pages around the > mobile web (because no flash), it becomes quite a bit of a problem if iOS > safari throws a hissing fit everytime an iFrame or WebGL context on a page > exceeds its (unknown and unknowable) resource limit and therefore borks the > whole page. But this is the WebGL specification ML, we can't mandate that > browsers behave nicely for everything, we could mandate they don't throw > hissing fits if WebGL is being used in fashion that exceeds invisible > resource limit border. > > On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson wrote: > >> >> On 11 Nov 2015, at 9:51 AM, Florian B?sch wrote: >> >> On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson wrote: >> >>> I do think it should (must?) be "acceptable" to kill the process/page >>> completely if necessary. >>> >> Obviously detecting that the context is broken and firing a context lost >>> event is the preferred option, but I don't think we can require all >>> implementations to always recover gracefully. >>> >> >> The issue is that if you kill the whole page, a reload will just kill it >> again in an endless loop (or however many auto-reloads iOS safari does by >> itself). It's night impossible to use iOS safari if it does that (closing >> the tab manually becomes quite challenging etc.). It also leaves the JS on >> the page with no clue that it did something bad (munch too much vram or >> whatever) and so no avenue to rectify/address the "bad" behavior. On the >> whole it's just really, really bad, is why I think it'd make a fairly good >> requirement for a specification. >> >> >> Safari should only reload the page twice and then give up. It's >> definitely a bug if it reloads constantly. >> >> Dean >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emm...@ Wed Nov 11 12:01:02 2015 From: emm...@ (Helmut Emmelmann) Date: Wed, 11 Nov 2015 21:01:02 +0100 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> Message-ID: <56439E7E.4000803@taccgl.org> It would be very useful to somehow let the js code know that there is a problem, so that it can show alternate content e.g. simplified WebGL content or content not using WebGL at all. I am using WebGL in a way to improve the look of classical web pages and in this kind of application it is not a very big problem if the WebGL content does not show but its a big problem if it breaks the page completely. Am 11/11/2015 um 7:01 PM schrieb Florian B?sch: > As more JS/Canvas/WebGL is being embedded on third party pages around > the mobile web (because no flash), it becomes quite a bit of a problem > if iOS safari throws a hissing fit everytime an iFrame or WebGL context > on a page exceeds its (unknown and unknowable) resource limit and > therefore borks the whole page. But this is the WebGL specification ML, > we can't mandate that browsers behave nicely for everything, we could > mandate they don't throw hissing fits if WebGL is being used in fashion > that exceeds invisible resource limit border. > > On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson > wrote: > > >> On 11 Nov 2015, at 9:51 AM, Florian B?sch > > wrote: >> >> On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson > > wrote: >> >> I do think it should (must?) be "acceptable" to kill the >> process/page completely if necessary. >> >> Obviously detecting that the context is broken and firing a >> context lost event is the preferred option, but I don't think >> we can require all implementations to always recover gracefully. >> >> >> The issue is that if you kill the whole page, a reload will just >> kill it again in an endless loop (or however many auto-reloads iOS >> safari does by itself). It's night impossible to use iOS safari if >> it does that (closing the tab manually becomes quite challenging >> etc.). It also leaves the JS on the page with no clue that it did >> something bad (munch too much vram or whatever) and so no avenue >> to rectify/address the "bad" behavior. On the whole it's just >> really, really bad, is why I think it'd make a fairly good >> requirement for a specification. > > Safari should only reload the page twice and then give up. It's > definitely a bug if it reloads constantly. > > Dean > > ------------------------------------------------------------------------- H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim Germany | Ph:+49 621-795141 | Fax: +49 621-7951 | emmel...@ Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 Handelsregister: HRB 7273 | Amtsgericht Mannheim http://www.taccgl.org | http://www.h-e-i.de ------------------------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From Raf...@ Wed Nov 11 12:34:19 2015 From: Raf...@ (Rafael Cintron) Date: Wed, 11 Nov 2015 20:34:19 +0000 Subject: [Public WebGL] appropriate context loss response In-Reply-To: <56439E7E.4000803@taccgl.org> References: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> <56439E7E.4000803@taccgl.org> Message-ID: The appropriate response to context loss is documented in the WebGL spec, specifically section 5.15.2. (https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.15.2) The spec also has example code that illustrates how an application can handle context loss and restoration. I've pasted the important portions below: 5.15.2 The Context Lost Event When the user agent detects that the drawing buffer associated with a WebGLRenderingContext context has been lost, it must run the following steps: 1. Let canvas be the context's canvas. 2. If context's webgl context lost flag is set, abort these steps. 3. Set context's webgl context lost flag. 4. Set the invalidated flag of each WebGLObject instance created by this context. 5. Disable all extensions except "WEBGL_lose_context". 6. Queue a task to perform the following steps: 0.0.1. Fire a WebGL context event named "webglcontextlost" at canvas, with its statusMessage attribute set to "". 6.1. If the event's canceled flag is not set, abort these steps. 6.2. Perform the following steps asynchronously. 6.3. Await a restorable drawing buffer. 6.6. Queue a task to restore the drawing buffer for context. Example V The following code prevents the default behavior of the webglcontextlost event and enables the webglcontextrestored event to be delivered: canvas.addEventListener("webglcontextlost", function(e) { e.preventDefault(); }, false); 5.15.3 The Context Restored Event When the user agent is to restore the drawing buffer for a WebGLRenderingContext context, it must run the following steps: 1. Let canvas be the canvas object associated with context. 2. If context's webgl context lost flag is not set, abort these steps. 3. Create a drawing buffer using the settings specified in context's context creation parameters, and associate the drawing buffer with context, discarding any previous drawing buffer. 4. Clear context's webgl context lost flag. 5. Reset context's OpenGL error state. 6. Fire a WebGL context event named "webglcontextrestored" at canvas, with its statusMessage attribute set to "". Non-normative: Once the context is restored, WebGL resources such as textures and buffers that were created before the context was lost are no longer valid. The application needs to reinitialize the context's state and recreate all such resources. Edge and IE detect D3D device removal and (barring any bugs) resets the D3D device such that the page can resume its business. If the developer calls e.preventDefault, it can get back a new webgl context, as explained in the spec. Since device removal can potentially destabilize other applications running on the system, Edge and IE reset into software mode to avoid repeated resets. We do not reload the page. If you find bugs with IE and Edge's behavior, please let me know. --Rafael -----Original Message----- From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of Helmut Emmelmann Sent: Wednesday, November 11, 2015 12:01 PM To: Florian B?sch ; Dean Jackson Cc: public webgl Subject: Re: [Public WebGL] appropriate context loss response It would be very useful to somehow let the js code know that there is a problem, so that it can show alternate content e.g. simplified WebGL content or content not using WebGL at all. I am using WebGL in a way to improve the look of classical web pages and in this kind of application it is not a very big problem if the WebGL content does not show but its a big problem if it breaks the page completely. Am 11/11/2015 um 7:01 PM schrieb Florian B?sch: > As more JS/Canvas/WebGL is being embedded on third party pages around > the mobile web (because no flash), it becomes quite a bit of a problem > if iOS safari throws a hissing fit everytime an iFrame or WebGL > context on a page exceeds its (unknown and unknowable) resource limit > and therefore borks the whole page. But this is the WebGL > specification ML, we can't mandate that browsers behave nicely for > everything, we could mandate they don't throw hissing fits if WebGL is > being used in fashion that exceeds invisible resource limit border. > > On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson > wrote: > > >> On 11 Nov 2015, at 9:51 AM, Florian B?sch > > wrote: >> >> On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson > > wrote: >> >> I do think it should (must?) be "acceptable" to kill the >> process/page completely if necessary. >> >> Obviously detecting that the context is broken and firing a >> context lost event is the preferred option, but I don't think >> we can require all implementations to always recover gracefully. >> >> >> The issue is that if you kill the whole page, a reload will just >> kill it again in an endless loop (or however many auto-reloads iOS >> safari does by itself). It's night impossible to use iOS safari if >> it does that (closing the tab manually becomes quite challenging >> etc.). It also leaves the JS on the page with no clue that it did >> something bad (munch too much vram or whatever) and so no avenue >> to rectify/address the "bad" behavior. On the whole it's just >> really, really bad, is why I think it'd make a fairly good >> requirement for a specification. > > Safari should only reload the page twice and then give up. It's > definitely a bug if it reloads constantly. > > Dean > > ------------------------------------------------------------------------- H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim Germany | Ph:+49 621-795141 | Fax: +49 621-7951 | emmel...@ Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 Handelsregister: HRB 7273 | Amtsgericht Mannheim http://www.taccgl.org | http://www.h-e-i.de ------------------------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Nov 11 13:16:47 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 11 Nov 2015 22:16:47 +0100 Subject: [Public WebGL] appropriate context loss response In-Reply-To: References: <0A50B5A4-095D-4D98-863C-CEC796F31912@apple.com> <56439E7E.4000803@taccgl.org> Message-ID: That's the description of how context loss works. It doesn't specify that page reload is an invalid context loss response right? On Wed, Nov 11, 2015 at 9:34 PM, Rafael Cintron < Rafael.Cintron...@> wrote: > The appropriate response to context loss is documented in the WebGL spec, > specifically section 5.15.2. ( > https://www.khronos.org/registry/webgl/specs/latest/1.0/#5.15.2) The spec > also has example code that illustrates how an application can handle > context loss and restoration. > > I've pasted the important portions below: > 5.15.2 The Context Lost Event > > When the user agent detects that the drawing buffer associated > with a WebGLRenderingContext context has been lost, it must run the > following steps: > 1. Let canvas be the context's canvas. > 2. If context's webgl context lost flag is set, abort these steps. > 3. Set context's webgl context lost flag. > 4. Set the invalidated flag of each WebGLObject instance created > by this context. > 5. Disable all extensions except "WEBGL_lose_context". > 6. Queue a task to perform the following steps: 0.0.1. Fire a > WebGL context event named "webglcontextlost" at canvas, with its > statusMessage attribute set to "". > 6.1. If the event's canceled flag is not set, abort these steps. > 6.2. Perform the following steps asynchronously. > 6.3. Await a restorable drawing buffer. > 6.6. Queue a task to restore the drawing buffer for context. > > Example V The following code prevents the default behavior of the > webglcontextlost event and enables the webglcontextrestored event to be > delivered: > canvas.addEventListener("webglcontextlost", function(e) { > e.preventDefault(); }, false); > > 5.15.3 The Context Restored Event > > When the user agent is to restore the drawing buffer for a > WebGLRenderingContext context, it must run the following steps: > 1. Let canvas be the canvas object associated with context. > 2. If context's webgl context lost flag is not set, abort these > steps. > 3. Create a drawing buffer using the settings specified in > context's context creation parameters, and associate the drawing buffer > with context, discarding any previous drawing buffer. > 4. Clear context's webgl context lost flag. > 5. Reset context's OpenGL error state. > 6. Fire a WebGL context event named "webglcontextrestored" at > canvas, with its statusMessage attribute set to "". > > Non-normative: Once the context is restored, WebGL resources such > as textures and buffers that were created before the context was lost are > no longer valid. The application needs to reinitialize the context's state > and recreate all such resources. > > > Edge and IE detect D3D device removal and (barring any bugs) resets the > D3D device such that the page can resume its business. If the developer > calls e.preventDefault, it can get back a new webgl context, as explained > in the spec. Since device removal can potentially destabilize other > applications running on the system, Edge and IE reset into software mode to > avoid repeated resets. We do not reload the page. > > If you find bugs with IE and Edge's behavior, please let me know. > > --Rafael > > -----Original Message----- > From: owners-public_webgl...@ [mailto: > owners-public_webgl...@] On Behalf Of Helmut Emmelmann > Sent: Wednesday, November 11, 2015 12:01 PM > To: Florian B?sch ; Dean Jackson > Cc: public webgl > Subject: Re: [Public WebGL] appropriate context loss response > > > It would be very useful to somehow let the js code know that there is a > problem, so that it can show alternate content e.g. simplified WebGL > content or content not using WebGL at all. I am using WebGL in a way to > improve the look of classical web pages and in this kind of application it > is not a very big problem if the WebGL content does not show but its a big > problem if it breaks the page completely. > > Am 11/11/2015 um 7:01 PM schrieb Florian B?sch: > > As more JS/Canvas/WebGL is being embedded on third party pages around > > the mobile web (because no flash), it becomes quite a bit of a problem > > if iOS safari throws a hissing fit everytime an iFrame or WebGL > > context on a page exceeds its (unknown and unknowable) resource limit > > and therefore borks the whole page. But this is the WebGL > > specification ML, we can't mandate that browsers behave nicely for > > everything, we could mandate they don't throw hissing fits if WebGL is > > being used in fashion that exceeds invisible resource limit border. > > > > On Wed, Nov 11, 2015 at 6:55 PM, Dean Jackson > > wrote: > > > > > >> On 11 Nov 2015, at 9:51 AM, Florian B?sch >> > wrote: > >> > >> On Wed, Nov 11, 2015 at 6:39 PM, Dean Jackson >> > wrote: > >> > >> I do think it should (must?) be "acceptable" to kill the > >> process/page completely if necessary. > >> > >> Obviously detecting that the context is broken and firing a > >> context lost event is the preferred option, but I don't think > >> we can require all implementations to always recover gracefully. > >> > >> > >> The issue is that if you kill the whole page, a reload will just > >> kill it again in an endless loop (or however many auto-reloads iOS > >> safari does by itself). It's night impossible to use iOS safari if > >> it does that (closing the tab manually becomes quite challenging > >> etc.). It also leaves the JS on the page with no clue that it did > >> something bad (munch too much vram or whatever) and so no avenue > >> to rectify/address the "bad" behavior. On the whole it's just > >> really, really bad, is why I think it'd make a fairly good > >> requirement for a specification. > > > > Safari should only reload the page twice and then give up. It's > > definitely a bug if it reloads constantly. > > > > Dean > > > > > ------------------------------------------------------------------------- > H.E.I. Informationssystems GmbH | Wimpfenerstra?e 23 | 68259 Mannheim > Germany | Ph:+49 621-795141 | Fax: +49 621-7951 | emmel...@ > Gesch?ftsf?hrer: Dr.Helmut Emmelmann, StNr.37001/32880,UstId DE185233091 > Handelsregister: HRB 7273 | Amtsgericht Mannheim > http://www.taccgl.org | http://www.h-e-i.de > ------------------------------------------------------------------------- > > ----------------------------------------------------------- > 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: