From bre...@ Thu Jan 1 15:15:49 2015 From: bre...@ (Brett Camper) Date: Thu, 1 Jan 2015 15:15:49 -0800 Subject: [Public WebGL] early warning: sharp dropoff in google chrome OSX webgl support levels In-Reply-To: References: Message-ID: Florian - regarding cloud service IPs, here is a database of known data center IPs that we used to filter traffic for similar purposes when I was at Kickstarter: https://github.com/client9/ipcat (see also https://github.com/kickstarter/ipcat-ruby). It is not perfect but sending along in case it is useful. Best, Brett --- Brett Camper Mapzen, an open-source mapping lab - http://mapzen.com Tangram, WebGL for OpenStreetMap - http://mapzen.com/tangram, https://github.com/tangrams/tangram On Tue, Dec 30, 2014 at 2:29 AM, Florian B?sch wrote: > It'd be useful if google and microsoft could publish ip-range lists for > their compute services at a canonical up-to-date URL too. > > On Tue, Dec 30, 2014 at 11:23 AM, Florian B?sch wrote: > >> I've added an IP-range filtering mechanism to the http://webglstats.com/ >> analysis that looks for the IP-ranges of amazon-aws >> https://ip-ranges.amazonaws.com/ip-ranges.json . This should eliminate >> the anomaly in the new year. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Fri Jan 2 10:12:02 2015 From: zmo...@ (Zhenyao Mo) Date: Fri, 2 Jan 2015 10:12:02 -0800 Subject: [Public WebGL] Losing GL context during rAF execution? In-Reply-To: References: Message-ID: Context lost can happen any time. On Wed, Dec 31, 2014 at 6:02 AM, Jukka Jyl?nki wrote: > Hi there, > > Is it possible to lose the WebGL context *during* the execution of a rAF > handler (or for that matter, during some other JS code)? That is, if I have > the following code: > > function rAF() { > if (gl.isContextLost()) { > // handle loss > return; > } > gl.xxx(); > gl.yyy(); > window.requestAnimationFrame(rAF); > } > > is it allowed that the GL context gets lost during the GL calls in the > middle? > > Thanks, > Jukka ----------------------------------------------------------- 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 juj...@ Fri Jan 2 11:18:08 2015 From: juj...@ (=?UTF-8?Q?Jukka_Jyl=C3=A4nki?=) Date: Fri, 2 Jan 2015 21:18:08 +0200 Subject: [Public WebGL] Losing GL context during rAF execution? In-Reply-To: References: Message-ID: I've been unsure about the wording as to whether it's possible to actually lose the context in the middle of a stream of GL calls, or if that can happen only when execution is yielded back to the browser. I guess since the spec doesn't say anything about it specifically, then the former should be assumed. Thanks, I think that clears it up. 2015-01-02 20:12 GMT+02:00 Zhenyao Mo : > Context lost can happen any time. > > On Wed, Dec 31, 2014 at 6:02 AM, Jukka Jyl?nki wrote: > > Hi there, > > > > Is it possible to lose the WebGL context *during* the execution of a rAF > > handler (or for that matter, during some other JS code)? That is, if I > have > > the following code: > > > > function rAF() { > > if (gl.isContextLost()) { > > // handle loss > > return; > > } > > gl.xxx(); > > gl.yyy(); > > window.requestAnimationFrame(rAF); > > } > > > > is it allowed that the GL context gets lost during the GL calls in the > > middle? > > > > Thanks, > > Jukka > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdo...@ Mon Jan 5 07:51:35 2015 From: mdo...@ (Matthias Dondorff) Date: Mon, 5 Jan 2015 16:51:35 +0100 Subject: [Public WebGL] Unclear "Texture Upload Width and Height" definition Message-ID: The latest draft of WebGL 1.0 (10th Dec. 2014) is unclear on the size of the texture after upload from a HTMLImageElement and the current behavior differs for SVG vs non SVG images. Snip from WebGL 1.0 latest: > 6.7 Texture Upload Width and Height > > Unless width and height parameters are explicitly specified, the width and height of the texture > set by texImage2D and the width and height of the sub-rectangle updated by texSubImage2D > are determined based on the uploaded TexImageSource source object: > [...] > source of type HTMLImageElement > If a bitmap is uploaded, the width and height of the texture are set to the width and height > of the uploaded bitmap in pixels. If an SVG image is uploaded, the width and height of the > texture are set to the current values of the width and height properties of the > HTMLImageElement object. Regarding the uploaded size: The phrase "are set to the width and height of the uploaded bitmap in pixels" is unspecific. - Proposal Explicitly specify which property of the HTMLImageElement will be used, i.e. "naturalWidth" and "naturalHeight". - Rational The width and height property is modifiable and define the elements (probably scaled) width and height. Uploading a scaled image should not be part of the texture upload specification (and afaik isn't currently implemented). Explicitly defining what property will be used, will help developers understand behavior. Regarding SVG support: To determine the texture size, a developer would have to investigate the type of image element being uploaded, since the 'naturalWidth' is taken for non-SVG images whereas 'width' is taken for SVG images. - Proposal Strip specialization for SVG images and also take the naturalWidth / naturalHeight property for those type of images. - Rational If a specific size of a SVG is needed, uploading a scaled SVG image is possible through the use of a 2D canvas and upload this. This is more cumbersome than using the widht / height property but a more streamlined API weighs more than this, imho. Are there any known users of the scaling behavior for SVG graphics? -- Matthias Dondorff | Software Engineer | mdondorff...@ Google Germany GmbH Maria-Goeppert-Str. 3 23562 L?beck Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch?ftsf?hrer: Graham Law, Christine Elizabeth Flores If you received this communication by mistake, please don't forward it to anyone else (it may contain confidential or privileged information), please erase all copies of it, including all attachments, and please let the sender know it went to the wrong person. Thanks. Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und l?schen Sie die E-Mail und alle Anh?nge. Vielen Dank. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Jan 5 13:39:43 2015 From: jgi...@ (Jeff Gilbert) Date: Mon, 5 Jan 2015 13:39:43 -0800 Subject: [Public WebGL] Losing GL context during rAF execution? In-Reply-To: References: Message-ID: I'll explicitly add that WebGL commands can trigger context loss. On Fri, Jan 2, 2015 at 11:18 AM, Jukka Jyl?nki wrote: > I've been unsure about the wording as to whether it's possible to actually > lose the context in the middle of a stream of GL calls, or if that can > happen only when execution is yielded back to the browser. I guess since > the spec doesn't say anything about it specifically, then the former should > be assumed. Thanks, I think that clears it up. > > 2015-01-02 20:12 GMT+02:00 Zhenyao Mo : > >> Context lost can happen any time. >> >> On Wed, Dec 31, 2014 at 6:02 AM, Jukka Jyl?nki wrote: >> > Hi there, >> > >> > Is it possible to lose the WebGL context *during* the execution of a rAF >> > handler (or for that matter, during some other JS code)? That is, if I >> have >> > the following code: >> > >> > function rAF() { >> > if (gl.isContextLost()) { >> > // handle loss >> > return; >> > } >> > gl.xxx(); >> > gl.yyy(); >> > window.requestAnimationFrame(rAF); >> > } >> > >> > is it allowed that the GL context gets lost during the GL calls in the >> > middle? >> > >> > Thanks, >> > Jukka >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 5 23:38:43 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 08:38:43 +0100 Subject: [Public WebGL] extension candidates for khronos ratification from community approved Message-ID: The following extensions now have widespread and cross vendor implementation coverage and I'd like to propose them as candidates for Khronos ratification: EXT_frag_depth, supported by: - windows - chrome - firefox - opera - osx - chrome - firefox - opera - linux - chrome - chromium - firefox - opera EXT_blend_minmax, supported by: - windows - chrome - opera - firefox - osx - chrome - firefox - opera - linux - chrome - chromium - firefox - opera - android - mobile firefox EXT_shader_texture_lod - windows - chrome - firefox - opera - osx - safari - chrome - opera - linux - chrome - chromium - opera - android - chrome mobile - opera mobile - mobile firefox - ios - mobile safari - chrome mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jan 6 02:31:01 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 11:31:01 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification Message-ID: Some of the frequent problems with properly handling shader/program info log information is: - How to locate the line and column number (because different backends/browsers report it differently) - How to separate log entries (that may span multiple lines) into distinct entries for each error reported - empty error message ("") - unusable error messages (like those linker error messages that reference Direct3D intermediary bytecode and are piped trough straight I'm wondering if it would make sense to come up with some sort of formal specification for WebGL 2.0 that ensures that: - the returned log info is a proper structure (lists/objects) - That line and column numbers are not mangled together with the log entry text - For convenience may include the sourceline - That ensures all reported errors are not piped trough from some backend, but are relevant to the source passed in Maybe something along the lines of: info-log := [error, error] error := object { line: INT column: INT message: STRING sourceline: STRING } -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Tue Jan 6 04:53:00 2015 From: khr...@ (Mark Callow) Date: Tue, 6 Jan 2015 21:53:00 +0900 Subject: [Public WebGL] Losing GL context during rAF execution? In-Reply-To: References: Message-ID: <9B4657C6-EDA5-4B38-8842-BA5C7161E077@callow.im> > On Jan 6, 2015, at 6:39 AM, Jeff Gilbert wrote: > > I'll explicitly add that WebGL commands can trigger context loss. > I don?t think ?WebGL commands can trigger context loss? is the right wording. ?Context loss can happen at any time during execution of WebGL commands? is better. It is not usually the WebGL commands that trigger the context loss. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Tue Jan 6 04:56:58 2015 From: khr...@ (Mark Callow) Date: Tue, 6 Jan 2015 21:56:58 +0900 Subject: [Public WebGL] extension candidates for khronos ratification from community approved In-Reply-To: References: Message-ID: <6EDE7E3B-A0ED-4A38-9106-56F68345CECC@callow.im> > On Jan 6, 2015, at 4:38 PM, Florian B?sch wrote: > > The following extensions now have widespread and cross vendor implementation coverage and I'd like to propose them as candidates for Khronos ratification: > > EXT_frag_depth? EXT extensions aren?t ratified by Khronos. They are simply multi-vendor extensions. Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Tue Jan 6 04:59:45 2015 From: khr...@ (Mark Callow) Date: Tue, 6 Jan 2015 21:59:45 +0900 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> > On Jan 6, 2015, at 7:31 PM, Florian B?sch wrote: > > Some of the frequent problems with properly handling shader/program info log information is: > How to locate the line and column number (because different backends/browsers report it differently) > How to separate log entries (that may span multiple lines) into distinct entries for each error reported > empty error message ("") > unusable error messages (like those linker error messages that reference Direct3D intermediary bytecode and are piped trough straight > I'm wondering if it would make sense to come up with some sort of formal specification for WebGL 2.0 that ensures that: > the returned log info is a proper structure (lists/objects) > That line and column numbers are not mangled together with the log entry text > For convenience may include the sourceline > That ensures all reported errors are not piped trough from some backend, but are relevant to the source passed in > Maybe something along the lines of: > > info-log := [error, error] > error := object { > line: INT > column: INT > message: STRING > sourceline: STRING > } > This is a great idea but I suspect it will be a nightmare to implement due to lack of similar functionality in OpenGL{, ES}. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Tue Jan 6 05:10:27 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 14:10:27 +0100 Subject: [Public WebGL] extension candidates for khronos ratification from community approved In-Reply-To: <6EDE7E3B-A0ED-4A38-9106-56F68345CECC@callow.im> References: <6EDE7E3B-A0ED-4A38-9106-56F68345CECC@callow.im> Message-ID: On Tue, Jan 6, 2015 at 1:56 PM, Mark Callow wrote: > > EXT extensions aren?t ratified by Khronos. They are simply multi-vendor > extensions. Objection irrelevant. This understanding of the extension process is derived from the ES-native registries, it has no bearing on the WebGL extension registry. Please consult https://www.khronos.org/registry/webgl/extensions/ for the WebGL extension process. The EXT_ prefix (as well as any other prefix mirrored from an ES extension) does not have a specific meaning for the WebGL ratification process. *Khronos ratified* extensions are those community approved extensions which > have been voted upon by the Khronos Board of Promoters Precedents for non OES extensions that've been WebGL Khronos Ratified: - WEBGL_lose_context - WEBGL_debug_renderer_info - WEBGL_debug_shaders - WEBGL_compressed_texture_s3tc - WEBGL_depth_texture - EXT_texture_filter_anisotropic - WEBGL_draw_buffers - ANGLE_instanced_arrays The status "community approved" was introduced so that WebGL extensions can be moved out of draft (where they would be vendor prefixed) in order to avoid extensions languishing in eternal draft hell until the Khronos board got around to ratify them. The goal of a community approved extension is to make it to Khronos ratified to complete the process. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jan 6 05:17:16 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 14:17:16 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> References: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> Message-ID: On Tue, Jan 6, 2015 at 1:59 PM, Mark Callow wrote: > This is a great idea but I suspect it will be a nightmare to implement due > to lack of similar functionality in OpenGL{, ES}. > WebGL can introduce additional functionality in its specification as it partains to its specific needs. It's preferrable browser vendors, who have full access to all machine/GPU parameters and underlying transpiled code implement consistent handling of error info logs, than that WebGL users, who only have an incomplete picture of the machine and GPU parameters and do not have access to the transpiled code do it each on their own. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Tue Jan 6 05:22:12 2015 From: khr...@ (Mark Callow) Date: Tue, 6 Jan 2015 22:22:12 +0900 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> Message-ID: > On Jan 6, 2015, at 10:17 PM, Florian B?sch wrote: > > On Tue, Jan 6, 2015 at 1:59 PM, Mark Callow > wrote: > This is a great idea but I suspect it will be a nightmare to implement due to lack of similar functionality in OpenGL{, ES}. > WebGL can introduce additional functionality in its specification as it partains to its specific needs. Doh! > It's preferrable browser vendors, who have full access to all machine/GPU parameters and underlying transpiled code implement consistent handling of error info logs, than that WebGL users, who only have an incomplete picture of the machine and GPU parameters and do not have access to the transpiled code do it each on their own. My point is that due to lack of specification of the message format in OpenGL the browser vendors will have to examine each implementation and write matching parsing code. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Tue Jan 6 05:25:27 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 14:25:27 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> Message-ID: On Tue, Jan 6, 2015 at 2:22 PM, Mark Callow wrote: > My point is that due to lack of specification of the message format in > OpenGL the browser vendors will have to examine each implementation and > write matching parsing code. > My point is it's preferrable that browser vendors do this, because they can do it once and they have all possible information to perform the task, whereas users would have to do it each their own, and they're not in posession of all necessary information to do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Tue Jan 6 05:30:51 2015 From: khr...@ (Mark Callow) Date: Tue, 6 Jan 2015 22:30:51 +0900 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> Message-ID: <5D2280F2-4C14-4A3E-829C-56485D5CF237@callow.im> > On Jan 6, 2015, at 10:25 PM, Florian B?sch wrote: > > On Tue, Jan 6, 2015 at 2:22 PM, Mark Callow > wrote: > My point is that due to lack of specification of the message format in OpenGL the browser vendors will have to examine each implementation and write matching parsing code. > My point is it's preferrable that browser vendors do this, because they can do it once and they have all possible information to perform the task, whereas users would have to do it each their own, and they're not in posession of all necessary information to do it. I understand that. If you recall, I wrote ?this is a great idea?. This whole exchange has been rather pointless. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Tue Jan 6 05:34:28 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 14:34:28 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: <5D2280F2-4C14-4A3E-829C-56485D5CF237@callow.im> References: <481C49E0-14BB-436A-94EC-BC94F4B665D0@callow.im> <5D2280F2-4C14-4A3E-829C-56485D5CF237@callow.im> Message-ID: On Tue, Jan 6, 2015 at 2:30 PM, Mark Callow wrote: > I understand that. If you recall, I wrote ?this is a great idea?. > I understand that you understoood. The purpose of my explanation was to make it clear that it's preferrable a job is performed well by few who can perform it, rather than by many repeatedly who lack helpful information to do it. > This whole exchange has been rather pointless. > I agree. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Tue Jan 6 10:19:38 2015 From: zmo...@ (Zhenyao Mo) Date: Tue, 6 Jan 2015 10:19:38 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: For Chrome (very likely other browsers), most error reporting are generated by browsers instead of the underlying drivers, because we translate the shader, and check many limitations before linking. For these, it's possible to format them in a certain way. However, in those errors that our pre-processing fail to catch (like instruction limit reached), it's hard to format them. Just as Mark pointed out, it's all driver specific, besides, figuring out the line number and sourceline from original shader (not the translated shader that submitted to the driver) is not a simple task. At the moment we do some post-processing to replace hashed names with original names, but that's all we do at the moment for log readability. On Tue, Jan 6, 2015 at 2:31 AM, Florian B?sch wrote: > Some of the frequent problems with properly handling shader/program info log > information is: > > How to locate the line and column number (because different > backends/browsers report it differently) > How to separate log entries (that may span multiple lines) into distinct > entries for each error reported > empty error message ("") > unusable error messages (like those linker error messages that reference > Direct3D intermediary bytecode and are piped trough straight > > I'm wondering if it would make sense to come up with some sort of formal > specification for WebGL 2.0 that ensures that: > > the returned log info is a proper structure (lists/objects) > That line and column numbers are not mangled together with the log entry > text > For convenience may include the sourceline > That ensures all reported errors are not piped trough from some backend, but > are relevant to the source passed in > > Maybe something along the lines of: > > info-log := [error, error] > error := object { > line: INT > column: INT > message: STRING > sourceline: STRING > } > > ----------------------------------------------------------- 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 Jan 6 13:02:07 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 6 Jan 2015 22:02:07 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: If I'm not mistaken Direct3D 11 introduced a bunch of new debugging facilities that should ease the process of getting usable error feedback. Since WebGL 2.0 is going (to have to be) based on Direct3D 11 (afaik), would that open some doors? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zmo...@ Tue Jan 6 13:24:30 2015 From: zmo...@ (Zhenyao Mo) Date: Tue, 6 Jan 2015 13:24:30 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: I am not familiar with such facilities. +Shannon On Tue, Jan 6, 2015 at 1:02 PM, Florian B?sch wrote: > If I'm not mistaken Direct3D 11 introduced a bunch of new debugging > facilities that should ease the process of getting usable error feedback. > Since WebGL 2.0 is going (to have to be) based on Direct3D 11 (afaik), would > that open some doors? ----------------------------------------------------------- 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 Jan 6 16:04:23 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 6 Jan 2015 16:04:23 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: It would be ideal if lines in the error messages match lines in the source, but when using a shader validator, this should generally be true. However, enforcing a strict log format doesn't seem (to me) to have a large value for something which should only be dealt with at debugging time, and seems like a ton of extra work for implementers. -Jeff On Tue, Jan 6, 2015 at 2:31 AM, Florian B?sch wrote: > Some of the frequent problems with properly handling shader/program info > log information is: > > - How to locate the line and column number (because different > backends/browsers report it differently) > - How to separate log entries (that may span multiple lines) into > distinct entries for each error reported > - empty error message ("") > - unusable error messages (like those linker error messages that > reference Direct3D intermediary bytecode and are piped trough straight > > I'm wondering if it would make sense to come up with some sort of formal > specification for WebGL 2.0 that ensures that: > > - the returned log info is a proper structure (lists/objects) > - That line and column numbers are not mangled together with the log > entry text > - For convenience may include the sourceline > - That ensures all reported errors are not piped trough from some > backend, but are relevant to the source passed in > > Maybe something along the lines of: > > info-log := [error, error] > error := object { > line: INT > column: INT > message: STRING > sourceline: STRING > } > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Jan 6 16:06:49 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 6 Jan 2015 16:06:49 -0800 Subject: [Public WebGL] Losing GL context during rAF execution? In-Reply-To: <9B4657C6-EDA5-4B38-8842-BA5C7161E077@callow.im> References: <9B4657C6-EDA5-4B38-8842-BA5C7161E077@callow.im> Message-ID: That is more generally correct, but it can happen. On Tue, Jan 6, 2015 at 4:53 AM, Mark Callow wrote: > > > On Jan 6, 2015, at 6:39 AM, Jeff Gilbert wrote: > > > > I'll explicitly add that WebGL commands can trigger context loss. > > > > I don?t think ?WebGL commands can trigger context loss? is the right > wording. ?Context loss can happen at any time during execution of WebGL > commands? is better. It is not usually the WebGL commands that trigger the > context loss. > > Regards > > -Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jan 6 22:57:51 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 7 Jan 2015 07:57:51 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Wed, Jan 7, 2015 at 1:04 AM, Jeff Gilbert wrote: > However, enforcing a strict log format doesn't seem (to me) to have a > large value for something which should only be dealt with at debugging > time, and seems like a ton of extra work for implementers. > The issue I'm describing partains to debugging, and it's a ton of work for whoever needs to do it. The reason it's important to be able to reliably figure out which line and column an error comes from, and which are separate error messages in the info log is: - In order to map line error messages to files (shaders are often pasted together from separate files by the user) - To translate the line number as reported to a line number as it partains to one of the shader source files - To shortcut requiring the user to peek at the source to figure out the error (this greatly accelerates fixing issues) For example. This is how the error arrives from chrome on linux for a shader error (one vec3 argument to a function is wrongly typed) ERROR: 0:170: 'dot' : no matching overloaded function found ERROR: 0:178: 'textureEnv' : no matching overloaded function found ERROR: 0:174: 'return' : function return is not matching type: ERROR: 0:187: 'getShading' : no matching overloaded function found ERROR: 0:188: 'getShading' : no matching overloaded function found ERROR: 0:186: '=' : cannot convert from 'const mediump float' to '3-component vector of float' I'm employing this function to translate this error: translateError: (error, lines) -> result = ['Shader Compile Error'] for line, i in error.split('\n') match = line.match /ERROR: \d+:(\d+): (.*)/ if match lineno = parseFloat(match[1])-1 message = match[2] sourceline = lines[lineno] result.push "File \"#{sourceline.filename}\", Line #{sourceline.lineno}, #{message}" result.push " #{sourceline.source}" else result.push line return result.join('\n') Which yields this log: Uncaught Shader Compile Error File "/display.shader", Line 150, 'dot' : no matching overloaded function found float incidentDot = dot(normal, -eyeDir); File "/display.shader", Line 158, 'textureEnv' : no matching overloaded function found textureEnv(env, eyeDir, normal, params.envAngle) File "/display.shader", Line 154, 'return' : function return is not matching type: return ( File "/display.shader", Line 167, 'getShading' : no matching overloaded function found getShading(shading0environ, shading0, eyeDir, normal) + File "/display.shader", Line 168, 'getShading' : no matching overloaded function found getShading(shading1environ, shading1, eyeDir, normal) File "/display.shader", Line 166, '=' : cannot convert from 'const mediump float' to '3-component vector of float' vec3 color = ( Of course this breaks down depending on the format of the error message because... different formats/backends/what have you. But it easily shows how the error messages as they come out are nearly useless (they have no other choice to be nearly useless, there's nothing wrong with that), and how to get usable error messages you *HAVE* to translate them. And since you *HAVE* to translate them, it's perfectly justified to ask for a standard for doing so, consistently, reliably and vendor independently. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jan 6 23:43:16 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 7 Jan 2015 08:43:16 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: It's worth noting that similar problems exist with JS'es error.stack, but these are discussed in the es-discuss WG/ML. This is how the error looks on: Linux Chrome/Firefox, Android Chrome Mobile, OSX Chrome/Firefox/Opera/Safari, iOS Safari, Windows Chrome/Firefox ERROR: 0:170: 'dot' : no matching overloaded function found ERROR: 0:178: 'textureEnv' : no matching overloaded function found ERROR: 0:174: 'return' : function return is not matching type: ERROR: 0:187: 'getShading' : no matching overloaded function found ERROR: 0:188: 'getShading' : no matching overloaded function found ERROR: 0:186: '=' : cannot convert from 'const mediump float' to '3-component vector of float' This is how it looks on Windows IE: (170, 29): Invalid arguments passed to function 'dot' There's already nearly a standard, except it's not spelled out, and some don't follow it. And it's perhaps a bit clumsy on style (it'd be preferable to deal with a structured format rather than a blob of text, but whatever). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Jan 7 15:50:19 2015 From: jgi...@ (Jeff Gilbert) Date: Wed, 7 Jan 2015 15:50:19 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: I am not convinced translation is necessary, or that without translation, the logs are useless. (The reason it has a de facto standard is that everyone but IE use ANGLE) Further, it's not guaranteed that all errors are caught by ANGLE. Even if we assume ANGLE is perfect, sometimes there are GL implementations that are too strict. These would generate non-standard error logs. We don't want to get involved with translating error logs. Since it seems the main benefit for devs is having the error line displayed, I recommend requesting this functionality from browser vendors. I think trying to codify a log format just so devs can write parsing translators is the wrong way to go about this. On Tue, Jan 6, 2015 at 11:43 PM, Florian B?sch wrote: > It's worth noting that similar problems exist with JS'es error.stack, but > these are discussed in the es-discuss WG/ML. > > This is how the error looks on: Linux Chrome/Firefox, Android Chrome > Mobile, OSX Chrome/Firefox/Opera/Safari, iOS Safari, Windows Chrome/Firefox > > ERROR: 0:170: 'dot' : no matching overloaded function found > ERROR: 0:178: 'textureEnv' : no matching overloaded function found > ERROR: 0:174: 'return' : function return is not matching type: > ERROR: 0:187: 'getShading' : no matching overloaded function found > ERROR: 0:188: 'getShading' : no matching overloaded function found > ERROR: 0:186: '=' : cannot convert from 'const mediump float' to > '3-component vector of float' > > This is how it looks on Windows IE: > > (170, 29): Invalid arguments passed to function 'dot' > > There's already nearly a standard, except it's not spelled out, and some > don't follow it. And it's perhaps a bit clumsy on style (it'd be preferable > to deal with a structured format rather than a blob of text, but whatever). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Wed Jan 7 23:37:02 2015 From: khr...@ (Gregg Tavares) Date: Wed, 7 Jan 2015 23:37:02 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: Referring back to the mobile limiting extension idea this again seems far better implemented as a JavaScript library. Either take ANGLE and compile it with emscripten or write a new parser. There's no reason to bloat the spec and bloat browsers with this stuff. And just like before, you can continue to add more and more features whenever you want without having to wait for 4, 5 or 6 browser teams to find the time to do it for you. You won't need to argue here about which format should be supported (text, JSON? XML?) and whether it it be internationalized or which warnings to include vs errors and which other features you want. If you want a feature add it, if you can't agree fork it. You could even easily expand that into some kind of uber shader debugger that re-wrote/re-compiled the shaders on the fly as you try to step through them. I think as a library it's a great idea but I don't see how putting this in the browser or the official spec would be anything but a giant time sink. Time that would be better spent implementing a library or shipping the next couple versions of WebGL On Wed, Jan 7, 2015 at 3:50 PM, Jeff Gilbert wrote: > I am not convinced translation is necessary, or that without translation, > the logs are useless. (The reason it has a de facto standard is that > everyone but IE use ANGLE) > > Further, it's not guaranteed that all errors are caught by ANGLE. Even if > we assume ANGLE is perfect, sometimes there are GL implementations that are > too strict. These would generate non-standard error logs. We don't want to > get involved with translating error logs. > > Since it seems the main benefit for devs is having the error line > displayed, I recommend requesting this functionality from browser vendors. > I think trying to codify a log format just so devs can write parsing > translators is the wrong way to go about this. > > On Tue, Jan 6, 2015 at 11:43 PM, Florian B?sch wrote: > >> It's worth noting that similar problems exist with JS'es error.stack, but >> these are discussed in the es-discuss WG/ML. >> >> This is how the error looks on: Linux Chrome/Firefox, Android Chrome >> Mobile, OSX Chrome/Firefox/Opera/Safari, iOS Safari, Windows Chrome/Firefox >> >> ERROR: 0:170: 'dot' : no matching overloaded function found >> ERROR: 0:178: 'textureEnv' : no matching overloaded function found >> ERROR: 0:174: 'return' : function return is not matching type: >> ERROR: 0:187: 'getShading' : no matching overloaded function found >> ERROR: 0:188: 'getShading' : no matching overloaded function found >> ERROR: 0:186: '=' : cannot convert from 'const mediump float' to >> '3-component vector of float' >> >> This is how it looks on Windows IE: >> >> (170, 29): Invalid arguments passed to function 'dot' >> >> There's already nearly a standard, except it's not spelled out, and some >> don't follow it. And it's perhaps a bit clumsy on style (it'd be preferable >> to deal with a structured format rather than a blob of text, but whatever). >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jan 7 23:37:37 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 8 Jan 2015 08:37:37 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: Let me just state by way of introduction in my usually offensively unproductive flamboyant manner: I'm really annoyed at this culture of "let's just half-arse it" To illustrate why nobody is getting around translation and why you can't sweep it under the rug as "meh", here I quote the ESSL 1.00/3.00 standard (section 3.4): #line must have, after macro substitution, one of the following two forms: #line line #line line source-string-number where line and source-string-number are constant integer expressions. The language contains a facility to provide line and file numbers (not filenames). It contains that facility in recognition that shaders are often composites of multiple files and snippets. In case we're not clear on that fact, here's some examples: - https://github.com/stackgl/glslify - http://acko.net/files/pres/siggraph-2014-bof/online.html And in case there's any lingering doubt that translation is indeed what happens a lot, here's some examples of that: - http://glslsandbox.com/ - https://www.shadertoy.com/ To wit, I'm pretty sure that most of you have translation in your own utility code, and that none of you would want to be debugging your shaders (single or multi file) based on raw error logs as they come out. On Thu, Jan 8, 2015 at 12:50 AM, Jeff Gilbert wrote: > I am not convinced translation is necessary > It is, demonstrated above. > , or that without translation, the logs are useless. > They are, demonstrated in the last message. > Further, it's not guaranteed that all errors are caught by ANGLE. Even if > we assume ANGLE is perfect, sometimes there are GL implementations that are > too strict. These would generate non-standard error logs. We don't want to > get involved with translating error logs. > That's true, see my comment about a culture of half-arsing it. > Since it seems the main benefit for devs is having the error line > displayed, I recommend requesting this functionality from browser vendors. > I think trying to codify a log format just so devs can write parsing > translators is the wrong way to go about this. > Wrong assertion for three reasons. 1. The ESSL compiler doesn't have the necessary information to produce usable error logs. Providing that information would require changing the language standard, which is something I'm pretty sure WebGL can't do. 2. Even if you had the relevant information and could produce a nice error log, that doesn't necessairly mean you'll get the same format of error log from different vendors, which is a usability impediment. 3. Even if you had consistent and readable error logs, errors aren't always displayed as a log, sometimes they're tied in with a variety of editing tools (see shadertoy, glslsandbox, vim/websocket hookups, etc.) In closing: This problem isn't going to go away. Ignoring it isn't going to solve it. Somebody has to do the hard work to make sure that error message are relevant, parsable and presentable, and the best crew to do this are browser vendors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jan 7 23:40:44 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 8 Jan 2015 08:40:44 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Thu, Jan 8, 2015 at 8:37 AM, Gregg Tavares wrote: > I think as a library it's a great idea but I don't see how putting this in > the browser or the official spec would be anything but a giant time sink. > Time that would be better spent implementing a library or shipping the next > couple versions of WebGL > Oh yeah, I'm sure that ensuring that WebGL is easily and out of the box debuggable is one of those huge timewasters, why bother eye mate? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jan 7 23:49:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 8 Jan 2015 08:49:21 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Thu, Jan 8, 2015 at 8:37 AM, Gregg Tavares wrote: > Referring back to the mobile limiting extension idea this again seems far > better implemented as a JavaScript library. Either take ANGLE and compile > it with emscripten or write a new parser. There's no reason to bloat the > spec and bloat browsers with this stuff. > > And just like before, you can continue to add more and more features > whenever you want without having to wait for 4, 5 or 6 browser teams to > find the time to do it for you. You won't need to argue here about which > format should be supported (text, JSON? XML?) and whether it it be > internationalized or which warnings to include vs errors and which other > features you want. If you want a feature add it, if you can't agree fork it. > > You could even easily expand that into some kind of uber shader debugger > that re-wrote/re-compiled the shaders on the fly as you try to step through > them. > The ESSL language specification already specifies delivery by the programmer of file and line numbers. It's only reasonable to ask that there be a facility to reliably retrieve those numbers again. See: half-arsing it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jan 8 00:11:53 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 8 Jan 2015 09:11:53 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: Up-specced, enjoy: https://www.khronos.org/bugzilla/show_bug.cgi?id=1284 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jan 8 01:03:58 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 8 Jan 2015 10:03:58 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: Suggesting to change the 6th paragraph in section 6.1 of the OpenGL ES specification: "The info log is typically only useful during application development and an application should not expect different GL implementations to produce identical info logs." With: "The info log is typically only useful during application development an application can expect it to be formatted according to error info log grammar in appendix E" Appendix E Error info log grammar. The error info logs retrieved from getShaderInfoLog(COMPILE_STATUS) and getProgramInfoLog(LINK_STATUS) have to conform to the following grammar: ::= ::= { } ::= | ::= "SOURCE-" ": File: " " Line: " ": " "\n" ::= ": " "\n" ::= "ERROR" | "WARNING" ::= ::= ::= ::= { } ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | ! | " | # | $ | % | & | ' | ( | ) | * | + | , | - | . | / | : | ; | < | = | > | ? | @ | [ | \ | ] | ^ | _ | ` | { | "|" | } | ~ | " " | \t ::= { } ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Jan 8 15:45:00 2015 From: jgi...@ (Jeff Gilbert) Date: Thu, 8 Jan 2015 15:45:00 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: I (at least) debug my shaders with the logs spewed from GL. Can you do cool things like highlighting if there were a standard format? Yes. Is it required to debug shaders? No. The specs say a lot of things. Implementations do a lot of things. Unfortunately, neither is a subset of the other. A good portion of my time goes to dealing with bad behavior from non-spec-compliant implementations. I'm not excited to invest even more time in this just so that error messages are prettier. (They seem sufficiently functional at present to me) If it's so easy to do, why not have a library which does it. That would at least halve the development time required. Submit bugs to browsers if they emit error logs that don't match the GLES spec. What you call 'half-arsing', we call 'resource prioritization'. Let's talk about making logs pretty after we have conformant WebGL 2 implementations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Jan 8 22:39:52 2015 From: khr...@ (Gregg Tavares) Date: Thu, 8 Jan 2015 22:39:52 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Wed, Jan 7, 2015 at 11:40 PM, Florian B?sch wrote: > On Thu, Jan 8, 2015 at 8:37 AM, Gregg Tavares > wrote: > >> I think as a library it's a great idea but I don't see how putting this >> in the browser or the official spec would be anything but a giant time >> sink. Time that would be better spent implementing a library or shipping >> the next couple versions of WebGL >> > > Oh yeah, I'm sure that ensuring that WebGL is easily and out of the box > debuggable is one of those huge timewasters, why bother eye mate? > Nice snarky comment. I thought you were smarter than that. So some how this magically gets implemented in zero time by 5+ browser teams and that all the debate over what goes in it and what doesn't is handled in magic free time people get back from the time fairy? Or you know, all that wasted time could be spent actually implementing this is JS and like magic, so much less time wasted. Oh and WebGL gets more debuggable. Hey what? Oh, right, you wanted WebGL debuggable. Guess I better switch to that other plan where it takes 30x more man hours, doesn't ship for 12-18 months, can't be updated without a lengthy process and more wasted time. That will make WebGL more debuggable. Uh-huh, yep. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Jan 8 22:58:56 2015 From: khr...@ (Gregg Tavares) Date: Thu, 8 Jan 2015 22:58:56 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: And now the more diplomatic version of that reply ;-D We're on the same page. We agree having features that make WebGL more debuggable is great. We just disagree on the best road to get there. I thought my suggestion was actually getting WebGL debuggable faster with far less work and far more flexibility. 5+ browser teams don't need to implement it only 1 team that that 1 team doesn't have to be anyone from a browser team who's currently trying to ship WebGL 2.0 but instead will have to add this to their stuff of stuff to do before it can ship. No arguing what the format should be or what features or which error has to be caught first or how many errors are required to be reported per complication or if there should be warnings for undefined behavior or unused variables or code or etc etc etc... And, you can have it probably in a week or two if someone set out to write it whereas if you go the spec route you probably won't get it for 12-18 months. Can you imagine how long it would have been for WebGL debugging tools if instead of Ben Vanik just making one , he instead came here and demanded we make an official spec for one and then waited for some browser team to implement it? BTW: you probably know this but GL doesn't require error messages period. Nor does it require any errors at compile time. On Wed, Jan 7, 2015 at 11:40 PM, Florian B?sch wrote: > On Thu, Jan 8, 2015 at 8:37 AM, Gregg Tavares > wrote: > >> I think as a library it's a great idea but I don't see how putting this >> in the browser or the official spec would be anything but a giant time >> sink. Time that would be better spent implementing a library or shipping >> the next couple versions of WebGL >> > > Oh yeah, I'm sure that ensuring that WebGL is easily and out of the box > debuggable is one of those huge timewasters, why bother eye mate? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jan 8 23:01:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 08:01:33 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 12:45 AM, Jeff Gilbert wrote: > I (at least) debug my shaders with the logs spewed from GL. > Which means that the shaders that you write are single file per stage without any automatic modification (such as including boilerplate and utilities), inclusion of other files, require system, composition or other transformations. This isn't actually how most WebGL shaders are written. I'm sure you realize this. Have you reviewed sketchfabs WebGL Insights chapter? Did you look at glslify? Mathbox? Did you look into the crop of popular frameworks around WebGL? > Is it required to debug shaders? No. > It's absolutely required because beyond "hello world" usage, line numbers shift, and file numbers start meaning something. File numbers are a ESSL language feature you know? I've shown that, I've quoted the section. Did you see that? Did you realize that nobody in his right mind maps file-numbers to file names/paths in their heads? That nobody adjusts for line-shift due to composition in their head? Isn't that quite obvious and straightforward to understand? What's exactly unclear about this? Didn't I just provide plenty of examples and reasoning why that is so? Why do you keep rejecting an obviously unrejectable argument? Why do I even have to point this out to you? It's exceedingly obvious. > The specs say a lot of things. Implementations do a lot of things. > Unfortunately, neither is a subset of the other. A good portion of my time > goes to dealing with bad behavior from non-spec-compliant implementations. > I'm not excited to invest even more time in this just so that error > messages are prettier. (They seem sufficiently functional at present to me) > They're functional because, as you've stated, that most errors are generated by the Angle validator, and most vendors use Angle, and so the format is semi-standard. It's only a semi-standard, because sometimes garbage does get piped trough from the underlying backend, and at least one vendor, who isn't using Angle, isn't implementing that format. You're lulled into a false complacency to think things are ok, because they seem to work alright (did I mention I didn't like this kind of half-arsing, I mentioned that, didn't I? I'm pretty sure I did.). I'm not saying this isn't going away because I won't shup about it, no, sooner or later even I will get tired of pointing the bleedingly obvious. No, this problem isn't going to go away, because the future holds more variety of WebGL implementations, and possibly more errors that need to get piped trough from the backend as language features expand and you can produce errors for source that's syntactically correct, but cannot be compiled or linked regardless. > If it's so easy to do, why not have a library which does it. That would at > least halve the development time required. Submit bugs to browsers if they > emit error logs that don't match the GLES spec. > The GLES spec doesn't have a specification of the errors yet. I fooolishly thought it'd be easier to find UA vendor consensus on an obvious API intended for both human and machine consumption before I'd have to attempt to force UA vendors to conform to the ES spec by changing the ES spec. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jan 8 23:13:02 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 08:13:02 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: We don't agree at all. I've got nothing "against" using whatever duct-tape and chickenwire is required to gap this problem, that's what I, and everybody else, is doing anyway. That's not a suggestion of how to solve this issue, this is a description of the status quo. That's what we do. I didn't come here to talk about chickenwire and duct-tape. Not at all. What I point is that there is half a specification, this half specification, specifies delivery of line-numbers and file-numbers to the ESSL compiler (the #line directive). What I also point is that, this feature is specifically intended to ease debugging of shaders, that's how it's used by everybody. And finally, I point out how the return values of that API, which is both in theory and practice intended for machine consumption, is not standardized. And so conclude how this lack of agreement of the format is already an annoyance (because one vendor doesn't agree on the format and you've got to add some duct-tape and chickenwire to make it work), but that worse than that sometimes you get back completely unusable error message (which should obviously be fixed) and how both of these problems will not get any better in the future if there isn't a consensus reached. And the consensus is very simple: Error info log messages are part of the API, intended for machine consumption. This isn't a difficult realization to agree on, at all. It doesn't require 50+ messages. It's exceedingly obvious to anybody. And it's a complete mystery to me why I even have to talk about it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Jan 8 23:25:56 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 08:25:56 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: To make it clear how silly this debate is. Substitue GLSL for say, gcc, llvm, python, lua, Java, gdb or any other even moderatly popular system of programming/compiling/debugging things. All of the former (and most of the ones implied) have a structured way to communicate errors so they're fit for machine consumption. The only place I've seen the untenable position of not having a structured way to do it being discussed in earnest, is here and in ES-discuss (on JS stack traces). I cannot believe it honestly. You understand how this is a mystery to me right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Thu Jan 8 23:38:36 2015 From: khr...@ (Gregg Tavares) Date: Thu, 8 Jan 2015 23:38:36 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Thu, Jan 8, 2015 at 11:25 PM, Florian B?sch wrote: > To make it clear how silly this debate is. Substitue GLSL for say, gcc, > llvm, python, lua, Java, gdb or any other even moderatly popular system of > programming/compiling/debugging things. All of the former (and most of the > ones implied) have a structured way to communicate errors so they're fit > for machine consumption. > They do? I thought VC++, g++, clang and every other C++ compiler generate different errors in different formats. There's no spec for the errors nor is there a spec for the error format (or was it added?). I thought all there is is a language spec that says what must compile and what must fail. Exactly the same situation for GLSL. > > The only place I've seen the untenable position of not having a structured > way to do it being discussed in earnest, is here and in ES-discuss (on JS > stack traces). I cannot believe it honestly. You understand how this is a > mystery to me right? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Fri Jan 9 00:05:25 2015 From: khr...@ (Gregg Tavares) Date: Fri, 9 Jan 2015 00:05:25 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Thu, Jan 8, 2015 at 11:13 PM, Florian B?sch wrote: > We don't agree at all. I've got nothing "against" using whatever duct-tape > and chickenwire is required to gap this problem, that's what I, and > everybody else, is doing anyway. That's not a suggestion of how to solve > this issue, this is a description of the status quo. That's what we do. I > didn't come here to talk about chickenwire and duct-tape. Not at all. > I don't know if you were suggesting my solution was "duct-tape and chickenwire". If you were I don't see it that way. I see my solution as vastly superior for all the reasons stated. To reiterate *) less man work *) covers more browsers *) requires no debate on specs or features *) doesn't add to the already full plates of browser teams *) can be expanded without more debate and specing *) is more flexible *) will be available sooner *) bugs can be fixed immediately without waiting for some browser team to find time to fix them *) bug fixes available immediately, no waiting several months for a them to bubble through browser release cycles. > Error info log messages are part of the API, intended for machine consumption. No they aren't. Error Info Log messages are speced such that they can always be empty. It is purely up to the driver implementor if they want to return anything there or not. The only error related to GLSL that's required is that bad shaders return false for gl.LINK_STATUS at LINK time. They are free to return success even on bad shaders at COMPILE time. Everything else is optional. I know this because I had to fix all the webgl conformance tests that used to require failure at compile time. > > What I point is that there is half a specification, this half > specification, specifies delivery of line-numbers and file-numbers to the > ESSL compiler (the #line directive). What I also point is that, this > feature is specifically intended to ease debugging of shaders, that's how > it's used by everybody. And finally, I point out how the return values of > that API, which is both in theory and practice intended for machine > consumption, is not standardized. And so conclude how this lack of > agreement of the format is already an annoyance (because one vendor doesn't > agree on the format and you've got to add some duct-tape and chickenwire to > make it work), but that worse than that sometimes you get back completely > unusable error message (which should obviously be fixed) and how both of > these problems will not get any better in the future if there isn't a > consensus reached. And the consensus is very simple: > > Error info log messages are part of the API, intended for machine > consumption. > > > This isn't a difficult realization to agree on, at all. It doesn't require > 50+ messages. It's exceedingly obvious to anybody. And it's a complete > mystery to me why I even have to talk about it. > I think you're underestimating the amount of work. Let's assume it's just Chrome (since that's what I know) It's not just formatting messages in ANGLE. ANGLE isn't guaranteed to catch every error the driver might issue. For example ANGLE might let through a complex shader the driver rejects for some reason. Or, the driver might generate warnings (as some do). So now this problem has turned into somehow keeping a database of the all the drivers out there and what to do when they emit a message so it can then translate it back into this format. That's also assuming that format is consistent even inside a single driver. I have no way to know how to generate every possible message a driver might issue so I can check. Then they need to check every time a new driver comes out that someone didn't change something. Updating the ES spec won't help old drivers or non ES drivers. Then there's buggy drivers. Do they then blacklist any driver that spits out a message that doesn't parse by whatever rules were written previously? Because otherwise if they let any bad messages through someone's spec compliant parsing code will fail and their webpage will stop working. Updating the ES spec also doesn't help with DirectX -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 9 00:17:11 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 09:17:11 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 8:38 AM, Gregg Tavares wrote: > They do? I thought VC++, g++, clang and every other C++ compiler generate > different errors in different formats. There's no spec for the errors nor > is there a spec for the error format (or was it added?). I thought all > there is is a language spec that says what must compile and what must fail. > Exactly the same situation for GLSL. > There's 3 major differences to WebGL which makes the debate about a standard format matter: - WebGL doesn't have a format, not even for one vendor. Sure, there's an informal "standard", which works most of the time, except when it doesn't, but even the vendors who use have zero commitment to keep it that way. - VC++, g++, clang etc. don't have an API standard. They have a language standard, but not an API standard. WebGL has an API standard. - WebGL being on the Web (that's the Web part, in case you didn't notice), is exposed to the need to do things in a cross vendor compatible fashion a lot more than it's cruically important that say your Suse C++ IDE also supports VC++'es error format. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 9 00:27:57 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 09:27:57 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 9:05 AM, Gregg Tavares wrote: > I don't know if you were suggesting my solution was "duct-tape and > chickenwire". If you were I don't see it that way. I see my solution as > vastly superior for all the reasons stated. > By that logic, it's futile to have a standard, about anything, in the first place, let's just half-arse-wing it and throw duct-tape and chickenwire at everything. Heck, why have conformance test? That's circularly self referencing nonsense. > To reiterate > > *) less man work > *) covers more browsers > *) requires no debate on specs or features > *) doesn't add to the already full plates of browser teams > *) can be expanded without more debate and specing > *) is more flexible > *) will be available sooner > *) bugs can be fixed immediately without waiting for some browser team to > find time to fix them > *) bug fixes available immediately, no waiting several months for a them > to bubble through browser release cycles. > That's not what it's about, so that's completely irrelevant. > > Error info log messages are part of the API, intended for machine > consumption. > > No they aren't. Error Info Log messages are speced such that they can > always be empty. It is purely up to the driver implementor if they want to > return anything there or not. The only error related to GLSL that's > required is that bad shaders return false for gl.LINK_STATUS at LINK time. > They are free to return success even on bad shaders at COMPILE time. > Everything else is optional. I know this because I had to fix all the webgl > conformance tests that used to require failure at compile time. > I didn't say that was how it is. I said, that is what the consensus should be. I said it, I know, I just wrote it in the message before, which, you probably didn't read. I think you're underestimating the amount of work. Let's assume it's just > Chrome (since that's what I know) It's not just formatting messages in > ANGLE. ANGLE isn't guaranteed to catch every error the driver might issue. > For example ANGLE might let through a complex shader the driver rejects for > some reason. Or, the driver might generate warnings (as some do). So now > this problem has turned into somehow keeping a database of the all the > drivers out there and what to do when they emit a message so it can then > translate it back into this format. That's also assuming that format is > consistent even inside a single driver. I have no way to know how to > generate every possible message a driver might issue so I can check. Then > they need to check every time a new driver comes out that someone didn't > change something. Updating the ES spec won't help old drivers or non ES > drivers. Then there's buggy drivers. Do they then blacklist any driver that > spits out a message that doesn't parse by whatever rules were written > previously? Because otherwise if they let any bad messages through > someone's spec compliant parsing code will fail and their webpage will stop > working. Updating the ES spec also doesn't help with DirectX > I'm neither over nor underestimating the problem. In fact, I refuse to estimate, this isn't about estimation. This is also not about how difficult or easy it is, or soon or late it'll get done, those are all completely utterly irrelevant. What you're essentially advocating is this: "This seems complex, I don't wanna do it, I know all our users would be happy if we did it, but I say, we'll have-arse it one more time." This might ok if you're selling a product, or service, or work at a company anywhere and you have a looming deadline, or whatever. This isn't appropriate if you're talking about a standard. You should never shrink from the responsibility of solving an issue just because it's inconvenient to do so. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Fri Jan 9 00:48:17 2015 From: khr...@ (Gregg Tavares) Date: Fri, 9 Jan 2015 00:48:17 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 12:27 AM, Florian B?sch wrote: > On Fri, Jan 9, 2015 at 9:05 AM, Gregg Tavares > wrote: > >> I don't know if you were suggesting my solution was "duct-tape and >> chickenwire". If you were I don't see it that way. I see my solution as >> vastly superior for all the reasons stated. >> > By that logic, it's futile to have a standard, about anything, in the > first place, let's just half-arse-wing it and throw duct-tape and > chickenwire at everything. Heck, why have conformance test? That's > circularly self referencing nonsense. > > >> To reiterate >> >> *) less man work >> *) covers more browsers >> *) requires no debate on specs or features >> *) doesn't add to the already full plates of browser teams >> *) can be expanded without more debate and specing >> *) is more flexible >> *) will be available sooner >> *) bugs can be fixed immediately without waiting for some browser team to >> find time to fix them >> *) bug fixes available immediately, no waiting several months for a them >> to bubble through browser release cycles. >> > That's not what it's about, so that's completely irrelevant. > > >> > Error info log messages are part of the API, intended for machine >> consumption. >> >> No they aren't. Error Info Log messages are speced such that they can >> always be empty. It is purely up to the driver implementor if they want to >> return anything there or not. The only error related to GLSL that's >> required is that bad shaders return false for gl.LINK_STATUS at LINK time. >> They are free to return success even on bad shaders at COMPILE time. >> Everything else is optional. I know this because I had to fix all the webgl >> conformance tests that used to require failure at compile time. >> > > I didn't say that was how it is. I said, that is what the consensus should > be. I said it, I know, I just wrote it in the message before, which, you > probably didn't read. > > I think you're underestimating the amount of work. Let's assume it's just >> Chrome (since that's what I know) It's not just formatting messages in >> ANGLE. ANGLE isn't guaranteed to catch every error the driver might issue. >> For example ANGLE might let through a complex shader the driver rejects for >> some reason. Or, the driver might generate warnings (as some do). So now >> this problem has turned into somehow keeping a database of the all the >> drivers out there and what to do when they emit a message so it can then >> translate it back into this format. That's also assuming that format is >> consistent even inside a single driver. I have no way to know how to >> generate every possible message a driver might issue so I can check. Then >> they need to check every time a new driver comes out that someone didn't >> change something. Updating the ES spec won't help old drivers or non ES >> drivers. Then there's buggy drivers. Do they then blacklist any driver that >> spits out a message that doesn't parse by whatever rules were written >> previously? Because otherwise if they let any bad messages through >> someone's spec compliant parsing code will fail and their webpage will stop >> working. Updating the ES spec also doesn't help with DirectX >> > I'm neither over nor underestimating the problem. In fact, I refuse to > estimate, this isn't about estimation. This is also not about how difficult > or easy it is, or soon or late it'll get done, those are all completely > utterly irrelevant. > They're completely relevant. There's a finite amount of resources. You have to decide where to spend them. GL hasn't had a standard for error messages for 22 years yet somehow it's doing just fine so this certainly doesn't seem like a priority for resources. Epic, Id, Crtek, Autodesk, etc haven't been clamoring for this feature in OpenGL so why is it needed in WebGL? > > What you're essentially advocating is this: "This seems complex, I don't > wanna do it, I know all our users would be happy if we did it, but I say, > we'll have-arse it one more time." > I don't know our users would be happy if we did it. Going off stackoverflow I suspect most of them would never know anything existed because most of them can't even be bothered open the JavaScript console and see if an error was even printed. It's highly unlikely they're going to write error parsers. And again, YOU'RE THE ONE HALF-ASSiNG IT! You're asking for 13+ teams to waste time on this when you could probably solve your specific issue with 5 lines of JS regexes Great way to spend resources dude! > > This might ok if you're selling a product, or service, or work at a > company anywhere and you have a looming deadline, or whatever. This isn't > appropriate if you're talking about a standard. You should never shrink > from the responsibility of solving an issue just because it's inconvenient > to do so. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 9 00:56:31 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 09:56:31 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 9:48 AM, Gregg Tavares wrote: > They're completely relevant. There's a finite amount of resources. You > have to decide where to spend them. GL hasn't had a standard for error > messages for 22 years yet somehow it's doing just fine so this certainly > doesn't seem like a priority for resources. > The modern use of shaders was intially conceived by Pixar in Renderman in 1988. But in actual use they only made their way to standards in 2004, so 10 years ago, and their use and sophistication has been on the rise ever since. > Epic, Id, Crtek, Autodesk, etc haven't been clamoring for this feature in > OpenGL so why is it needed in WebGL? > Have you asked them if they'd wanted a standard error feature? I haven't, but I'm pretty sure that if you asked, they'd say yes. > I don't know our users would be happy if we did it. Going off > stackoverflow I suspect most of them would never know anything existed > because most of them can't even be bothered open the JavaScript console and > see if an error was even printed. It's highly unlikely they're going to > write error parsers. > Ah a classic. Our users are dumb, what does it matter? > And again, YOU'RE THE ONE HALF-ASSiNG IT! You're asking for 13+ teams to > waste time on this when you could probably solve your specific issue with 5 > lines of JS regexes > Ah another classic, why waste time defining something that should obviously defined when it'd be so much easier to accuse the messenger of being the source of the problem. See that's why I get tired of pointing out the bleedingly obvious quite often. You can't make people understand the obvious. It's a bloddy pain in the arse. > Great way to spend resources dude! > You're aware aren't you that we're talking about a standard right? Last I looked Googles HR-department didn't sit on the standards board or do they? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 9 03:46:10 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 12:46:10 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: I would please ask that we not have arguments where I consistently reason with logic and facts and have to re-iterate a single obvious point again and again. I'm using WebGL every day of my life, for a living, for the last couple of years. I come here because I have real world concerns, affecting my real world life, serving real world customers, which I make in the real world with using what this standard group cobbles together. Maybe not everything is a world-changing problem like mythical WebGL 2 or how to get enough resources to do everything you should (HR-miracles, or something). But that doesn't mean they're not problems. Every single person I've asked about this agrees that a standard format is a good idea. So please, with sugar on top, stop arguing with nonsense against something we all agree is a good idea. Since we all agree it's a good idea, we can instead do something productive like discussing how to do it best so that it gets done eventually. And the one single I never ever want to hear ever again, ever, ever, is how you should concentrate on different things because something you agree is a good idea would distract from something more important. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 9 03:59:46 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 12:59:46 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Fri, Jan 9, 2015 at 12:46 PM, Florian B?sch wrote: > And the one single I never ever want to hear ever again, ever, ever, is > how you should concentrate on different things because something you agree > is a good idea would distract from something more important. > You're all capable of prioritization. I'm not asking anybody to change their priorities. WebGL is a collaboration between many companies and individuals, it's not a single thread process. Whatever comes up, at any time, it's understood that it may not be the most important thing, or might not get bumped to the front of anybodies priority queue right away, or maybe ever. That should not stop us from trying to define the future, and addressing problems, major or minor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 9 04:41:19 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 9 Jan 2015 13:41:19 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: Maybe this is a better idea than the grammar idea, I don't know. http://codeflow.org/specs/OES_structured_info_log.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jan 10 00:11:55 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 10 Jan 2015 09:11:55 +0100 Subject: [Public WebGL] lone platforms without any webgl implementation Message-ID: WebGL has made great strides in the last 2 years and reached every major platform. It is now available on all desktop platforms and all mobile platforms, and it's on track to comprehensive activation coverage in the next 2 years. It is even found on some mobile gaming devices like the Nvidia shield devices. Sadly there are platforms that run modern browsers but do not have any WebGL support yet: - Xbox One - Playstation 4 - Wii - Windows smart TVs Speaking from personal experience with the Playstation 4, a lack of WebGL isn't the only problem this platform has for the web, it has a number of other deficiencies such as: - No Web Audio Data API implementation - No Gamepad API support - No Fullscreen API support - Slow JS execution speeds (scores badly on benchmarks) It's clear that the allure of the web has forced every internet connected device to offer better browser support, and in defense it has to be said that the browsers on these devices have made great progress from their previous versions. But at the same time it has to be said that these devices are still way behind the capabilities of other platforms. I would like to see this gap close, and I'd encourage the responsible parties to work towards that goal harder. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Mon Jan 12 15:45:31 2015 From: jgi...@ (Jeff Gilbert) Date: Mon, 12 Jan 2015 15:45:31 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Thu, Jan 8, 2015 at 11:01 PM, Florian B?sch wrote: > On Fri, Jan 9, 2015 at 12:45 AM, Jeff Gilbert > wrote: > >> I (at least) debug my shaders with the logs spewed from GL. >> > Which means that the shaders that you write are single file per stage > without any automatic modification (such as including boilerplate and > utilities), inclusion of other files, require system, composition or other > transformations. This isn't actually how most WebGL shaders are written. > I'm sure you realize this. Have you reviewed sketchfabs WebGL Insights > chapter? Did you look at glslify? Mathbox? Did you look into the crop of > popular frameworks around WebGL? > gl.getShaderSource() > Is it required to debug shaders? No. >> > It's absolutely required because beyond "hello world" usage, line numbers > shift, and file numbers start meaning something. File numbers are a ESSL > language feature you know? I've shown that, I've quoted the section. Did > you see that? Did you realize that nobody in his right mind maps > file-numbers to file names/paths in their heads? That nobody adjusts for > line-shift due to composition in their head? Isn't that quite obvious and > straightforward to understand? What's exactly unclear about this? Didn't I > just provide plenty of examples and reasoning why that is so? Why do you > keep rejecting an obviously unrejectable argument? Why do I even have to > point this out to you? It's exceedingly obvious. > gl.getShaderSource() + JS helpers. Would it be nicer if this were fully-automated? Yes. I don't think it's critical to fix right now though. > > >> The specs say a lot of things. Implementations do a lot of things. >> Unfortunately, neither is a subset of the other. A good portion of my time >> goes to dealing with bad behavior from non-spec-compliant implementations. >> I'm not excited to invest even more time in this just so that error >> messages are prettier. (They seem sufficiently functional at present to me) >> > They're functional because, as you've stated, that most errors are > generated by the Angle validator, and most vendors use Angle, and so the > format is semi-standard. It's only a semi-standard, because sometimes > garbage does get piped trough from the underlying backend, and at least one > vendor, who isn't using Angle, isn't implementing that format. You're > lulled into a false complacency to think things are ok, because they seem > to work alright (did I mention I didn't like this kind of half-arsing, I > mentioned that, didn't I? I'm pretty sure I did.). I'm not saying this > isn't going away because I won't shup about it, no, sooner or later even I > will get tired of pointing the bleedingly obvious. No, this problem isn't > going to go away, because the future holds more variety of WebGL > implementations, and possibly more errors that need to get piped trough > from the backend as language features expand and you can produce errors for > source that's syntactically correct, but cannot be compiled or linked > regardless. > We should avoid standardizing with the assumption that ANGLE will always be used. It's already not used in IE. If you want standardized error messages, and don't use something like ANGLE, there's a bunch of work needed to parse error messages from different drivers, not just different vendors. > > >> If it's so easy to do, why not have a library which does it. That would >> at least halve the development time required. Submit bugs to browsers if >> they emit error logs that don't match the GLES spec. >> > The GLES spec doesn't have a specification of the errors yet. I fooolishly > thought it'd be easier to find UA vendor consensus on an obvious API > intended for both human and machine consumption before I'd have to attempt > to force UA vendors to conform to the ES spec by changing the ES spec. > If errors aren't specified, I really really don't want to commit to a universal error format right now, given finite resources. It's a nice thought, but it's too low in terms of ROI compared to other things we're working on right now. It takes time just to standardize things, not to mention the long tail of driver-specific log parsers this might eventually entail. Phrased as an optional extension, it's more viable. We could simply choose to stop offering it if we need to change something, or are on a configuration where we don't generate errors ourselves. However, the more time we spend on this low-ROI work item now, the longer WebGL 2 is going to take. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 12 21:14:37 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 13 Jan 2015 06:14:37 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Tue, Jan 13, 2015 at 12:45 AM, Jeff Gilbert wrote: > gl.getShaderSource() > That doesn't help you to locate the line-number and file-number in the error message so you can map it to one of your source lines and source files. gl.getShaderSource() + JS helpers. Would it be nicer if this were > fully-automated? Yes. > Ding-ding-ding. > I don't think it's critical to fix right now though. > Who said it was? I'd like to see this fixed eventually, and I do think the pain of this point is going to increase in the future, so the longer you defer solving that problem, the more often this debate will come up. > If errors aren't specified, I really really don't want to commit to a > universal error format right now, given finite resources. > > It's a nice thought, but it's too low in terms of ROI compared to other > things we're working on right now. It takes time just to standardize > things, not to mention the long tail of driver-specific log parsers this > might eventually entail. > > Phrased as an optional extension, it's more viable. We could simply choose > to stop offering it if we need to change something, or are on a > configuration where we don't generate errors ourselves. > > However, the more time we spend on this low-ROI work item now, the longer > WebGL 2 is going to take. > I told you that I don't want to hear this "argument" ever again. I told you this for a specific reason, maybe I haven't made that reason perfectly clear, so let me help you there. There isn't a scenario in which I'm the intended recipient of an "argument"/message that says "We don't have time for it right now, and it would delay other things." Such a scenario doesn't exist because: - Do you have trouble managing your time, keeping track of tasks and prioritizing your activity? I suggest you take that up with your team-lead and/or project manager. These folks can help you understanding work practices, tools to manage your tasks and will aide you in assigning a priority to work items. - Do you have too few human resources to do the things you need to do? I suggest you take that up with your HR department and have them bring you candidates for positions that are clearly vacant. - Do you have too little money to acquire the human resources? I suggest you take that up with corporate finance. - Do you have trouble assigning the human resources you have on the work items in your queue because your code doesn't physically allow multiple people to pursue multiple tasks? I suggest you take that up with your software-architect, clear that's a problem with your codebase. So you see how in no possible scenario is this an "argument" that you'll want to write to me right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Jan 13 17:34:42 2015 From: jgi...@ (Jeff Gilbert) Date: Tue, 13 Jan 2015 17:34:42 -0800 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: I'm sure we'll discuss this on the working group call next week. -Jeff On Mon, Jan 12, 2015 at 9:14 PM, Florian B?sch wrote: > On Tue, Jan 13, 2015 at 12:45 AM, Jeff Gilbert > wrote: > >> gl.getShaderSource() >> > That doesn't help you to locate the line-number and file-number in the > error message so you can map it to one of your source lines and source > files. > > gl.getShaderSource() + JS helpers. Would it be nicer if this were >> fully-automated? Yes. >> > Ding-ding-ding. > > >> I don't think it's critical to fix right now though. >> > Who said it was? I'd like to see this fixed eventually, and I do think the > pain of this point is going to increase in the future, so the longer you > defer solving that problem, the more often this debate will come up. > > >> If errors aren't specified, I really really don't want to commit to a >> universal error format right now, given finite resources. >> >> It's a nice thought, but it's too low in terms of ROI compared to other >> things we're working on right now. It takes time just to standardize >> things, not to mention the long tail of driver-specific log parsers this >> might eventually entail. >> >> Phrased as an optional extension, it's more viable. We could simply >> choose to stop offering it if we need to change something, or are on a >> configuration where we don't generate errors ourselves. >> >> However, the more time we spend on this low-ROI work item now, the longer >> WebGL 2 is going to take. >> > I told you that I don't want to hear this "argument" ever again. I told > you this for a specific reason, maybe I haven't made that reason perfectly > clear, so let me help you there. > > There isn't a scenario in which I'm the intended recipient of an > "argument"/message that says "We don't have time for it right now, and it > would delay other things." Such a scenario doesn't exist because: > > - Do you have trouble managing your time, keeping track of tasks and > prioritizing your activity? I suggest you take that up with your team-lead > and/or project manager. These folks can help you understanding work > practices, tools to manage your tasks and will aide you in assigning a > priority to work items. > - Do you have too few human resources to do the things you need to do? > I suggest you take that up with your HR department and have them bring you > candidates for positions that are clearly vacant. > - Do you have too little money to acquire the human resources? I > suggest you take that up with corporate finance. > - Do you have trouble assigning the human resources you have on the > work items in your queue because your code doesn't physically allow > multiple people to pursue multiple tasks? I suggest you take that up with > your software-architect, clear that's a problem with your codebase. > > So you see how in no possible scenario is this an "argument" that you'll > want to write to me right? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jan 13 21:01:24 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 14 Jan 2015 06:01:24 +0100 Subject: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification In-Reply-To: References: Message-ID: On Wed, Jan 14, 2015 at 2:34 AM, Jeff Gilbert wrote: > I'm sure we'll discuss this on the working group call next week. > Timing/priority information like that is a perfectly valid response and it's nice to know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jan 14 00:42:17 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 14 Jan 2015 09:42:17 +0100 Subject: [Public WebGL] extensions status Message-ID: I've gone over the implementation status of extensions and would like to comment on some cases. EXT_color_buffer_half_float and WEBGL_color_buffer_float which are in community approved status have dropped off the map (implementations have vanished). This is sort of a problem and I'd like to know if: - Is there any intent to implement those? - If not, should (can) it be dropped from the registry? EXT_color_buffer_float (draft) hasn't been implemented. - Is there intent to implement it? - If not, should we drop it from the registry? WEBGL_compressed_texture_es3 (proposal) - Is this specification finalized? - If so, is there intent to implement it? - If so, should it be moved to draft? WEBGL_dynamic_texture (proposal) - Is this specification finalized? - If so, is there intent to implement it? - If so, should it be moved to draft? WEBGL_draw_elements_no_range_check (proposal) - Is this specification finalized? - If so, is there intent to implement it? - If so, should it be moved to draft? EXT_disjoint_timer_query (draft) - Is there intent to implement it? - If not, should it be dropped from the registry? WEBGL_shared_resources (draft) - Is there intent to implement it? - If not, should it be dropped from the registry? WEBGL_security_sensitive_resources (draft) - Is there intent to implement it? - If not, should it be dropped from the registry? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oet...@ Wed Jan 14 02:23:45 2015 From: oet...@ (Olli Etuaho) Date: Wed, 14 Jan 2015 10:23:45 +0000 Subject: [Public WebGL] extensions status In-Reply-To: References: Message-ID: I think I can answer a few of these: WEBGL_draw_elements_no_range_check - dropped as an extension. This functionality would be better to implement just as a part of WebGL 2 at this point, if it is decided that the tradeoffs offered here are good. EXT_color_buffer_float - this is a WebGL 2 extension, so it's quite natural it hasn't yet been implemented. I'm sure it will move forward once basic WebGL 2 support is in place. WEBGL_security_sensitive_resources - This is a very ambitious extension. While the functionality is desirable, it's hard to implement and could hurt performance in a major way in some cases. For example delta color compression in NVIDIA GPUs would likely have to be disabled due to the timing requirements. So I don't honestly see this being worth the effort, though maybe others disagree. I recall that the process has still been that proposals are kept in the registry even if they are rejected, in order to keep a history of what has been proposed. -Olli ________________________________ From: owners-public_webgl...@ on behalf of Florian B?sch Sent: Wednesday, January 14, 2015 10:42 AM To: public webgl Subject: [Public WebGL] extensions status I've gone over the implementation status of extensions and would like to comment on some cases. EXT_color_buffer_half_float and WEBGL_color_buffer_float which are in community approved status have dropped off the map (implementations have vanished). This is sort of a problem and I'd like to know if: * Is there any intent to implement those? * If not, should (can) it be dropped from the registry? EXT_color_buffer_float (draft) hasn't been implemented. * Is there intent to implement it? * If not, should we drop it from the registry? WEBGL_compressed_texture_es3 (proposal) * Is this specification finalized? * If so, is there intent to implement it? * If so, should it be moved to draft? WEBGL_dynamic_texture (proposal) * Is this specification finalized? * If so, is there intent to implement it? * If so, should it be moved to draft? WEBGL_draw_elements_no_range_check (proposal) * Is this specification finalized? * If so, is there intent to implement it? * If so, should it be moved to draft? EXT_disjoint_timer_query (draft) * Is there intent to implement it? * If not, should it be dropped from the registry? WEBGL_shared_resources (draft) * Is there intent to implement it? * If not, should it be dropped from the registry? WEBGL_security_sensitive_resources (draft) * Is there intent to implement it? * If not, should it be dropped from the registry? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jan 14 02:46:36 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 14 Jan 2015 11:46:36 +0100 Subject: [Public WebGL] extensions status In-Reply-To: References: Message-ID: Thank you for the feedback Olli, On Wed, Jan 14, 2015 at 11:23 AM, Olli Etuaho wrote: > > I recall that the process has still been that proposals are kept in the > registry even if they are rejected, in order to keep a history of what has > been proposed. > Maybe we can have a category for extensions we'll drop so that the history is still available, something like a status "dropped" or "rejected"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jan 17 09:24:25 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 17 Jan 2015 18:24:25 +0100 Subject: [Public WebGL] WebGL-next Message-ID: This is a bit of idle speculation, but some things stood out to me from the Khronos OpenGL-next roadmap: https://www.khronos.org/assets/uploads/events/Next-Generation-OpenGL-Dec14.pdf - Intermediary bytecode shader format - Multi-threaded render command submission - complete API redesign - statelessness and direct access? I think some of these will be challenges for the web. *Intermediary bytecode shader format* The main problem here is probably that most simple solutions aren't going to work with it (so source fallback needs to exist). Also, most web developers don't use a precompilation step for their sources. The second problem I see here would be a complete lack of tooling to compile shaders on machines that do not have GPUs (as in webservers). I think Khronos needs to do a huge step forward there and produce a compiler that does not rely on a GPU, is available on all platforms, can easily be installed (a minimum of dependencies) and if at all possible, is open source. *Multi-threaded render command submission* Here the web has a problem. We don't have threads. There's WebWorkers, which is great, but they're not threads. Is it worth considering something like WebThreads so that WebGL-next users could make use of this feature? *Complete API redesign* WebGL does its best to dress up the C-origin API of OpenGL and make it nice to use in JS. But even the best falls somewhat flat because it does need to adhere to the specification and it is still a C API. I think there's a chance that a new standard could offer for a polyglot environment to provide greater leeway in the concrete interpretation of the API language, so as to make it more idiomatic for any given target. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Sat Jan 17 22:41:02 2015 From: baj...@ (Brandon Jones) Date: Sun, 18 Jan 2015 06:41:02 +0000 Subject: [Public WebGL] WebGL-next References: Message-ID: It'll be easier to comment once the spec is actually made public, but broadly agree that it's going to be a challenge to realize a sane and useful web API that follows in the footsteps of any of the next generation of graphics libs. A few thoughts on your specific comments: Regarding intermediate bytecode for shaders, I don't view this as a problem and actually view it as a positive for the web in general. Aside from being more efficient to process and easier to distribute, by having an bytecode users can develop shaders in whatever language has a compiler available but the web only has to understand one format. That puts us in roughly the same position as we're in with GLSL today, but with a more performance-friendly format. It may prove to be a concern for Shadertoy-like sites that want to compile their shaders on the fly, but with the advent of emscripten we can be reasonably certain that any native compilers that get built can have a JS interface. Also, for the sake of clarity: the compile process shouldn't require a GPU. The bytecode will be standardized and not rely on any GPU specific instructions, so it should be perfectly feasible to run the compilers on any device with a CPU. Multi-threading: Yeah, this one is going to suck to figure out. There may be a reasonable way to build command buffers in a worker and submit them from the main thread, but I'm not sure. Really we just need to wait till the spec is public to collectively dig into it and see. API redesign: The bits I find most objectionable about WebGL as it stands today are primarily historical artifacts that have carried through the various API revisions. Things like leftover function arguments (Texture borders!) and the general state-machine design. Khronos is well aware that everyone, from game devs to driver devs, has issues with the current state of things. They also have an awful lot of very intelligent, very experienced people contributing, so have a bit of faith that they won't make a total mess of things. :) On Sat Jan 17 2015 at 9:25:16 AM Florian B?sch wrote: > This is a bit of idle speculation, but some things stood out to me from > the Khronos OpenGL-next roadmap: > > > https://www.khronos.org/assets/uploads/events/Next-Generation-OpenGL-Dec14.pdf > > - Intermediary bytecode shader format > - Multi-threaded render command submission > - complete API redesign > - statelessness and direct access? > > I think some of these will be challenges for the web. > > *Intermediary bytecode shader format* > > The main problem here is probably that most simple solutions aren't going > to work with it (so source fallback needs to exist). Also, most web > developers don't use a precompilation step for their sources. The second > problem I see here would be a complete lack of tooling to compile shaders > on machines that do not have GPUs (as in webservers). I think Khronos needs > to do a huge step forward there and produce a compiler that does not rely > on a GPU, is available on all platforms, can easily be installed (a minimum > of dependencies) and if at all possible, is open source. > > *Multi-threaded render command submission* > > Here the web has a problem. We don't have threads. There's WebWorkers, > which is great, but they're not threads. Is it worth considering something > like WebThreads so that WebGL-next users could make use of this feature? > > *Complete API redesign* > > WebGL does its best to dress up the C-origin API of OpenGL and make it > nice to use in JS. But even the best falls somewhat flat because it does > need to adhere to the specification and it is still a C API. > > I think there's a chance that a new standard could offer for a polyglot > environment to provide greater leeway in the concrete interpretation of the > API language, so as to make it more idiomatic for any given target. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jan 17 23:24:44 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 18 Jan 2015 08:24:44 +0100 Subject: [Public WebGL] WebGL-next In-Reply-To: References: Message-ID: On Sun, Jan 18, 2015 at 7:41 AM, Brandon Jones wrote: > Regarding intermediate bytecode for shaders, I don't view this as a > problem and actually view it as a positive for the web in general. Aside > from being more efficient to process and easier to distribute, by having an > bytecode users can develop shaders in whatever language has a compiler > available but the web only has to understand one format. That puts us in > roughly the same position as we're in with GLSL today, but with a more > performance-friendly format. > Well, I don't mean a problem as in "it shouldn't be done". I think it should be done, and it's a good idea. It's a problem because it introduces a (hitherto unheard of) precompilation requirement on web technology (and so will surprise a whole lot of people). > It may prove to be a concern for Shadertoy-like sites that want to compile > their shaders on the fly, but with the advent of emscripten we can be > reasonably certain that any native compilers that get built can have a JS > interface. Also, for the sake of clarity: the compile process shouldn't > require a GPU. The bytecode will be standardized and not rely on any GPU > specific instructions, so it should be perfectly feasible to run the > compilers on any device with a CPU. > I think that stating it as "a concern for Shadertoy-like sites" is not a correct characterization. Being able to deliver bytecode is beneficial, no two ways about it. However, the facility to provide source (and compile it to bytecode on the client) has to be present from day 0, no ifs and whens and tooling. This is because many sites (among them shadertoy like ones, but also fractal explorer etc.) assemble a shader based on performance requirements and user settings. For instance, I recently engaged a client from the geomapping domain, which has a complex configuration requirement where a shader needs to perform one of a dozen of different flavors of interpolation, using one of 3 possible fading effects, using one of 2 possible texture layout interpretations, using one of 2 possible texture packing formats, leading to (drumroll) a complete total of 144 possible shader combinations (only 2-3 of which are in actual use at any point in time). It'd be a huge drag on bandwidth, build times and code complexity to pre-assemble all combinations instead of assembling them in-situ. And an emscripten compilate as a required dependence to get something back which is hugely beneficial is a suggestion I find unsavory. So the problem, really is tooling for the bytecode format, which has to be there and it has to be excellent (and fast, and have zero download overhead for the client), and it has to be present from day 0. That's the huge step I see Khronos as being required to take, to make sure it is so, and that the compile tool is widely avaiable, has a minimum of dependencies, is easy to integrate both into developers toolchains as well as for browser vendors. This really is a requirement if you're going to rely on a bytecode format for an open standard, particularly, when it's for the web. API redesign: The bits I find most objectionable about WebGL as it stands > today are primarily historical artifacts that have carried through the > various API revisions. Things like leftover function arguments (Texture > borders!) and the general state-machine design. Khronos is well aware that > everyone, from game devs to driver devs, has issues with the current state > of things. They also have an awful lot of very intelligent, very > experienced people contributing, so have a bit of faith that they won't > make a total mess of things. :) > What I meant to indicate is that OpenGL is traditionally designed for C. But WebGL isn't programmed in C. In fact, OpenGL is rarely used in C these days (most people use Java, Objective C, C++, Javascript etc.). So I see a possible pitfall in designing OpenGL-next as another C API, with little leeway in its interpretation for other host languages (as it has traditionally been the way if a GL implementation wants to be ratified by Khronos). I'd suggest that a new standard takes into account that the new API is not going to be consumed in C primarily, but only incidentially, and that it offers ways for implementations to attain Khronos ratification even if the changes to the API they make (from a C version) would be fairly substantial in order to attain idiomacity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mar...@ Sun Jan 18 03:33:56 2015 From: mar...@ (=?UTF-8?B?TWFya3VzIFNjaMO8dHo=?=) Date: Sun, 18 Jan 2015 12:33:56 +0100 Subject: [Public WebGL] WebGL-next In-Reply-To: References: Message-ID: <54BB9A24.2040903@gmx.at> I'm somewhat in the same boat. I've got a lot of different possible shader configurations that are assembled and compiled at run time, usually when the user changes some options. It seems unfeasible to compile/assemble all of them previously. Besides shadertoy, another application that I started to like is the firefox shader debugger. I guess that one wouldn't work with intermediate bytecode? Personally I'd love to see both options. The glsl compilers as they are now and intermediate bytecode, enabling developers to choose what's best for the task at hand. Am 18/01/2015 um 08:24 schrieb Florian B?sch: > On Sun, Jan 18, 2015 at 7:41 AM, Brandon Jones > wrote: > > Regarding intermediate bytecode for shaders, I don't view this as > a problem and actually view it as a positive for the web in > general. Aside from being more efficient to process and easier to > distribute, by having an bytecode users can develop shaders in > whatever language has a compiler available but the web only has to > understand one format. That puts us in roughly the same position > as we're in with GLSL today, but with a more performance-friendly > format. > > Well, I don't mean a problem as in "it shouldn't be done". I think it > should be done, and it's a good idea. It's a problem because it > introduces a (hitherto unheard of) precompilation requirement on web > technology (and so will surprise a whole lot of people). > > It may prove to be a concern for Shadertoy-like sites that want to > compile their shaders on the fly, but with the advent of > emscripten we can be reasonably certain that any native compilers > that get built can have a JS interface. Also, for the sake of > clarity: the compile process shouldn't require a GPU. The bytecode > will be standardized and not rely on any GPU specific > instructions, so it should be perfectly feasible to run the > compilers on any device with a CPU. > > I think that stating it as "a concern for Shadertoy-like sites" is not > a correct characterization. Being able to deliver bytecode is > beneficial, no two ways about it. However, the facility to provide > source (and compile it to bytecode on the client) has to be present > from day 0, no ifs and whens and tooling. This is because many sites > (among them shadertoy like ones, but also fractal explorer etc.) > assemble a shader based on performance requirements and user settings. > For instance, I recently engaged a client from the geomapping domain, > which has a complex configuration requirement where a shader needs to > perform one of a dozen of different flavors of interpolation, using > one of 3 possible fading effects, using one of 2 possible texture > layout interpretations, using one of 2 possible texture packing > formats, leading to (drumroll) a complete total of 144 possible > shader combinations (only 2-3 of which are in actual use at any point > in time). It'd be a huge drag on bandwidth, build times and code > complexity to pre-assemble all combinations instead of assembling them > in-situ. And an emscripten compilate as a required dependence to get > something back which is hugely beneficial is a suggestion I find unsavory. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Jan 18 04:00:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sun, 18 Jan 2015 13:00:21 +0100 Subject: [Public WebGL] WebGL-next In-Reply-To: <54BB9A24.2040903@gmx.at> References: <54BB9A24.2040903@gmx.at> Message-ID: To expand a bit on the topic of shader combinatorics. I've previously wielded this argumentation to encourage vendors to make compilation of shaders faster (and it improved a lot, sadly it's still slower than just about any compiler I know of). I'm now wielding the same club to encourage thought about making sure to preserve old advantages, while helping to build new ones (bytecode). I'm sure OpenGL-next will introduce a lot of handy functionality to avoid having to combine shaders at source level. At the same time, not everything that needs to be configured can always be abstracted into a set of function symbols. There's always going to be cases where combinatoric changes to the shader are required. The first and foremost way to make these changes, is to recombine pieces of shader source on the client. Bytecode is very welcome for other usecases, and it needs to be supported extremely well. And if the bytecode compiler/tool wants to offer features making combinatorics easier, all the better. But source delivery has to work, always. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Thu Jan 22 15:28:19 2015 From: jda...@ (John Davis) Date: Thu, 22 Jan 2015 18:28:19 -0500 Subject: [Public WebGL] IE11 vs Chrome In-Reply-To: References: Message-ID: Just upgraded to Chrome 40, it still stutters when compared to IE11. Did the Intel upgrade go in? On Mon, Nov 24, 2014 at 12:22 PM, Jamie Madill wrote: > If you want to use it now, you can try Beta, Dev or Canary. I believe > releases are usually every six weeks so you should see M40 hitting stable > around the end of December. > > On Sat, Nov 22, 2014 at 5:54 AM, John Davis > wrote: > >> Is there an ETA on release? >> >> >> On Wed, Nov 19, 2014 at 10:09 AM, Jamie Madill >> wrote: >> >>> Hey John & Florian, >>> >>> We were forcing D3D9 on Intel for a while due to performance problems. >>> Now that we've mostly fixed the perf in ANGLE, in Chrome M40 (currently >>> only available as dev or Canary) we've enabled D3D11 for more recent Intel >>> drivers. >>> >>> There's a tracking Chrome bug here: http://crbug.com/363721. >>> >>> On Tue, Nov 18, 2014 at 6:05 PM, Florian B?sch wrote: >>> >>>> - https://code.google.com/p/chromium/issues/list >>>> - https://bugzilla.mozilla.org/ >>>> - https://bugs.webkit.org/ >>>> - https://code.google.com/p/angleproject/issues/list >>>> - https://connect.microsoft.com/IE >>>> >>>> On Tue, Nov 18, 2014 at 11:58 PM, John Davis >>>> wrote: >>>> >>>>> Ticket? Where? BTW, Jamie just said the Intel updates are on their >>>>> way. >>>>> >>>>> On Tue, Nov 18, 2014 at 5:56 PM, Florian B?sch >>>>> wrote: >>>>> >>>>>> So it's the ordinary DX11 path for IE. So for whatever reason, Chrome >>>>>> decided to service your webgl with DX9. Maybe file a ticket? >>>>>> >>>>>> On Tue, Nov 18, 2014 at 11:54 PM, John Davis < >>>>>> jdavis...@> wrote: >>>>>> >>>>>>> Platform:Win32Browser User Agent:Mozilla/5.0 (Windows NT 6.3; >>>>>>> WOW64; Trident/7.0; Touch; .NET4.0E; .NET4.0C; Tablet PC 2.0; .NET CLR >>>>>>> 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; InfoPath.3; BRI/2; >>>>>>> rv:11.0) like GeckoContext Name:experimental-webglGL Version:WebGL >>>>>>> 0.94Shading Language Version:WebGL GLSL ES 0.94Vendor:Microsoft >>>>>>> Renderer:Internet ExplorerUnmasked Vendor:MicrosoftUnmasked >>>>>>> Renderer:Intel(R) HD Graphics 4000Antialiasing:AvailableANGLE:NoMajor >>>>>>> Performance Caveat:No >>>>>>> >>>>>>> On Tue, Nov 18, 2014 at 5:42 PM, Florian B?sch >>>>>>> wrote: >>>>>>> >>>>>>>> I believe that this backend was selected for you, because of the HD >>>>>>>> 4000, for whatever reason. Could some of the chrome guys comment on this? >>>>>>>> Also please look at http://webglreport.com/ with IE and see what >>>>>>>> you get. >>>>>>>> >>>>>>>> On Tue, Nov 18, 2014 at 11:38 PM, John Davis < >>>>>>>> jdavis...@> wrote: >>>>>>>> >>>>>>>>> Lol, that must be it, I have Intel drivers. >>>>>>>>> >>>>>>>>> ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex vs_3_0 ps_3_0) >>>>>>>>> >>>>>>>>> When's the new update come out? >>>>>>>>> >>>>>>>>> On Tue, Nov 18, 2014 at 9:58 AM, Jamie Madill < >>>>>>>>> jmadill...@> wrote: >>>>>>>>> >>>>>>>>>> This 3D Texture sample seems to use 100% of my GPU; it's possible >>>>>>>>>> IE handles dropped frames a little better sometimes. For me, Canary behaves >>>>>>>>>> better than stable Chrome. >>>>>>>>>> >>>>>>>>>> FYI you can also look at about:gpu in Chrome to determine if >>>>>>>>>> you're using D3D11 or D3D9. Most AMD and nVidia systems should be on D3D11, >>>>>>>>>> and we're recently moving to D3D11 on Intel systems with recent drivers. >>>>>>>>>> >>>>>>>>>> On Tue, Nov 18, 2014 at 5:13 AM, Tibor Ouden, den < >>>>>>>>>> tibordenouden...@> wrote: >>>>>>>>>> >>>>>>>>>>> If you go to : http://webglreport.com/ you will see if the >>>>>>>>>>> webgl implementation uses ANGLE and what version of DirectX is used. >>>>>>>>>>> >>>>>>>>>>> 2014-11-18 10:54 GMT+01:00 Florian B?sch : >>>>>>>>>>> >>>>>>>>>>>> On Tue, Nov 18, 2014 at 10:38 AM, John Davis < >>>>>>>>>>>> jdavis...@> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Will Chrome/Angle be using DX11 anytime soon? >>>>>>>>>>>>> >>>>>>>>>>>> As Brandon has said, it depends on your system if Angle is >>>>>>>>>>>> using DX11 or DX9. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Not sure about everyone else, but on my end this demo is >>>>>>>>>>>>> smooth as glass on IE11, but stutters/jerks on Chrome. >>>>>>>>>>>>> >>>>>>>>>>>> That's probably not got anything to do with the backend choice. >>>>>>>>>>>> It runs smooth here in Chrome/Linux. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Any idea what the difference is? Or how I can make it run >>>>>>>>>>>>> better on Chrome? >>>>>>>>>>>>> >>>>>>>>>>>> Stuttering/Jerking/etc. is most often caused by engaging the JS >>>>>>>>>>>> garbage collector a lot. Each time it kicks in, it stops the world for >>>>>>>>>>>> anything between 80-150ms and nothing gets drawn during that time. >>>>>>>>>>>> >>>>>>>>>>>> It is possible that there's a particular bug with Chrome (due >>>>>>>>>>>> to vsync and whatnot) that you might be affected by (Brandon and I talked >>>>>>>>>>>> about this getting somewhat worse). You should compare your demo on >>>>>>>>>>>> different browsers (IE, Chrome, Firefox, Opera) and on different OSes (OSX, >>>>>>>>>>>> Windows, Android, iOS). This helps you spot if you did something wrong >>>>>>>>>>>> (it's bad everywhere), or something suboptimal you did (it's good on >>>>>>>>>>>> exactly one browser, but not on any other), or if it's a browser bug (it's >>>>>>>>>>>> bad on only one browser). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Thu Jan 22 15:48:02 2015 From: jda...@ (John Davis) Date: Thu, 22 Jan 2015 18:48:02 -0500 Subject: [Public WebGL] Hololens Message-ID: This whole Hololens thing, will there be webgl hooks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Thu Jan 22 17:27:21 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 23 Jan 2015 01:27:21 +0000 Subject: [Public WebGL] Hololens In-Reply-To: References: Message-ID: Hello John, The information I can share with you at this point is what we have disclosed to the general public. From http://www.microsoft.com/microsoft-hololens/en-us/get-ready: ?How do I learn more about designing and developing apps for Microsoft HoloLens? Microsoft HoloLens runs on Windows 10, so developers building on Windows 10 will already know how to build for Microsoft HoloLens from a platform perspective. Having this same foundation means that developers will be familiar with the tools and benefits of the Windows Store. The best way to get started is to become familiar with Windows 10 by joining the Windows Insider Program. Next, register for Build 2015. At Build, you?ll learn more about how to get started designing and developing for Microsoft HoloLens, receive details on the SDK, and meet members of our engineering team. If you can?t attend in person, plan to tune in via livestream or check out the recorded keynote and session presentations that will be available after the event.? --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of John Davis Sent: Thursday, January 22, 2015 3:48 PM To: public webgl Subject: [Public WebGL] Hololens This whole Hololens thing, will there be webgl hooks? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Jan 22 17:58:21 2015 From: kbr...@ (Kenneth Russell) Date: Thu, 22 Jan 2015 17:58:21 -0800 Subject: [Public WebGL] extension candidates for khronos ratification from community approved In-Reply-To: References: <6EDE7E3B-A0ED-4A38-9106-56F68345CECC@callow.im> Message-ID: On Tue, Jan 6, 2015 at 5:10 AM, Florian B?sch wrote: > On Tue, Jan 6, 2015 at 1:56 PM, Mark Callow wrote: >> >> EXT extensions aren?t ratified by Khronos. They are simply multi-vendor >> extensions. > > > Objection irrelevant. This understanding of the extension process is derived > from the ES-native registries, it has no bearing on the WebGL extension > registry. Please consult https://www.khronos.org/registry/webgl/extensions/ > for the WebGL extension process. > > The EXT_ prefix (as well as any other prefix mirrored from an ES extension) > does not have a specific meaning for the WebGL ratification process. > >> Khronos ratified extensions are those community approved extensions which >> have been voted upon by the Khronos Board of Promoters > > > Precedents for non OES extensions that've been WebGL Khronos Ratified: > > WEBGL_lose_context > WEBGL_debug_renderer_info > WEBGL_debug_shaders > WEBGL_compressed_texture_s3tc > WEBGL_depth_texture > EXT_texture_filter_anisotropic > WEBGL_draw_buffers > ANGLE_instanced_arrays > > The status "community approved" was introduced so that WebGL extensions can > be moved out of draft (where they would be vendor prefixed) in order to > avoid extensions languishing in eternal draft hell until the Khronos board > got around to ratify them. > > The goal of a community approved extension is to make it to Khronos ratified > to complete the process. The WebGL WG will consider submitting these extensions to the Khronos Promoters for ratification. Thanks for providing availability statistics. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Fri Jan 23 03:13:08 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Fri, 23 Jan 2015 12:13:08 +0100 Subject: [Public WebGL] Hololens In-Reply-To: References: Message-ID: John's question related to WebGL. It's generally the case that Web/WebGL developers have little interest in SDKs and single platform locked in technology. What does generally interest us is if it will work across platforms and in WebGL. On Fri, Jan 23, 2015 at 2:27 AM, Rafael Cintron < Rafael.Cintron...@> wrote: > Hello John, > > > > The information I can share with you at this point is what we have > disclosed to the general public. > > > > From http://www.microsoft.com/microsoft-hololens/en-us/get-ready: > > *?How do I learn more about designing and developing apps for Microsoft > HoloLens? * > > > > Microsoft HoloLens runs on Windows 10, so developers building on Windows > 10 will already know how to build for Microsoft HoloLens from a platform > perspective. Having this same foundation means that developers will be > familiar with the tools and benefits of the Windows Store. > > > > The best way to get started is to become familiar with Windows 10 by > joining the Windows Insider Program. Next, register for Build 2015. At > Build, you?ll learn more about how to get started designing and developing > for Microsoft HoloLens, receive details on the SDK, and meet members of our > engineering team. If you can?t attend in person, plan to tune in via > livestream or check out the recorded keynote and session presentations that > will be available after the event.? > > > > > > --Rafael > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *John Davis > *Sent:* Thursday, January 22, 2015 3:48 PM > *To:* public webgl > *Subject:* [Public WebGL] Hololens > > > > This whole Hololens thing, will there be webgl hooks? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Fri Jan 23 09:00:22 2015 From: tpa...@ (Tony Parisi) Date: Fri, 23 Jan 2015 09:00:22 -0800 Subject: [Public WebGL] Hololens In-Reply-To: References: Message-ID: Hi Rafael If there is any way to get a message back to the Hololens team, please pass this on: people in this group would be very interested in building *web* applications for Hololens. If that is going to happen, then the browser and WebGL would be the way to do it. If they're not yet thinking about this, they should be. Tony On Thu, Jan 22, 2015 at 5:27 PM, Rafael Cintron < Rafael.Cintron...@> wrote: > Hello John, > > > > The information I can share with you at this point is what we have > disclosed to the general public. > > > > From http://www.microsoft.com/microsoft-hololens/en-us/get-ready: > > *?How do I learn more about designing and developing apps for Microsoft > HoloLens? * > > > > Microsoft HoloLens runs on Windows 10, so developers building on Windows > 10 will already know how to build for Microsoft HoloLens from a platform > perspective. Having this same foundation means that developers will be > familiar with the tools and benefits of the Windows Store. > > > > The best way to get started is to become familiar with Windows 10 by > joining the Windows Insider Program. Next, register for Build 2015. At > Build, you?ll learn more about how to get started designing and developing > for Microsoft HoloLens, receive details on the SDK, and meet members of our > engineering team. If you can?t attend in person, plan to tune in via > livestream or check out the recorded keynote and session presentations that > will be available after the event.? > > > > > > --Rafael > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *John Davis > *Sent:* Thursday, January 22, 2015 3:48 PM > *To:* public webgl > *Subject:* [Public WebGL] Hololens > > > > This whole Hololens thing, will there be webgl hooks? > > > -- Tony Parisi tparisi...@ Founder, Third Eye http://www.thirdeye.gl/ Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Mobile 415.902.8002 Skype auradeluxe Read my books! *Programming 3D Applications in HTML5 and WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 WebGL, Up and Running* http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From Raf...@ Fri Jan 23 10:46:54 2015 From: Raf...@ (Rafael Cintron) Date: Fri, 23 Jan 2015 18:46:54 +0000 Subject: [Public WebGL] Hololens In-Reply-To: References: Message-ID: Thank you for your feedback Tony and Florian. I have passed it along to the Hololens team. From: Tony Parisi [mailto:tparisi...@] Sent: Friday, January 23, 2015 9:00 AM To: Rafael Cintron Cc: John Davis; public webgl Subject: Re: [Public WebGL] Hololens Hi Rafael If there is any way to get a message back to the Hololens team, please pass this on: people in this group would be very interested in building *web* applications for Hololens. If that is going to happen, then the browser and WebGL would be the way to do it. If they're not yet thinking about this, they should be. Tony On Thu, Jan 22, 2015 at 5:27 PM, Rafael Cintron > wrote: Hello John, The information I can share with you at this point is what we have disclosed to the general public. From http://www.microsoft.com/microsoft-hololens/en-us/get-ready: ?How do I learn more about designing and developing apps for Microsoft HoloLens? Microsoft HoloLens runs on Windows 10, so developers building on Windows 10 will already know how to build for Microsoft HoloLens from a platform perspective. Having this same foundation means that developers will be familiar with the tools and benefits of the Windows Store. The best way to get started is to become familiar with Windows 10 by joining the Windows Insider Program. Next, register for Build 2015. At Build, you?ll learn more about how to get started designing and developing for Microsoft HoloLens, receive details on the SDK, and meet members of our engineering team. If you can?t attend in person, plan to tune in via livestream or check out the recorded keynote and session presentations that will be available after the event.? --Rafael From: owners-public_webgl...@ [mailto:owners-public_webgl...@] On Behalf Of John Davis Sent: Thursday, January 22, 2015 3:48 PM To: public webgl Subject: [Public WebGL] Hololens This whole Hololens thing, will there be webgl hooks? -- Tony Parisi tparisi...@ Founder, Third Eye http://www.thirdeye.gl/ Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Mobile 415.902.8002 Skype auradeluxe Read my books! Programming 3D Applications in HTML5 and WebGL http://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 WebGL, Up and Running http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Fri Jan 23 11:04:33 2015 From: tpa...@ (Tony Parisi) Date: Fri, 23 Jan 2015 11:04:33 -0800 Subject: [Public WebGL] Hololens In-Reply-To: References: Message-ID: thanks :-) On Fri, Jan 23, 2015 at 10:46 AM, Rafael Cintron < Rafael.Cintron...@> wrote: > Thank you for your feedback Tony and Florian. I have passed it along to > the Hololens team. > > > > *From:* Tony Parisi [mailto:tparisi...@] > *Sent:* Friday, January 23, 2015 9:00 AM > *To:* Rafael Cintron > *Cc:* John Davis; public webgl > *Subject:* Re: [Public WebGL] Hololens > > > > Hi Rafael > > If there is any way to get a message back to the Hololens team, please > pass this on: people in this group would be very interested in building > *web* applications for Hololens. If that is going to happen, then the > browser and WebGL would be the way to do it. If they're not yet thinking > about this, they should be. > > Tony > > > > On Thu, Jan 22, 2015 at 5:27 PM, Rafael Cintron < > Rafael.Cintron...@> wrote: > > Hello John, > > > > The information I can share with you at this point is what we have > disclosed to the general public. > > > > From http://www.microsoft.com/microsoft-hololens/en-us/get-ready: > > *?How do I learn more about designing and developing apps for Microsoft > HoloLens? * > > > > Microsoft HoloLens runs on Windows 10, so developers building on Windows > 10 will already know how to build for Microsoft HoloLens from a platform > perspective. Having this same foundation means that developers will be > familiar with the tools and benefits of the Windows Store. > > > > The best way to get started is to become familiar with Windows 10 by > joining the Windows Insider Program. Next, register for Build 2015. At > Build, you?ll learn more about how to get started designing and developing > for Microsoft HoloLens, receive details on the SDK, and meet members of our > engineering team. If you can?t attend in person, plan to tune in via > livestream or check out the recorded keynote and session presentations that > will be available after the event.? > > > > > > --Rafael > > > > *From:* owners-public_webgl...@ [mailto: > owners-public_webgl...@] *On Behalf Of *John Davis > *Sent:* Thursday, January 22, 2015 3:48 PM > *To:* public webgl > *Subject:* [Public WebGL] Hololens > > > > This whole Hololens thing, will there be webgl hooks? > > > > > > > -- > > > > Tony Parisi tparisi...@ > > Founder, Third Eye http://www.thirdeye.gl/ > > Follow me on Twitter! http://twitter.com/auradeluxe > > Read my blog at http://www.tonyparisi.com/ > > Learn WebGL http://learningwebgl.com/ > > Mobile 415.902.8002 > > Skype auradeluxe > > > Read my books! > > > * Programming 3D Applications in HTML5 and WebGL > http://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 > > WebGL, Up and Running* > http://www.amazon.com/dp/144932357X > -- Tony Parisi tparisi...@ Founder, Third Eye http://www.thirdeye.gl/ Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Mobile 415.902.8002 Skype auradeluxe Read my books! *Programming 3D Applications in HTML5 and WebGLhttp://www.amazon.com/Programming-Applications-HTML5-WebGL-Visualization/dp/1449362966 WebGL, Up and Running* http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 23 21:40:11 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Jan 2015 06:40:11 +0100 Subject: [Public WebGL] extensions status In-Reply-To: References: Message-ID: On Wed, Jan 14, 2015 at 11:46 AM, Florian B?sch wrote: > Maybe we can have a category for extensions we'll drop so that the history > is still available, something like a status "dropped" or "rejected"? > A rejected status has been introduced. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 23 22:04:50 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Jan 2015 07:04:50 +0100 Subject: [Public WebGL] extensions status In-Reply-To: References: Message-ID: On Wed, Jan 14, 2015 at 11:23 AM, Olli Etuaho wrote: > WEBGL_draw_elements_no_range_check - dropped as an extension. This > functionality would be better to implement just as a part of WebGL 2 at > this point, if it is decided that the tradeoffs offered here are good. > Although I'm sad to see it go, I'm proposing to reject this extension, any objections? https://github.com/KhronosGroup/WebGL/pull/822 > WEBGL_security_sensitive_resources - This is a very ambitious extension. > While the functionality is desirable, it's hard to implement and could hurt > performance in a major way in some cases. For example delta color > compression in NVIDIA GPUs would likely have to be disabled due to the > timing requirements. So I don't honestly see this being worth the effort, > though maybe others disagree. > Proposing to reject this extension, any objections? https://github.com/KhronosGroup/WebGL/pull/824 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Jan 23 22:19:30 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Jan 2015 07:19:30 +0100 Subject: [Public WebGL] Re: extensions status In-Reply-To: References: Message-ID: On Wed, Jan 14, 2015 at 9:42 AM, Florian B?sch wrote: > > EXT_color_buffer_half_float and WEBGL_color_buffer_float which are in > community approved status have dropped off the map (implementations have > vanished). This is sort of a problem and I'd like to know if: > > - Is there any intent to implement those? > - If not, should (can) it be dropped from the registry? > > Any input on EXT_color_buffer_half_float and WEBGL_color_buffer_float? WEBGL_compressed_texture_es3 (proposal) > > - Is this specification finalized? > - If so, is there intent to implement it? > - If so, should it be moved to draft? > > Any input on WEBGL_compressed_texture_es3? > WEBGL_dynamic_texture (proposal) > > - Is this specification finalized? > - If so, is there intent to implement it? > - If so, should it be moved to draft? > > Proposing to reject this extension, any objections? https://github.com/KhronosGroup/WebGL/pull/825 > > EXT_disjoint_timer_query (draft) > > - Is there intent to implement it? > - If not, should it be dropped from the registry? > > Any input on EXT_disjoint_timer_query? > WEBGL_shared_resources (draft) > > - Is there intent to implement it? > - If not, should it be dropped from the registry? > > Proposing to reject this extension, any objections? https://github.com/KhronosGroup/WebGL/pull/826 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jan 24 00:27:23 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Jan 2015 09:27:23 +0100 Subject: [Public WebGL] WEBGL_debug_shader_precision extension proposal In-Reply-To: References: <0d8d2351645043d395c3b3082c57a051@UKMAIL101.nvidia.com> <709999714.32547316.1415679688805.JavaMail.zimbra@mozilla.com> <1921268102.32684235.1415740830778.JavaMail.zimbra@mozilla.com> <8767142A-90BA-49D6-B54C-CBE3BD995FFD@callow.im> <80241209.32721429.1415759193822.JavaMail.zimbra@mozilla.com> <9b2510c7eded4dc39ded3eaf3f9827fc@UKMAIL101.nvidia.com> <530768bd1b2e433cbe2df3fd39691a76@UKMAIL101.nvidia.com> <3ec1d95e870f4cfaae837b3aba8b36ba@UKMAIL101.nvidia.com> <33a07ed145ae4642874b1cfeb6dcce24@UKMAIL101.nvidia.com> Message-ID: On Wed, Nov 19, 2014 at 11:31 PM, Kenneth Russell wrote: > Given this, it looks like the best way forward is to write some > helpers that make it easy to invoke the Emscripten-compiled shader > translator from JavaScript, and provide this precision emulation as a > JavaScript library. > Is there consensus that this is the best course of action (I would agree)? If so, I would propose to reject this extension: https://github.com/KhronosGroup/WebGL/pull/827 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jan 24 00:43:05 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Jan 2015 09:43:05 +0100 Subject: [Public WebGL] WEBGL_subscribe_uniform extension In-Reply-To: References: Message-ID: I would welcome the functionality of this proposal. I'm not in favor of formulating it as an extension (for reasons listed) and I'm objecting to the semantic. I believe that the functionality can be provided without an extension (but a separate specification) and be done with better semantics. These points would be important to address: 1. Are we going to fail reaching consensus on the requirement to have this extension? 2. Can we reach consensus to provide it without an extension? I would propose that in case of #2 we can reject this extension. In case #1 persists or no further input is provided until February 24th 2015, that this extension be rejected, a suitable pull request has been prepared: https://github.com/KhronosGroup/WebGL/pull/828 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Jan 24 00:52:01 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Sat, 24 Jan 2015 09:52:01 +0100 Subject: [Public WebGL] WEBGL_texture_from_depth_video extension proposal In-Reply-To: <54653831.6020403@buildAR.com> References: <1983959216.32547150.1415679365272.JavaMail.zimbra@mozilla.com> <54629BD9.9040103@buildAR.com> <5462A59A.3080809@buildAR.com> <1413640822.32706449.1415752011280.JavaMail.zimbra@mozilla.com> <54653831.6020403@buildAR.com> Message-ID: For the reasons discussed (brief support period, feasibility of providing it without an extension etc.) I propose to reject this extension. Any objections (please provide the until February 24th 2015 the latest)? A suitable pull request has been prepared: https://github.com/KhronosGroup/WebGL/pull/829 -------------- next part -------------- An HTML attachment was scrubbed... URL: From roB...@ Sat Jan 24 17:18:25 2015 From: roB...@ (Rob Manson) Date: Sun, 25 Jan 2015 12:18:25 +1100 Subject: [Public WebGL] WEBGL_texture_from_depth_video extension proposal In-Reply-To: References: <1983959216.32547150.1415679365272.JavaMail.zimbra@mozilla.com> <54629BD9.9040103@buildAR.com> <5462A59A.3080809@buildAR.com> <1413640822.32706449.1415752011280.JavaMail.zimbra@mozilla.com> <54653831.6020403@buildAR.com> Message-ID: <54C44461.1030704@buildAR.com> +1 On 24/01/15 7:52 PM, Florian B?sch wrote: > For the reasons discussed (brief support period, feasibility of > providing it without an extension etc.) I propose to reject this > extension. Any objections (please provide the until February 24th 2015 > the latest)? A suitable pull request has been prepared: > https://github.com/KhronosGroup/WebGL/pull/829 ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Mon Jan 26 05:57:40 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 14:57:40 +0100 Subject: [Public WebGL] Device/Extension statistics Message-ID: I have done some data sleuthing on mobile GPUs consulting WEBGL_debug_render_info data from http://webglstats.com . I consulted close to a million entries in a 30 day span. These are the major devices/GPUs that WebGL sees (note that android share is adjusted for the fact that not all android browsers support debug renderer info. the iOS devices where determined by user agent). * 21.9% iPhone * 20.0% iPad * 14.5% Adreno (TM) 330 * 13.3% Adreno (TM) 305 * 12.5% Mali-400 MP * 9.3% Adreno (TM) 320 * 1.2% iPod * 1.2% NVIDIA Tegra 3 Using weights for OpenGL ES 3.0 support of these devices (see Appendix A), we can arrive at the conclusion that about *51%* of devices that have WebGL available, support *OpenGL ES 3.0*. This means that for the next 2 years, a substantial population of mobile devices *will not be able to run WebGL 2.0*. I have previously conducted estimates on extension support. Combining these GPU/device distributions from WEBGL_debug_renderer_info with the common subset of extensions each of the GPUs/devices support yields an estimate on extension support that's probably much better than before. See Appendix B for the full list. Note that GPU vendor specific extensions and extensions with less than 20% support have been purged. Further eliminating from that list: * Extensions we already have in WebGL * EGL extensions * EXT_robustness because browsers already handle that * withdrawn extensions * GL_EXT_discard_framebuffer because the context attribute preserveDrawingBuffer already covers this use-case. * extensions which are contained in the core of OpenGL ES 2.0 * debug_marker and debug_label because they aren't relevant to WebGL (you can always proxy the API and attach labels and markers) *List of potentially interesting extensions for WebGL* 92.5% GL_OES_packed_depth_stencil 92.5% GL_OES_depth24 81.3% GL_OES_fbo_render_mipmap 50.7% GL_EXT_texture_format_BGRA8888 49.5% GL_OES_texture_npot 44.3% GL_OES_mapbuffer 44.3% GL_EXT_occlusion_query_boolean 43.1% GL_EXT_texture_storage 43.1% GL_EXT_texture_rg 43.1% GL_EXT_shadow_samplers 43.1% GL_EXT_shader_framebuffer_fetch 43.1% GL_EXT_separate_shader_objects 43.1% GL_EXT_read_format_bgra 43.1% GL_EXT_pvrtc_sRGB 43.1% GL_EXT_map_buffer_range 38.2% GL_OES_vertex_half_float 37.0% GL_OES_vertex_type_10_10_10_2 37.0% GL_OES_texture_3D 37.0% GL_OES_depth_texture_cube_map 37.0% GL_EXT_texture_type_2_10_10_10_REV *Appendix A - OpenGL ES 3.0 weights.* * Mali-400 MP: 0% * Adreno (TM) 330: 100% * Adreno (TM) 305: 100% * Adreno (TM) 320: 100% * NVIDIA Tegra 3: 0% * iPhone: 42.3% * iPad: 24.5% * iPod: 0% These weights where determined consulting GPU specifications and the following sources: * http://www.nvidia.com/object/tegra-3-processor.html * http://en.wikipedia.org/wiki/Adreno * https://developer.apple.com/library/ios/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/OpenGLESPlatforms/OpenGLESPlatforms.html * http://david-smith.org/iosversionstats/ *Appendix B - full extension support estimate.* 93.7% GL_OES_standard_derivatives 92.5% GL_OES_packed_depth_stencil 92.5% GL_OES_depth_texture 92.5% GL_OES_depth24 92.5% GL_EXT_discard_framebuffer 81.3% GL_OES_texture_half_float 81.3% GL_OES_texture_float 81.3% GL_OES_rgb8_rgba8 81.3% GL_OES_fbo_render_mipmap 80.1% GL_OES_vertex_array_object 80.1% GL_OES_texture_half_float_linear 80.1% GL_OES_element_index_uint 80.1% GL_EXT_sRGB 80.1% GL_EXT_debug_marker 80.1% GL_EXT_debug_label 80.1% GL_EXT_color_buffer_half_float 58.7% GL_EXT_texture_filter_anisotropic 55.5% GL_EXT_blend_minmax 50.7% GL_OES_compressed_ETC1_RGB8_texture 50.7% GL_OES_EGL_image_external 50.7% GL_OES_EGL_image 50.7% GL_EXT_texture_format_BGRA8888 49.5% GL_OES_texture_npot 44.3% GL_OES_mapbuffer 44.3% GL_EXT_occlusion_query_boolean 43.1% GL_EXT_texture_storage 43.1% GL_EXT_texture_rg 43.1% GL_EXT_shadow_samplers 43.1% GL_EXT_shader_texture_lod 43.1% GL_EXT_shader_framebuffer_fetch 43.1% GL_EXT_separate_shader_objects 43.1% GL_EXT_read_format_bgra 43.1% GL_EXT_pvrtc_sRGB 43.1% GL_EXT_map_buffer_range 43.1% GL_EXT_instanced_arrays 43.1% GL_EXT_draw_instanced 38.2% GL_OES_vertex_half_float 38.2% GL_EXT_robustness 37.0% GL_OES_vertex_type_10_10_10_2 37.0% GL_OES_texture_3D 37.0% GL_OES_get_program_binary 37.0% GL_OES_fragment_precision_high 37.0% GL_OES_depth_texture_cube_map 37.0% GL_EXT_texture_type_2_10_10_10_REV 37.0% GL_EXT_disjoint_timer_query 37.0% GL_EXT_color_buffer_float -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 26 07:35:51 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 16:35:51 +0100 Subject: [Public WebGL] OES_fbo_render_mipmap Message-ID: I propose to add the extension OES_fbo_render_mipmap to WebGL for these reasons: - It is well supported on mobiles (around 81%) - It has been core functionality in desktops since OpenGL 2.0 - Direct3D 9 supports it - It is a core feature of OpenGL ES 3.0 - Considerable time will pass until WebGL 2.0 can be as widely supported A pull request has been prepared for review: https://github.com/KhronosGroup/WebGL/pull/830 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jav...@ Mon Jan 26 09:27:17 2015 From: jav...@ (Javi Agenjo) Date: Mon, 26 Jan 2015 18:27:17 +0100 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? Message-ID: Hi everyone: Sorry if this is not the propper place to comment this but since the latest Chrome update (40.0.2214.91 m) in windows the rendering to FBO using TEXTURE_CUBE_MAP has stopped working (sometimes it works with strange flickering). In OSX works fine as in Firefox. A product of mine already in production that was working perfectly has stopped working. Check it here: http://tamats.com/games/bwr/ (the skydome is pre-rendered to a cubemap using Florian approach to save performance). Has anybody experienced the same problem? I have created a simple demo of the bug but I cannot find the place to report bugs for webgl in chrome (only for Chromium). Which is the official way to face this kinds of problems? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 26 09:38:56 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 18:38:56 +0100 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? In-Reply-To: References: Message-ID: Hi Javi, I've had some trouble recently with cubemaps in a particular configuration. I did not manage to isolate the issue though, and I don't have a machine that exhibits the problem (it was a clients MBP). The usual procedure for that kind of thing is: 1. See if you can find a related conformance test that would fail/succeed in the same way your own code does ( https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html ) 2. If a conformance does not exist then isolate the problem and write a minimal test page that exhibits the error 3. Create a conformance test from that test page ( https://github.com/KhronosGroup/WebGL/tree/master/sdk/tests/conformance) 4. Submit a pull request to that conformance test ( https://github.com/KhronosGroup/WebGL/pulls) 5. Once the pull request is accepted, file tickets with the respective browser vendors. (https://bugzilla.mozilla.org/ , https://code.google.com/p/chromium/issues/list , https://bugs.webkit.org/ , https://connect.microsoft.com/IE/Feedback ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jav...@ Mon Jan 26 09:42:54 2015 From: jav...@ (Javi Agenjo) Date: Mon, 26 Jan 2015 18:42:54 +0100 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? In-Reply-To: References: Message-ID: Thanks a lot Florian, I'm going to check every step. On Mon, Jan 26, 2015 at 6:38 PM, Florian B?sch wrote: > Hi Javi, > > I've had some trouble recently with cubemaps in a particular > configuration. I did not manage to isolate the issue though, and I don't > have a machine that exhibits the problem (it was a clients MBP). > > The usual procedure for that kind of thing is: > > 1. See if you can find a related conformance test that would > fail/succeed in the same way your own code does ( > https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html > ) > 2. If a conformance does not exist then isolate the problem and write > a minimal test page that exhibits the error > 3. Create a conformance test from that test page ( > https://github.com/KhronosGroup/WebGL/tree/master/sdk/tests/conformance > ) > 4. Submit a pull request to that conformance test ( > https://github.com/KhronosGroup/WebGL/pulls) > 5. Once the pull request is accepted, file tickets with the respective > browser vendors. (https://bugzilla.mozilla.org/ , > https://code.google.com/p/chromium/issues/list , > https://bugs.webkit.org/ , https://connect.microsoft.com/IE/Feedback ) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From van...@ Mon Jan 26 09:43:49 2015 From: van...@ (Vangelis Kokkevis) Date: Mon, 26 Jan 2015 09:43:49 -0800 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? In-Reply-To: References: Message-ID: Javi, You're running into an ANGLE bug that slipped through the release process: https://code.google.com/p/chromium/issues/detail?id=447419 It has been fixed and the fix has been merged to the Chrome 41 branch but unfortunately it missed the Chrome 40 push. Vangelis On Mon, Jan 26, 2015 at 9:38 AM, Florian B?sch wrote: > Hi Javi, > > I've had some trouble recently with cubemaps in a particular > configuration. I did not manage to isolate the issue though, and I don't > have a machine that exhibits the problem (it was a clients MBP). > > The usual procedure for that kind of thing is: > > 1. See if you can find a related conformance test that would > fail/succeed in the same way your own code does ( > https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html > ) > 2. If a conformance does not exist then isolate the problem and write > a minimal test page that exhibits the error > 3. Create a conformance test from that test page ( > https://github.com/KhronosGroup/WebGL/tree/master/sdk/tests/conformance > ) > 4. Submit a pull request to that conformance test ( > https://github.com/KhronosGroup/WebGL/pulls) > 5. Once the pull request is accepted, file tickets with the respective > browser vendors. (https://bugzilla.mozilla.org/ , > https://code.google.com/p/chromium/issues/list , > https://bugs.webkit.org/ , https://connect.microsoft.com/IE/Feedback ) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geo...@ Mon Jan 26 09:47:02 2015 From: geo...@ (Geoff Lang) Date: Mon, 26 Jan 2015 17:47:02 +0000 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? References: Message-ID: It fix was also merged for Chrome 40 but didn't make the initial release. It should show up with the first update to Chrome 40. On Mon Jan 26 2015 at 12:44:35 PM Vangelis Kokkevis wrote: > Javi, > > You're running into an ANGLE bug that slipped through the release process: > > https://code.google.com/p/chromium/issues/detail?id=447419 > > It has been fixed and the fix has been merged to the Chrome 41 branch but > unfortunately it missed the Chrome 40 push. > > Vangelis > > On Mon, Jan 26, 2015 at 9:38 AM, Florian B?sch wrote: > >> Hi Javi, >> >> I've had some trouble recently with cubemaps in a particular >> configuration. I did not manage to isolate the issue though, and I don't >> have a machine that exhibits the problem (it was a clients MBP). >> >> The usual procedure for that kind of thing is: >> >> 1. See if you can find a related conformance test that would >> fail/succeed in the same way your own code does ( >> https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html >> ) >> 2. If a conformance does not exist then isolate the problem and write >> a minimal test page that exhibits the error >> 3. Create a conformance test from that test page ( >> https://github.com/KhronosGroup/WebGL/tree/master/sdk/tests/conformance >> ) >> 4. Submit a pull request to that conformance test ( >> https://github.com/KhronosGroup/WebGL/pulls) >> 5. Once the pull request is accepted, file tickets with the >> respective browser vendors. (https://bugzilla.mozilla.org/ , >> https://code.google.com/p/chromium/issues/list , >> https://bugs.webkit.org/ , https://connect.microsoft.com/IE/Feedback ) >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 26 09:50:33 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 18:50:33 +0100 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? In-Reply-To: References: Message-ID: Is there a conformance test for that kind of bug? There wasn't one on the ticket... -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 26 09:54:21 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 18:54:21 +0100 Subject: [Public WebGL] Re: Device/Extension statistics In-Reply-To: References: Message-ID: Packed depth stencil is already serviced by WEBGL_depth_texture I believe, so that's probably not that interesting. The revised list would be: 92.5% GL_OES_depth24 81.3% GL_OES_fbo_render_mipmap 50.7% GL_EXT_texture_format_BGRA8888 49.5% GL_OES_texture_npot 44.3% GL_OES_mapbuffer 44.3% GL_EXT_occlusion_query_boolean 43.1% GL_EXT_texture_storage 43.1% GL_EXT_texture_rg 43.1% GL_EXT_shadow_samplers 43.1% GL_EXT_shader_framebuffer_fetch 43.1% GL_EXT_separate_shader_objects 43.1% GL_EXT_read_format_bgra 43.1% GL_EXT_pvrtc_sRGB 43.1% GL_EXT_map_buffer_range 38.2% GL_OES_vertex_half_float 37.0% GL_OES_vertex_type_10_10_10_2 37.0% GL_OES_texture_3D 37.0% GL_OES_depth_texture_cube_map 37.0% GL_EXT_texture_type_2_10_10_10_REV -------------- next part -------------- An HTML attachment was scrubbed... URL: From geo...@ Mon Jan 26 10:30:42 2015 From: geo...@ (Geoff Lang) Date: Mon, 26 Jan 2015 18:30:42 +0000 Subject: [Public WebGL] Latest Chrome Render to Cubemap bug? References: Message-ID: No conformance test yet, it's on my to-do list. I wrote a small test in ANGLE when I fixed the bug and it's running on the chrome waterfall for now. On Mon, Jan 26, 2015, 5:50 PM Florian B?sch wrote: > Is there a conformance test for that kind of bug? There wasn't one on the > ticket... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 26 13:38:00 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 22:38:00 +0100 Subject: [Public WebGL] OES_depth24 Message-ID: I propose to add the extension OES_depth24 to WebGL for these reasons: - It's really the companion extension to depth textures since they enjoy about the same level of support (and depth textures support 24-bit depths) - The frontbuffer on WebGL is already almost always 24-bit - Framebuffer objects can only choose a 16-bit depth renderbuffer (and so are at a disadvantage) - It is well supported on mobiles (around 92%) - It has been core functionality on desktops since OpenGL 3.1 - It's defined on desktops since ARB_framebuffer_object (which is a prerequisite to FBOs) - It's supported by Direct3D 9 (D24X8) - Considerable time will pass until WebGL 2.0 can be as widely supported. A pull request has been prepared for review: https://github.com/KhronosGroup/WebGL/pull/831 -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Mon Jan 26 13:42:05 2015 From: khr...@ (Mark Callow) Date: Mon, 26 Jan 2015 13:42:05 -0800 Subject: [Public WebGL] extensions status In-Reply-To: References: Message-ID: <100E1ADB-F0A3-4DCC-9972-298854AE9244@callow.im> > On Jan 14, 2015, at 12:42 AM, Florian B?sch wrote: > > I've gone over the implementation status of extensions and would like to comment on some cases. > > EXT_color_buffer_half_float and WEBGL_color_buffer_float which are in community approved status have dropped off the map (implementations have vanished). This is sort of a problem and I'd like to know if: > Is there any intent to implement those? > If not, should (can) it be dropped from the registry? They were just moved to community approved in November at Mozilla?s request because they were implementing them. I don?t know the current status of those implementations. Mozilla? Even if not exposed by an implementation, these extension documents guide what the browser *should* be doing when allowing float or half-float rendering after OES_texture_{half_,}float is enabled by the application. > EXT_color_buffer_float (draft) hasn't been implemented. > Is there intent to implement it? > If not, should we drop it from the registry? Yes there is intent. This is a WebGL 2.0 extension, equivalent to the above 2 1.0 extensions. I expect every implementation will support it. Without it there is no way to do float rendering in WebGL 2.0. > ... > WEBGL_dynamic_texture (proposal) > Is this specification finalized? > If so, is there intent to implement it? > If so, should it be moved to draft? I have an action item to remove some of the synchronisation stuff that browser vendors say will be difficult to implement. However I put that on hold several months ago because Mozilla said they were experimenting with the extension and we wanted to wait for the lessons from that experiment. I do not know the current status. Something like this is needed for efficient, copy-free, video textures which is especially important on power-constrained devices. I would like to leave this in proposals for a while longer. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Mon Jan 26 13:47:36 2015 From: khr...@ (Mark Callow) Date: Mon, 26 Jan 2015 13:47:36 -0800 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: > On Jan 26, 2015, at 1:38 PM, Florian B?sch wrote: > > I propose to add the extension OES_depth24 to WebGL for these reasons: > ... > The frontbuffer on WebGL is already almost always 24-bit > ... How is this relevant? And isn?t is 32-bit? Alpha defaults to true. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Mon Jan 26 13:53:15 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 22:53:15 +0100 Subject: [Public WebGL] OES_depth24 In-Reply-To: References: Message-ID: On Mon, Jan 26, 2015 at 10:47 PM, Mark Callow wrote: > How is this relevant? > It's relevant because it shows that 24-bit depth buffers are very widely supported. > And isn?t is 32-bit? Alpha defaults to true. > gl.getParameter(gl.DEPTH_BITS) with the frontbuffer will return 99.3% of the time 24-bits, and 0.7% of the time 16 (http://webglstats.com/) regardless of context creation setting of stencil or alpha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Mon Jan 26 13:57:40 2015 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Mon, 26 Jan 2015 22:57:40 +0100 Subject: [Public WebGL] extensions status In-Reply-To: <100E1ADB-F0A3-4DCC-9972-298854AE9244@callow.im> References: <100E1ADB-F0A3-4DCC-9972-298854AE9244@callow.im> Message-ID: On Mon, Jan 26, 2015 at 10:42 PM, Mark Callow wrote: > WEBGL_dynamic_texture (proposal) > > - Is this specification finalized? > - If so, is there intent to implement it? > - If so, should it be moved to draft? > > I have an action item to remove some of the synchronisation stuff that > browser vendors say will be difficult to implement. However I put that on > hold several months ago because Mozilla said they were experimenting with > the extension and we wanted to wait for the lessons from that experiment. I > do not know the current status. > > Something like this is needed for efficient, copy-free, video textures > which is especially important on power-constrained devices. I would like to > leave this in proposals for a while longer. > That's fine. It is quite complex, could this be broken out into some simpler parts? Effectively the video isn't in user-space from a JS programmers point of view. All anybody wants to do is say "this