From cvi...@ Sun May 1 20:40:43 2011 From: cvi...@ (Cedric Vivier) Date: Mon, 2 May 2011 10:40:43 +0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Sat, Apr 30, 2011 at 05:06, Glenn Maynard wrote: >> An application is notified that a context is not supported by returning >> null. >> The Canvas spec needs a minimal change equivalent of adding "or not >> supported _right now_" to the statement above. >> >> getContext spec does not have to even talk about the event at all : > > I think you're misunderstanding the problem. I think we are just misunderstanding each other here ;-) >The WebGL spec defines > getContext as if it owns that API, but that API is part of and defined by > the Canvas spec.? WebGL talks about things like "called for the first time" > and "subsequent calls".? This is all precisely defined by HTML5. I agree, we could remove or simplify this paragraph. > If you ignore the normative spec for getContext, then you can indeed define > getContext to do whatever you want, include dispatching an event, but that's > not a good way to spec an API that makes use of another API. The minor change necessary in the Canvas Spec is the addition of "or null if the context could not be created" at step 6 : "6. Return a new object for contextId or null if the context could not be created, as defined by the specification given for contextId's entry in the WHATWG Wiki CanvasContexts page." There, this would be sufficient to keep both specs in line, isn't it? [action item] The part "as defined by the specification given for contextId" gives us the leeway for any kind of WebGL-specific event dispatching (whether it is for *diagnostics* _or for asynchronous context creation_). This does not break the semantics or interface of getContext as an exception would do (NB: getContext IDL does not have a "throw DOMException" declaration). As Benoit summarized, this is the path of least resistance and the least breaking change. > I disagree with each these.? If throwing an exception causes problems with > debuggers, the debuggers need improvement. Do you imply that moreover changing the Canvas spec and interface we'd also need to change every debugger out there? ;-) > > the problem is that I don't thing *either* way can > be specced properly without some help from HTML5's getContext spec. Yes, we are aware of this. Hence why we are discussing the two possible options with regards to the getContext spec : Option 1 - add possibility or returning null at step 6 - doesn't break current semantics/interface, shouldn't be much trouble to get this upstream hopefully. Option 2 - add possibility of throwing an exception - breaks current semantics/interface, you attempted to push this upstream already and it was not a welcome change. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Sun May 1 21:06:06 2011 From: gle...@ (Glenn Maynard) Date: Mon, 2 May 2011 00:06:06 -0400 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Sun, May 1, 2011 at 11:40 PM, Cedric Vivier wrote: > The minor change necessary in the Canvas Spec is the addition of "or > null if the context could not be created" at step 6 : > > "6. Return a new object for contextId or null if the context could not > be created, as defined by the specification given for contextId's > entry in the WHATWG Wiki CanvasContexts page." It needs a bit more than that. In the failure case, it should probably leave the primary context unchanged, and step 5 would need to be made clear (for example, "has already been invoked on this element for the same contextId and returned successfully ..."). That's not hard, by any means--someone just needs to convince upstream that a change is needed. > Do you imply that moreover changing the Canvas spec and interface we'd > also need to change every debugger out there? ;-) I'm saying that we should report errors using the standard mechanism in the language; use exceptions as they're meant to be used. What you're effectively saying is that the API should avoid exceptions and use error-return-value style (C-style) error reporting because debuggers aren't yet up to snuff. I disagree strongly with that: we should use exceptions normally, and trust that the tools will catch up in due time. > Yes, we are aware of this. Hence why we are discussing the two > possible options with regards to the getContext spec : > Option 1 - add possibility or returning null at step 6 - doesn't break > current semantics/interface, shouldn't be much trouble to get this > upstream hopefully. > Option 2 - add possibility of throwing an exception - breaks current > semantics/interface, you attempted to push this upstream already and > it was not a welcome change. No, upstream was opposed to the idea of getContext reporting the reason for the error at all. This applies to either approach. He argued (briefly--I didn't press the issue, so I don't know how strongly he feels about this) that the reason for the context failing shouldn't even be exposed to scripts. I'd recommend that somebody talk with him (Ian Hickson) directly about this. If you can convince him that an error reporting mechanism is needed in the first place, his opinion on what method to use will be valuable. (I'd prefer somebody directly involved speak with him, since it's an extra level of indirection for me to do it.) -- Glenn Maynard ----------------------------------------------------------- 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 cvi...@ Sun May 1 22:54:09 2011 From: cvi...@ (Cedric Vivier) Date: Mon, 2 May 2011 12:54:09 +0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Mon, May 2, 2011 at 11:06, Glenn Maynard wrote: > On Sun, May 1, 2011 at 11:40 PM, Cedric Vivier wrote: >> "6. Return a new object for contextId or null if the context could not >> be created, as defined by the specification given for contextId's >> entry in the WHATWG Wiki CanvasContexts page." > > It needs a bit more than that. (...) > That's not hard, by any means--someone just needs to convince upstream > that a change is needed. Yes, just a bit more work on this but nothing earth-shattering indeed. Both options need a similar change to Canvas spec wrt context creation steps anyways, I just submitted a more serious proposal : http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031415.html > No, upstream was opposed to the idea of getContext reporting the > reason for the error at all. ?This applies to either approach. ?He > argued (briefly--I didn't press the issue, so I don't know how > strongly he feels about this) that the reason for the context failing > shouldn't even be exposed to scripts. This does not apply to option #1 approach, the application only gets notified the context is not currently available _as usual_ (null), the application does not know the reason. Otherwise I completely agree with this, in fact this is the main reason why I'm strongly leaning towards option #1. I also believe the reason for context creation failure should not be exposed to scripts, except for debugging purposes only, which was the (long forgotten?) rationale for webglcontextcreationerror in the first place iirc (otherwise we would also have statusCode rather than statusMessage only). This implies a context-specific (new contexts can have completely different reporting needs) opt-in (rules exceptions out) mechanism. As it is context-specific it is by definition completely independent from the Canvas spec, it is something that happens within step 6 when Canvas spec gives control to the context spec for the actual context object creation. And that's exactly what we got with 1.0-ratified webglcontextcreationerror. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From joe...@ Sun May 1 23:01:11 2011 From: joe...@ (Joe D Williams) Date: Sun, 1 May 2011 23:01:11 -0700 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <35B23BDDBFA448F6839BE41F02FBA4A1@joe1446a4150a8> Hi All, >From thinking about authioring using @canvas and seeing the HTML5 list about accessibility requirements that are in development, I suggest abandoning @canvas and going for @object. The @object element provides a defined means of fallback if WebGL is not available as well as a more highly developed interface with the DOM. Best Regards, Joe . ----------------------------------------------------------- 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 gle...@ Mon May 2 07:53:52 2011 From: gle...@ (Glenn Maynard) Date: Mon, 2 May 2011 10:53:52 -0400 Subject: [Public WebGL] (summarizing) Canvas.getContext error handling In-Reply-To: References: <790141956.170388.1304082505477.JavaMail.root@cm-mail03.mozilla.org> Message-ID: On Mon, May 2, 2011 at 1:54 AM, Cedric Vivier wrote: >> No, upstream was opposed to the idea of getContext reporting the >> reason for the error at all. ?This applies to either approach. ?He >> argued (briefly--I didn't press the issue, so I don't know how >> strongly he feels about this) that the reason for the context failing >> shouldn't even be exposed to scripts. > > This does not apply to option #1 approach, the application only gets > notified the context is not currently available _as usual_ (null), the > application does not know the reason. > > Otherwise I completely agree with this, in fact this is the main > reason why I'm strongly leaning towards option #1. > I also believe the reason for context creation failure should not be > exposed to scripts, except for debugging purposes only, which was the > (long forgotten?) rationale for webglcontextcreationerror in the first > place iirc (otherwise we would also have statusCode rather than > statusMessage only). Whatever the intended use is, exposed to scripts is exposed to scripts. One of his arguments was a security one, which definitely applies to either method (putting aside whether we agree with the argument itself--that discussion can take place on the whatwg thread). Anyhow, let's wait and see what comes out of whatwg. -- Glenn Maynard ----------------------------------------------------------- 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 bco...@ Mon May 2 13:37:36 2011 From: bco...@ (Brian Cornell) Date: Mon, 2 May 2011 13:37:36 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: So if you are using just an ArrayBuffer with a DataView and want to copy a subset of it (so the rest can be garbage collected, just keep a small part of it), is the recommendation to do the following? var buffer = DataView.buffer; var tmpToCopy = new Uint8Array(buffer, start, end); // Even though the data is not all Uint8s var tmpCopied = new Uint8Array(tmpToCopy); var subBuffer = tmpToCopy.buffer; var subView = new DataView(subBuffer); That seems convoluted and unobvious, especially the fact that I have to treat my many-typed data as all Uint8s just because only TypedArrays have ways to copy data. -Brian On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell wrote: > > On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: > > > > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: > > > >> > >> ... > >> As part of the planned Typed Array API changes to support efficient > >> communication with web workers, the plan is to add convenience methods > >> to copy ArrayBuffers and possibly sub-portions of them. I think we > >> should invest our time in moving those changes forward. > > > > Why is it necessary to have functions to copy ArrayBuffers. Isn't the > copy constructor in the TypedArrays sufficient? > > That's a fair point. During one of the face-to-face meetings with > Mozilla it seemed that if we used transfer-of-ownership for > ArrayBuffers sent via postMessage, then we had to make it easy to copy > them. You're right, though, that the slice() operation can be easily > implemented in pure JavaScript, with the only cost the creation of two > temporary Uint8Arrays. > > Should we just get rid of it and provide non-normative text showing > how it could be implemented? > > -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Mon May 2 14:10:01 2011 From: ben...@ (Ben Vanik) Date: Mon, 2 May 2011 14:10:01 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: Yeah - this is the scenario I'm concerned about, and as you pointed out that code is non-obvious and dirty. Just saying 'wrap it in function and drop it on a prototype' is a cop-out for clean API design. -- Ben Vanik http://www.noxa.org On Mon, May 2, 2011 at 1:37 PM, Brian Cornell wrote: > So if you are using just an ArrayBuffer with a DataView and want to copy a > subset of it (so the rest can be garbage collected, just keep a small part > of it), is the recommendation to do the following? > > var buffer = DataView.buffer; > var tmpToCopy = new Uint8Array(buffer, start, end); // Even though the > data is not all Uint8s > var tmpCopied = new Uint8Array(tmpToCopy); > var subBuffer = tmpToCopy.buffer; > var subView = new DataView(subBuffer); > > That seems convoluted and unobvious, especially the fact that I have to > treat my many-typed data as all Uint8s just because only TypedArrays have > ways to copy data. > > -Brian > > On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell wrote: > >> >> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: >> > >> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: >> > >> >> >> >> ... >> >> As part of the planned Typed Array API changes to support efficient >> >> communication with web workers, the plan is to add convenience methods >> >> to copy ArrayBuffers and possibly sub-portions of them. I think we >> >> should invest our time in moving those changes forward. >> > >> > Why is it necessary to have functions to copy ArrayBuffers. Isn't the >> copy constructor in the TypedArrays sufficient? >> >> That's a fair point. During one of the face-to-face meetings with >> Mozilla it seemed that if we used transfer-of-ownership for >> ArrayBuffers sent via postMessage, then we had to make it easy to copy >> them. You're right, though, that the slice() operation can be easily >> implemented in pure JavaScript, with the only cost the creation of two >> temporary Uint8Arrays. >> >> Should we just get rid of it and provide non-normative text showing >> how it could be implemented? >> >> -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 >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom...@ Tue May 3 08:01:20 2011 From: tom...@ (tom...@) Date: Tue, 3 May 2011 15:01:20 +0000 Subject: [Public WebGL] WebCL In-Reply-To: <1377301503.70891.1303215456873.JavaMail.root@cm-mail03.mozilla.org> References: <1377301503.70891.1303215456873.JavaMail.root@cm-mail03.mozilla.org> Message-ID: <8F9C33DBA4D7C645A1E833BDDDD2CFB3039A05@008-AM1MPN1-013.mgdnok.nokia.com> Benoit, all, I?m expecting a public WebCL mailing list to be set up within the next few days, we?re only waiting for a final ?OK? from the Khronos board. Meanwhile, you may want to try out our WebCL prototype at http://webcl.nokiaresearch.com. Be forewarned that it probably won?t work out of the box, unless you have very recent NVIDIA or AMD display drivers already installed (which may actually be the case for most people on this mailing list, but not the general public). The source code is available under LGPL. We would appreciate any feedback, either directly to me or via the upcoming WebCL public mailing list. Thanks in advance! Best regards, Tomi _____________________ Tomi Aarnio Senior Research Engineer Nokia Research Center Tampere, Finland From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of ext Benoit Jacob Sent: 19. huhtikuuta 2011 15:18 To: jdavis...@ Cc: public webgl Subject: Re: [Public WebGL] WebCL I, too, am eagerly waiting for the creation of a public WebCL list. I know at least 3 people working on WebCL-ish stuff who do not have access to the private list. Benoit ________________________________ When will the mailing list go public? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ala...@ Tue May 3 10:59:15 2011 From: ala...@ (Alan Chaney) Date: Tue, 03 May 2011 10:59:15 -0700 Subject: [Public WebGL] Man page links in WebGL spec. Message-ID: <4DC04273.4080304@mechnicality.com> The man page links in the V1.0 spec appear to be to a MathML document. Is this intentional? eg the man page link within the section: https://www.khronos.org/registry/webgl/specs/1.0/#TEXIMAGE2D_HTML is to: http://www.khronos.org/opengles/sdk/docs/man/glTexImage2D.xml Regards Alan ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue May 3 11:15:59 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 3 May 2011 11:15:59 -0700 Subject: [Public WebGL] Man page links in WebGL spec. In-Reply-To: <4DC04273.4080304@mechnicality.com> References: <4DC04273.4080304@mechnicality.com> Message-ID: On Tue, May 3, 2011 at 10:59 AM, Alan Chaney wrote: > > The man page links in the V1.0 spec appear to be to a MathML document. > > > ?"http://www.oasis-open.org/docbook/xml/mathml/1.1CR1/dbmathml.dtd"> > > Is this intentional? > > eg the man page link within the section: > > https://www.khronos.org/registry/webgl/specs/1.0/#TEXIMAGE2D_HTML > > is to: > > http://www.khronos.org/opengles/sdk/docs/man/glTexImage2D.xml This looks like a bug to me. I think the links should all be of the form: http://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml -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 kbr...@ Tue May 3 11:55:36 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 3 May 2011 11:55:36 -0700 Subject: [Public WebGL] Man page links in WebGL spec. In-Reply-To: References: <4DC04273.4080304@mechnicality.com> Message-ID: On Tue, May 3, 2011 at 11:15 AM, Kenneth Russell wrote: > On Tue, May 3, 2011 at 10:59 AM, Alan Chaney wrote: >> >> The man page links in the V1.0 spec appear to be to a MathML document. >> >> > >> ?"http://www.oasis-open.org/docbook/xml/mathml/1.1CR1/dbmathml.dtd"> >> >> Is this intentional? >> >> eg the man page link within the section: >> >> https://www.khronos.org/registry/webgl/specs/1.0/#TEXIMAGE2D_HTML >> >> is to: >> >> http://www.khronos.org/opengles/sdk/docs/man/glTexImage2D.xml > > This looks like a bug to me. I think the links should all be of the form: > > http://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml I've gone ahead and done a search-and-replace on all of these links in the editors' draft version of the spec. -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 tan...@ Wed May 4 23:16:18 2011 From: tan...@ (tansel halic) Date: Thu, 5 May 2011 02:16:18 -0400 Subject: [Public WebGL] webgl+plugin Message-ID: Hi, Can we share the webgl context with a browser plugin? Does anybody have an idea? tansel -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu May 5 05:01:37 2011 From: bja...@ (Benoit Jacob) Date: Thu, 5 May 2011 05:01:37 -0700 (PDT) Subject: [Public WebGL] webgl+plugin In-Reply-To: Message-ID: <93954343.14783.1304596897181.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> This is not possible at the moment. That would require exposing the WebGL context to the plugin API. Also, many browsers (at least Firefox >= 3.6.4, Chrome, etc) run plugins in a separate process from the content process, so just getting the OpenGL handles would be useless (at least, non portable) without a mechanism for piping GL calls across processes. Finally, if this were possible, assuming that you mean giving to plugins direct access to the underlying OpenGL context, that would allow plugins to crash the content process by issuing e.g. a bad glTexImage2D call, defeating plugin crash isolation mechanisms in place in browsers. For these reasons, it doesn't seem likely to me that we would want to do that. Benoit ----- Original Message ----- Hi, Can we share the webgl context with a browser plugin? Does anybody have an idea? tansel -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Thu May 5 09:12:43 2011 From: cma...@ (Chris Marrin) Date: Thu, 05 May 2011 09:12:43 -0700 Subject: [Public WebGL] webgl+plugin In-Reply-To: References: Message-ID: On May 4, 2011, at 11:16 PM, tansel halic wrote: > Hi, > Can we share the webgl context with a browser plugin? Does anybody have an idea? What are you thinking about? A WebGL context is a Javascript Object, while a plugin is native code. Are you thinking of picking out the native OpenGL (or D3D) context? If so, that's not possible in a portable way. For a given browser there may be ways to use bridge APIs to allow you to create and use the a WebGL object your plugin creates. Again that wouldn't be cross-platform, and it would probably be easier to just use the native 3D API on the platform. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu May 5 17:00:47 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 5 May 2011 17:00:47 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Thu, Apr 28, 2011 at 9:58 AM, Glenn Maynard wrote: > On Thu, Apr 28, 2011 at 12:01 PM, Tim Johansson wrote: >> >> On 4/28/11 5:36 PM, Glenn Maynard wrote: >> >>> Note that blacklisting is different than the device not being able to >>> support WebGL, since device blacklists are updated on the fly in some >>> implementations (Chrome, from what I understand) which can cause WebGL >>> support to go away (or return) after pages are already running. >>> ?Insufficient hardware is unlikely to change at runtime. >>> >> In theory they are different yes, but the chances that the blacklist will >> be updated to remove blacklisting of a gpu while you are looking at a page >> that did not load (because the gpu was blacklisted) are so insignificant >> that for all practical purposes they are the same thing. >> A driver being added to the blacklist cannot affect the context creation >> of a running app since that context has already been created so it only the >> - probably extremely rare - "webgl returns" case that would mater. It would >> have to signal a lost context in the case of "webgl goes away". > > Pages can create WebGL contexts at any time.? For example, you can create a > context in a hidden canvas to perform off-screen image manipulation, which > you pull out of the canvas by other means like canvas.toDataURL.? Long-lived > web apps are now common; I often leave pages loaded in tabs for weeks > without reloading them.? It's very possible for pages to attempt to create a > WebGL context when the GPU is blacklisted, but wasn't when the page was > originally loaded. > > (You can still say that "the contextId 'webgl' is not a supported rendering > context" and return null from step 2, despite this.? It just means that the > contextId would be considered unsupported despite the fact that > WebGLRenderingContext, etc. are present in the window.? That's not a big > deal.) > >> Yes, this all assumed that non recoverable errors would not send a message >> but leave it up to the browser or a troubleshooting page to notify the user >> of why the context creation failed. The app would only know that context >> creation failed and it cannot be solved by trying again. Recoverable errors >> could still get a status message as it would be signalled through context >> lost. > > I suggested that earlier and it was rejected--addressing that objection was > where this proposal originated.? My main underlying goal is just to > reconcile WebGL with HTML5's getContext spec. It sounds like my earlier objection may have caused an impasse. To clarify, the reason for the objection was the following. If the GPU is blacklisted, or some rare and unexpected error happens during OpenGL context creation, then it is important to be able to communicate that fact clearly to the developer, and from there to the end user. If the WebGL implementation can only return null in these situations, with no other channel for reporting programmatically what happened, I think this will lead to frustration by end users who can't get WebGL to work and who can't figure out why. (And further, the WebGL implementor will not easily be able to diagnose what happened.) It's almost inevitable that some kind of unexpected error will occur during WebGL initialization on some hardware/driver configuration. It might be acceptable to return null from the getContext call, report these errors to the JS console and rely on a troubleshooting page to point to them. I much prefer having the option to provide some error message to the application. -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 kbr...@ Thu May 5 17:54:41 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 5 May 2011 17:54:41 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: After looking at Brian's example below and giving this more thought I'm inclined to leave the new slice() method on ArrayBuffer. Doing so avoids the creation of two temporary Uint8Arrays, and I've received requests for this functionality from multiple individuals doing large file I/O, indicating it's worth providing it in the API rather than relying on third-party libraries to provide it. -Ken On Mon, May 2, 2011 at 2:10 PM, Ben Vanik wrote: > Yeah - this is the scenario I'm concerned about, and as you pointed out that > code is non-obvious and dirty. Just saying 'wrap it in function and drop it > on a prototype' is a cop-out for clean API design. > > -- > Ben Vanik > http://www.noxa.org > > > On Mon, May 2, 2011 at 1:37 PM, Brian Cornell wrote: >> >> So if you are using just an ArrayBuffer with a DataView and want to copy a >> subset of it (so the rest can be garbage collected, just keep a small part >> of it), is the recommendation to do the following? >> var buffer = DataView.buffer; >> var tmpToCopy = new Uint8Array(buffer, start, end); ?// Even though the >> data is not all Uint8s >> var tmpCopied = new Uint8Array(tmpToCopy); >> var subBuffer = tmpToCopy.buffer; >> var subView = new DataView(subBuffer); >> That seems convoluted and unobvious, especially the fact that I have to >> treat my many-typed data as all Uint8s just because only TypedArrays have >> ways to copy data. >> -Brian >> >> On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell wrote: >>> >>> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin wrote: >>> > >>> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: >>> > >>> >> >>> >> ... >>> >> As part of the planned Typed Array API changes to support efficient >>> >> communication with web workers, the plan is to add convenience methods >>> >> to copy ArrayBuffers and possibly sub-portions of them. I think we >>> >> should invest our time in moving those changes forward. >>> > >>> > Why is it necessary to have functions to copy ArrayBuffers. Isn't the >>> > copy constructor in the TypedArrays sufficient? >>> >>> That's a fair point. During one of the face-to-face meetings with >>> Mozilla it seemed that if we used transfer-of-ownership for >>> ArrayBuffers sent via postMessage, then we had to make it easy to copy >>> them. You're right, though, that the slice() operation can be easily >>> implemented in pure JavaScript, with the only cost the creation of two >>> temporary Uint8Arrays. >>> >>> Should we just get rid of it and provide non-normative text showing >>> how it could be implemented? >>> >>> -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 >>> ----------------------------------------------------------- >>> >> > > ----------------------------------------------------------- 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 gle...@ Thu May 5 18:09:15 2011 From: gle...@ (Glenn Maynard) Date: Thu, 5 May 2011 21:09:15 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell wrote: > It sounds like my earlier objection may have caused an impasse. Well, we're waiting for a response on whatwg. There's always a response, but it can take a while (overburdened spec editors, I assume). > To clarify, the reason for the objection was the following. If the GPU is > blacklisted, or some rare and unexpected error happens during OpenGL > context creation, then it is important to be able to communicate that > fact clearly to the developer, and from there to the end user. I know what you're saying, but to interject here: hopefully the common case for displaying errors won't be from the developer to the end user, but from the browser directly to the end user. (They aren't doing this at all yet.) FWIW, I don't have any strong opinion either way on this. Personally, I suspect the errors for the real uncommon cases (that is, anything except "GPU blacklisted", "GPU/drivers insufficient" or "browser doesn't support WebGL at all, I think) will probably not give very useful error messages anyway. It'd be nice to get error messages like "D3D surface creation failed: error code", "WebGL not supported; hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia driver", since that would give developers a way to give at least a bare amount of support to their users, but I doubt browsers will ever expose that level of detail. (They don't even expose a real GL_VENDOR.) -- Glenn Maynard ----------------------------------------------------------- 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 mik...@ Thu May 5 23:34:55 2011 From: mik...@ (Mikko Mononen) Date: Fri, 6 May 2011 09:34:55 +0300 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard wrote: > > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell wrote: >> It sounds like my earlier objection may have caused an impasse. > > Well, we're waiting for a response on whatwg. ?There's always a > response, but it can take a while (overburdened spec editors, I > assume). > >> To clarify, the reason for the objection was the following. If the GPU is >> blacklisted, or some rare and unexpected error happens during OpenGL >> context creation, then it is important to be able to communicate that >> fact clearly to the developer, and from there to the end user. > > I know what you're saying, but to interject here: hopefully the common > case for displaying errors won't be from the developer to the end > user, but from the browser directly to the end user. ?(They aren't > doing this at all yet.) As a developer I have to disagree with the idea of browser directly talking to the user. IMHO This is different situation that a missing plugin. Currently the situation is that a lot of the folks coming to a webgl site can indeed see the content (in our case I think it is something like >60%). A great deal of the rest of users can be encourage to upgrade to a more fresh browser to make things work. That leaves us about 10% of users who either have old or weird os/driver combination. Those people need to be handled with developers support, because it generally is too complicated for them to triage the problem themselves, or it is too complicated to write comprehensive guide how to fix things*. There is no way my mum could understand what to do if she gets "Cannot initialize webgl" alert box when entering a home planner site. If simple request of upgrading a browser on developers site cannot fix the problem, then the user needs to be channeled to the developer support, and in that case the developer should be able to have as much information as possible (such as the messages explained below) so the the support can explain the user why the problem exists. Most of the time the answer will be "you have too old computer/os", but it is nice to be able to tell that in person, if that is the way the company wants to handle support. *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I do not dare to direct people there. Any change to be able to embed the script to your own site? > FWIW, I don't have any strong opinion either way on this. ?Personally, > I suspect the errors for the real uncommon cases (that is, anything > except "GPU blacklisted", "GPU/drivers insufficient" or "browser > doesn't support WebGL at all, I think) will probably not give very > useful error messages anyway. ?It'd be nice to get error messages like > "D3D surface creation failed: error code", "WebGL not supported; > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia > driver", since that would give developers a way to give at least a > bare amount of support to their users, but I doubt browsers will ever > expose that level of detail. ?(They don't even expose a real > GL_VENDOR.) > > -- > Glenn Maynard > ----------------------------------------------------------- > 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 > ----------------------------------------------------------- > > -- Mikko Mononen, Software Engineer http://tinkercad.com?- Solid modeling for artists & makers ----------------------------------------------------------- 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 gle...@ Fri May 6 00:10:16 2011 From: gle...@ (Glenn Maynard) Date: Fri, 6 May 2011 03:10:16 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Fri, May 6, 2011 at 2:34 AM, Mikko Mononen wrote: >> I know what you're saying, but to interject here: hopefully the common >> case for displaying errors won't be from the developer to the end >> user, but from the browser directly to the end user. ?(They aren't >> doing this at all yet.) > > As a developer I have to disagree with the idea of browser directly > talking to the user. IMHO This is different situation that a missing > plugin. > > Currently the situation is that a lot of the folks coming to a webgl > site can indeed see the content (in our case I think it is something > like >60%). A great deal of the rest of users can be encourage to > upgrade to a more fresh browser to make things work. That leaves us > about 10% of users who either have old or weird os/driver combination. > Those people need to be handled with developers support, because it > generally is too complicated for them to triage the problem > themselves, or it is too complicated to write comprehensive guide how > to fix things*. It's not the job of every person running a webpage to give end-user tech support. If I'm expected, as a web developer, to be the first line of support for this sort of thing, that's a serious deterrent to using it at all. Browsers can do a lot to help users, because browser vendors already know a lot about the problems people are hitting, and they're the first to find out about new issues. > There is no way my mum could understand what to do if she gets "Cannot > initialize webgl" alert box when entering a home planner site. That's not what a browser troubleshooting dialog would look like, of course--and people at a home planner site probably won't know what to do, either. On the other hand, if the browser knows that it's disabling WebGL because the user is running old drivers that are known to crash systems, and if it knows that newer versions of those drivers fix the problem, it can point the user right at the GPU vendor's site for drivers. It'd take me a lot more work to do that; I don't know any of those things until I spend time troubleshooting and researching the problem; and once I figure it out I'm going to do the exact same thing the browser would have done. > If simple request of upgrading a browser on developers site cannot fix > the problem, then the user needs to be channeled to the developer > support, and in that case the developer should be able to have as much > information as possible (such as the messages explained below) It's always nice as a developer to have more information, but as I said, even with a mechanism in place to provide this information (which there currently is, we're just trying to fix it up), I have doubts about vendors actually putting enough information in these messages to be useful to developers. Browser vendors are defensive about what information they expose to scripts. If no production browsers will ever say anything more than "unsupported GPU", it's not going to be very useful to anyone. (Do any current browsers expose anything useful to webglcontextcreationerror yet--or anything at all, for that matter? I've never seen any information in it.) -- Glenn Maynard ----------------------------------------------------------- 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 gma...@ Fri May 6 00:13:54 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 6 May 2011 00:13:54 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Thu, May 5, 2011 at 11:34 PM, Mikko Mononen wrote: > > On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard wrote: > > > > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell wrote: > >> It sounds like my earlier objection may have caused an impasse. > > > > Well, we're waiting for a response on whatwg. There's always a > > response, but it can take a while (overburdened spec editors, I > > assume). > > > >> To clarify, the reason for the objection was the following. If the GPU > is > >> blacklisted, or some rare and unexpected error happens during OpenGL > >> context creation, then it is important to be able to communicate that > >> fact clearly to the developer, and from there to the end user. > > > > I know what you're saying, but to interject here: hopefully the common > > case for displaying errors won't be from the developer to the end > > user, but from the browser directly to the end user. (They aren't > > doing this at all yet.) > > As a developer I have to disagree with the idea of browser directly > talking to the user. IMHO This is different situation that a missing > plugin. > > Currently the situation is that a lot of the folks coming to a webgl > site can indeed see the content (in our case I think it is something > like >60%). A great deal of the rest of users can be encourage to > upgrade to a more fresh browser to make things work. That leaves us > about 10% of users who either have old or weird os/driver combination. > Those people need to be handled with developers support, because it > generally is too complicated for them to triage the problem > themselves, or it is too complicated to write comprehensive guide how > to fix things*. > > There is no way my mum could understand what to do if she gets "Cannot > initialize webgl" alert box when entering a home planner site. If > simple request of upgrading a browser on developers site cannot fix > the problem, then the user needs to be channeled to the developer > support, and in that case the developer should be able to have as much > information as possible (such as the messages explained below) so the > the support can explain the user why the problem exists. Most of the > time the answer will be "you have too old computer/os", but it is nice > to be able to tell that in person, if that is the way the company > wants to handle support. > > *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I > do not dare to direct people there. Any change to be able to embed the > script to your own site? > What do you need fixed and we'll get it fixed. It would be bad IMO for developers to put this on they're own site because they are unlikely to update it as new browsers, pages and platforms appear. It's also unlikely that most devs > > > > FWIW, I don't have any strong opinion either way on this. Personally, > > I suspect the errors for the real uncommon cases (that is, anything > > except "GPU blacklisted", "GPU/drivers insufficient" or "browser > > doesn't support WebGL at all, I think) will probably not give very > > useful error messages anyway. It'd be nice to get error messages like > > "D3D surface creation failed: error code", "WebGL not supported; > > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia > > driver", since that would give developers a way to give at least a > > bare amount of support to their users, but I doubt browsers will ever > > expose that level of detail. (They don't even expose a real > > GL_VENDOR.) > > > > -- > > Glenn Maynard > > ----------------------------------------------------------- > > 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 > > ----------------------------------------------------------- > > > > > > > > -- > Mikko Mononen, Software Engineer > http://tinkercad.com - Solid modeling for artists & makers > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mik...@ Fri May 6 02:17:56 2011 From: mik...@ (Mikko Mononen) Date: Fri, 6 May 2011 12:17:56 +0300 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: Ideally I would like to include a script from http://get.webgl.org, add a div to my webgl fault page, call init() with div id, and make the script do it's magic to populate the div with similar content that you get currently when you visit the page. That way the script could be always up to date, and I could give instructions directly on my sites fault page. In our experience, we loose users at each step that needs to be done to resolve a problem. I'll check if we track on how many users fail webgl and how many of them actually tries to seek help. --mikko On Fri, May 6, 2011 at 10:13 AM, Gregg Tavares (wrk) wrote: > > > On Thu, May 5, 2011 at 11:34 PM, Mikko Mononen wrote: >> >> On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard wrote: >> > >> > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell wrote: >> >> It sounds like my earlier objection may have caused an impasse. >> > >> > Well, we're waiting for a response on whatwg. ?There's always a >> > response, but it can take a while (overburdened spec editors, I >> > assume). >> > >> >> To clarify, the reason for the objection was the following. If the GPU >> >> is >> >> blacklisted, or some rare and unexpected error happens during OpenGL >> >> context creation, then it is important to be able to communicate that >> >> fact clearly to the developer, and from there to the end user. >> > >> > I know what you're saying, but to interject here: hopefully the common >> > case for displaying errors won't be from the developer to the end >> > user, but from the browser directly to the end user. ?(They aren't >> > doing this at all yet.) >> >> As a developer I have to disagree with the idea of browser directly >> talking to the user. IMHO This is different situation that a missing >> plugin. >> >> Currently the situation is that a lot of the folks coming to a webgl >> site can indeed see the content (in our case I think it is something >> like >60%). A great deal of the rest of users can be encourage to >> upgrade to a more fresh browser to make things work. That leaves us >> about 10% of users who either have old or weird os/driver combination. >> Those people need to be handled with developers support, because it >> generally is too complicated for them to triage the problem >> themselves, or it is too complicated to write comprehensive guide how >> to fix things*. >> >> There is no way my mum could understand what to do if she gets "Cannot >> initialize webgl" alert box when entering a home planner site. If >> simple request of upgrading a browser on developers site cannot fix >> the problem, then the user needs to be channeled to the developer >> support, and in that case the developer should be able to have as much >> information as possible (such as the messages explained below) so the >> the support can explain the user why the problem exists. Most of the >> time the answer will be "you have too old computer/os", but it is nice >> to be able to tell that in person, if that is the way the company >> wants to handle support. >> >> *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I >> do not dare to direct people there. Any change to be able to embed the >> script to your own site? > > What do you need fixed and we'll get it fixed. > It would be bad IMO for developers to put this on they're own site because > they are unlikely to update it as new browsers, pages and platforms appear. > It's also unlikely that most devs > >> >> > FWIW, I don't have any strong opinion either way on this. ?Personally, >> > I suspect the errors for the real uncommon cases (that is, anything >> > except "GPU blacklisted", "GPU/drivers insufficient" or "browser >> > doesn't support WebGL at all, I think) will probably not give very >> > useful error messages anyway. ?It'd be nice to get error messages like >> > "D3D surface creation failed: error code", "WebGL not supported; >> > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia >> > driver", since that would give developers a way to give at least a >> > bare amount of support to their users, but I doubt browsers will ever >> > expose that level of detail. ?(They don't even expose a real >> > GL_VENDOR.) >> > >> > -- >> > Glenn Maynard >> > ----------------------------------------------------------- >> > 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 >> > ----------------------------------------------------------- >> > >> > >> >> >> >> -- >> Mikko Mononen, Software Engineer >> http://tinkercad.com?- Solid modeling for artists & makers >> >> ----------------------------------------------------------- >> 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 >> ----------------------------------------------------------- >> > > -- Mikko Mononen, Software Engineer http://tinkercad.com?- Solid modeling for artists & makers ----------------------------------------------------------- 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 mik...@ Fri May 6 02:41:20 2011 From: mik...@ (Mikko Mononen) Date: Fri, 6 May 2011 12:41:20 +0300 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: I understand your point of view, but I don't completely agree. I just have a feeling that tech details and practice do not completely meet here. I don't have a better argument to back up my thoughts, though. Do you have a practical example how the user/browser/developer would interact in the case when for example the driver is blacklisted? Are there any previous similar new tech transitions which would have some practical data or "post mortem" available? Installing a plugin to get your website to work is closest that comes to my mind. I don't want to distract you guys any further. I humbly ask to bring someone into the discussion (i.e. Google body browser folks) who has struggled with the end user support. --mikko On Fri, May 6, 2011 at 10:10 AM, Glenn Maynard wrote: > On Fri, May 6, 2011 at 2:34 AM, Mikko Mononen wrote: >>> I know what you're saying, but to interject here: hopefully the common >>> case for displaying errors won't be from the developer to the end >>> user, but from the browser directly to the end user. ?(They aren't >>> doing this at all yet.) >> >> As a developer I have to disagree with the idea of browser directly >> talking to the user. IMHO This is different situation that a missing >> plugin. >> >> Currently the situation is that a lot of the folks coming to a webgl >> site can indeed see the content (in our case I think it is something >> like >60%). A great deal of the rest of users can be encourage to >> upgrade to a more fresh browser to make things work. That leaves us >> about 10% of users who either have old or weird os/driver combination. >> Those people need to be handled with developers support, because it >> generally is too complicated for them to triage the problem >> themselves, or it is too complicated to write comprehensive guide how >> to fix things*. > > It's not the job of every person running a webpage to give end-user > tech support. ?If I'm expected, as a web developer, to be the first > line of support for this sort of thing, that's a serious deterrent to > using it at all. ?Browsers can do a lot to help users, because browser > vendors already know a lot about the problems people are hitting, and > they're the first to find out about new issues. > >> There is no way my mum could understand what to do if she gets "Cannot >> initialize webgl" alert box when entering a home planner site. > > That's not what a browser troubleshooting dialog would look like, of > course--and people at a home planner site probably won't know what to > do, either. ?On the other hand, if the browser knows that it's > disabling WebGL because the user is running old drivers that are known > to crash systems, and if it knows that newer versions of those drivers > fix the problem, it can point the user right at the GPU vendor's site > for drivers. ?It'd take me a lot more work to do that; I don't know > any of those things until I spend time troubleshooting and researching > the problem; and once I figure it out I'm going to do the exact same > thing the browser would have done. > >> ?If simple request of upgrading a browser on developers site cannot fix >> the problem, then the user needs to be channeled to the developer >> support, and in that case the developer should be able to have as much >> information as possible (such as the messages explained below) > > It's always nice as a developer to have more information, but as I > said, even with a mechanism in place to provide this information > (which there currently is, we're just trying to fix it up), I have > doubts about vendors actually putting enough information in these > messages to be useful to developers. ?Browser vendors are defensive > about what information they expose to scripts. ?If no production > browsers will ever say anything more than "unsupported GPU", it's not > going to be very useful to anyone. > > (Do any current browsers expose anything useful to > webglcontextcreationerror yet--or anything at all, for that matter? > I've never seen any information in it.) > > -- > Glenn Maynard > -- Mikko Mononen, Software Engineer http://tinkercad.com?- Solid modeling for artists & makers ----------------------------------------------------------- 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 cvi...@ Fri May 6 02:59:03 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 6 May 2011 16:59:03 +0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Fri, May 6, 2011 at 16:41, Mikko Mononen wrote: > Do you have a practical example how the user/browser/developer would > interact in the case when for example the driver is blacklisted? I posted an example in the other thread of how a browser might present a known WebGL issue, an unobstrusive infobar at the top of the tab : == This web page could not initialize WebGL (what is this?) because of obsolete graphics drivers. [Upgrade driver now] [Do it later] [Forget it] == In other words, it could be indeed something similar to what most browsers already do when a plugin (eg Flash) is not available and needs to be installed, or when the browser requires user action to authorize a script feature (eg. geolocation API). User-friendly troubleshooting of WebGL is something that browsers do not handle at all currently, we will hopefully improve this situation. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From dan...@ Fri May 6 09:07:32 2011 From: dan...@ (Daniel Koch) Date: Fri, 6 May 2011 12:07:32 -0400 Subject: [Public WebGL] Looking for webgl applications which use vertex textures Message-ID: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> Hi folks, We're currently implementing support for vertex texture lookups in ANGLE and are looking for additional content to test the implementation. If you have any Webgl applications which either require vertex texture fetch, or will take advantage of this when advertised, can you please provide a link to the page in the ANGLE issue tracker: http://code.google.com/p/angleproject/issues/detail?id=95 Thanks, Daniel --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri May 6 12:30:20 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 6 May 2011 12:30:20 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> Message-ID: On Fri, May 6, 2011 at 2:17 AM, Mikko Mononen wrote: > Ideally I would like to include a script from http://get.webgl.org, > add a div to my webgl fault page, call init() with div id, and make > the script do it's magic to populate the div with similar content that > you get currently when you visit the page. That way the script could > be always up to date, and I could give instructions directly on my > sites fault page. > There's no way get.webgl.org can handle the traffic for every WebGL page on the planet including a script. Just detect and send them there. That way only people for whom webgl is not working will make it there and that number should get smaller and smaller over time. > > In our experience, we loose users at each step that needs to be done > to resolve a problem. I'll check if we track on how many users fail > webgl and how many of them actually tries to seek help. > > > --mikko > > > On Fri, May 6, 2011 at 10:13 AM, Gregg Tavares (wrk) > wrote: > > > > > > On Thu, May 5, 2011 at 11:34 PM, Mikko Mononen > wrote: > >> > >> On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard wrote: > >> > > >> > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell > wrote: > >> >> It sounds like my earlier objection may have caused an impasse. > >> > > >> > Well, we're waiting for a response on whatwg. There's always a > >> > response, but it can take a while (overburdened spec editors, I > >> > assume). > >> > > >> >> To clarify, the reason for the objection was the following. If the > GPU > >> >> is > >> >> blacklisted, or some rare and unexpected error happens during OpenGL > >> >> context creation, then it is important to be able to communicate that > >> >> fact clearly to the developer, and from there to the end user. > >> > > >> > I know what you're saying, but to interject here: hopefully the common > >> > case for displaying errors won't be from the developer to the end > >> > user, but from the browser directly to the end user. (They aren't > >> > doing this at all yet.) > >> > >> As a developer I have to disagree with the idea of browser directly > >> talking to the user. IMHO This is different situation that a missing > >> plugin. > >> > >> Currently the situation is that a lot of the folks coming to a webgl > >> site can indeed see the content (in our case I think it is something > >> like >60%). A great deal of the rest of users can be encourage to > >> upgrade to a more fresh browser to make things work. That leaves us > >> about 10% of users who either have old or weird os/driver combination. > >> Those people need to be handled with developers support, because it > >> generally is too complicated for them to triage the problem > >> themselves, or it is too complicated to write comprehensive guide how > >> to fix things*. > >> > >> There is no way my mum could understand what to do if she gets "Cannot > >> initialize webgl" alert box when entering a home planner site. If > >> simple request of upgrading a browser on developers site cannot fix > >> the problem, then the user needs to be channeled to the developer > >> support, and in that case the developer should be able to have as much > >> information as possible (such as the messages explained below) so the > >> the support can explain the user why the problem exists. Most of the > >> time the answer will be "you have too old computer/os", but it is nice > >> to be able to tell that in person, if that is the way the company > >> wants to handle support. > >> > >> *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I > >> do not dare to direct people there. Any change to be able to embed the > >> script to your own site? > > > > What do you need fixed and we'll get it fixed. > > It would be bad IMO for developers to put this on they're own site > because > > they are unlikely to update it as new browsers, pages and platforms > appear. > > It's also unlikely that most devs > > > >> > >> > FWIW, I don't have any strong opinion either way on this. Personally, > >> > I suspect the errors for the real uncommon cases (that is, anything > >> > except "GPU blacklisted", "GPU/drivers insufficient" or "browser > >> > doesn't support WebGL at all, I think) will probably not give very > >> > useful error messages anyway. It'd be nice to get error messages like > >> > "D3D surface creation failed: error code", "WebGL not supported; > >> > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia > >> > driver", since that would give developers a way to give at least a > >> > bare amount of support to their users, but I doubt browsers will ever > >> > expose that level of detail. (They don't even expose a real > >> > GL_VENDOR.) > >> > > >> > -- > >> > Glenn Maynard > >> > ----------------------------------------------------------- > >> > 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 > >> > ----------------------------------------------------------- > >> > > >> > > >> > >> > >> > >> -- > >> Mikko Mononen, Software Engineer > >> http://tinkercad.com - Solid modeling for artists & makers > >> > >> ----------------------------------------------------------- > >> 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 > >> ----------------------------------------------------------- > >> > > > > > > > > -- > Mikko Mononen, Software Engineer > http://tinkercad.com - Solid modeling for artists & makers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri May 6 13:34:32 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 6 May 2011 13:34:32 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: On Fri, May 6, 2011 at 12:46 PM, R?mi Arnaud wrote: > Google is hosting jquery and other scripts for the universe, maybe they can > be convinced to host a webgl script? > Maybe. Of course you know if that server ever goes down then every page using that jquery directly would go down as well. Since we're only talking about a script that helps users who CAN'T run webgl it doesn't seem worth the trade off that 60% of your users and climbing have to download a script they don't need (ie, WebGL works for them so they don't need the script) > > - Remi > > ------------------------------ > *From: * "Gregg Tavares (wrk)" > *Sender: * owner-public_webgl...@ > *Date: *Fri, 6 May 2011 12:30:20 -0700 > *To: *Mikko Mononen > *Cc: *Glenn Maynard; Kenneth Russell; Tim > Johansson; Cedric Vivier; Mark > Callow; > *Subject: *Re: [Public WebGL] Re: [whatwg] Canvas.getContext error > handling > > > > On Fri, May 6, 2011 at 2:17 AM, Mikko Mononen wrote: > >> Ideally I would like to include a script from http://get.webgl.org, >> add a div to my webgl fault page, call init() with div id, and make >> the script do it's magic to populate the div with similar content that >> you get currently when you visit the page. That way the script could >> be always up to date, and I could give instructions directly on my >> sites fault page. >> > > There's no way get.webgl.org can handle the traffic for every WebGL page > on the planet including a script. > > Just detect and send them there. That way only people for whom webgl is not > working will make it there and that number should get smaller and smaller > over time. > > >> >> In our experience, we loose users at each step that needs to be done >> to resolve a problem. I'll check if we track on how many users fail >> webgl and how many of them actually tries to seek help. >> >> >> --mikko >> >> >> On Fri, May 6, 2011 at 10:13 AM, Gregg Tavares (wrk) >> wrote: >> > >> > >> > On Thu, May 5, 2011 at 11:34 PM, Mikko Mononen >> wrote: >> >> >> >> On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard wrote: >> >> > >> >> > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell >> wrote: >> >> >> It sounds like my earlier objection may have caused an impasse. >> >> > >> >> > Well, we're waiting for a response on whatwg. There's always a >> >> > response, but it can take a while (overburdened spec editors, I >> >> > assume). >> >> > >> >> >> To clarify, the reason for the objection was the following. If the >> GPU >> >> >> is >> >> >> blacklisted, or some rare and unexpected error happens during OpenGL >> >> >> context creation, then it is important to be able to communicate >> that >> >> >> fact clearly to the developer, and from there to the end user. >> >> > >> >> > I know what you're saying, but to interject here: hopefully the >> common >> >> > case for displaying errors won't be from the developer to the end >> >> > user, but from the browser directly to the end user. (They aren't >> >> > doing this at all yet.) >> >> >> >> As a developer I have to disagree with the idea of browser directly >> >> talking to the user. IMHO This is different situation that a missing >> >> plugin. >> >> >> >> Currently the situation is that a lot of the folks coming to a webgl >> >> site can indeed see the content (in our case I think it is something >> >> like >60%). A great deal of the rest of users can be encourage to >> >> upgrade to a more fresh browser to make things work. That leaves us >> >> about 10% of users who either have old or weird os/driver combination. >> >> Those people need to be handled with developers support, because it >> >> generally is too complicated for them to triage the problem >> >> themselves, or it is too complicated to write comprehensive guide how >> >> to fix things*. >> >> >> >> There is no way my mum could understand what to do if she gets "Cannot >> >> initialize webgl" alert box when entering a home planner site. If >> >> simple request of upgrading a browser on developers site cannot fix >> >> the problem, then the user needs to be channeled to the developer >> >> support, and in that case the developer should be able to have as much >> >> information as possible (such as the messages explained below) so the >> >> the support can explain the user why the problem exists. Most of the >> >> time the answer will be "you have too old computer/os", but it is nice >> >> to be able to tell that in person, if that is the way the company >> >> wants to handle support. >> >> >> >> *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I >> >> do not dare to direct people there. Any change to be able to embed the >> >> script to your own site? >> > >> > What do you need fixed and we'll get it fixed. >> > It would be bad IMO for developers to put this on they're own site >> because >> > they are unlikely to update it as new browsers, pages and platforms >> appear. >> > It's also unlikely that most devs >> > >> >> >> >> > FWIW, I don't have any strong opinion either way on this. >> Personally, >> >> > I suspect the errors for the real uncommon cases (that is, anything >> >> > except "GPU blacklisted", "GPU/drivers insufficient" or "browser >> >> > doesn't support WebGL at all, I think) will probably not give very >> >> > useful error messages anyway. It'd be nice to get error messages >> like >> >> > "D3D surface creation failed: error code", "WebGL not supported; >> >> > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia >> >> > driver", since that would give developers a way to give at least a >> >> > bare amount of support to their users, but I doubt browsers will ever >> >> > expose that level of detail. (They don't even expose a real >> >> > GL_VENDOR.) >> >> > >> >> > -- >> >> > Glenn Maynard >> >> > ----------------------------------------------------------- >> >> > 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 >> >> > ----------------------------------------------------------- >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Mikko Mononen, Software Engineer >> >> http://tinkercad.com - Solid modeling for artists & makers >> >> >> >> ----------------------------------------------------------- >> >> 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 >> >> ----------------------------------------------------------- >> >> >> > >> > >> >> >> >> -- >> Mikko Mononen, Software Engineer >> http://tinkercad.com - Solid modeling for artists & makers >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri May 6 13:49:20 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 6 May 2011 13:49:20 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: On Thu, May 5, 2011 at 5:54 PM, Kenneth Russell wrote: > > After looking at Brian's example below and giving this more thought > I'm inclined to leave the new slice() method on ArrayBuffer. Doing so > avoids the creation of two temporary Uint8Arrays, and I've received > requests for this functionality from multiple individuals doing large > file I/O, indicating it's worth providing it in the API rather than > relying on third-party libraries to provide it. > I don't care either way but I'm missing the issue // This is the original buffer. With or without slice you'll have this var buffer = DataView.buffer; // This is just a VIEW to the original buffer. var tmpToCopy = new Uint8Array(buffer, start, end); // Even though the data is not all Uint8s // This is a copy. This is actually the same copy that slice would make. var tmpCopied = new Uint8Array(tmpToCopy); // This is a reference to the new buffer. var subBuffer = tmpToCopy.buffer; // This is a VIEW on the buffer. We still only have 2 buffers. The original and the copied subsection. var subView = new DataView(subBuffer); There's no more or less copies than slice. There's just a couple of small temp VIEWs. > -Ken > > On Mon, May 2, 2011 at 2:10 PM, Ben Vanik wrote: > > Yeah - this is the scenario I'm concerned about, and as you pointed out > that > > code is non-obvious and dirty. Just saying 'wrap it in function and drop > it > > on a prototype' is a cop-out for clean API design. > > > > -- > > Ben Vanik > > http://www.noxa.org > > > > > > On Mon, May 2, 2011 at 1:37 PM, Brian Cornell > wrote: > >> > >> So if you are using just an ArrayBuffer with a DataView and want to copy > a > >> subset of it (so the rest can be garbage collected, just keep a small > part > >> of it), is the recommendation to do the following? > >> var buffer = DataView.buffer; > >> var tmpToCopy = new Uint8Array(buffer, start, end); // Even though the > >> data is not all Uint8s > >> var tmpCopied = new Uint8Array(tmpToCopy); > >> var subBuffer = tmpToCopy.buffer; > >> var subView = new DataView(subBuffer); > >> That seems convoluted and unobvious, especially the fact that I have to > >> treat my many-typed data as all Uint8s just because only TypedArrays > have > >> ways to copy data. > >> -Brian > >> > >> On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell > wrote: > >>> > >>> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin > wrote: > >>> > > >>> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: > >>> > > >>> >> > >>> >> ... > >>> >> As part of the planned Typed Array API changes to support efficient > >>> >> communication with web workers, the plan is to add convenience > methods > >>> >> to copy ArrayBuffers and possibly sub-portions of them. I think we > >>> >> should invest our time in moving those changes forward. > >>> > > >>> > Why is it necessary to have functions to copy ArrayBuffers. Isn't the > >>> > copy constructor in the TypedArrays sufficient? > >>> > >>> That's a fair point. During one of the face-to-face meetings with > >>> Mozilla it seemed that if we used transfer-of-ownership for > >>> ArrayBuffers sent via postMessage, then we had to make it easy to copy > >>> them. You're right, though, that the slice() operation can be easily > >>> implemented in pure JavaScript, with the only cost the creation of two > >>> temporary Uint8Arrays. > >>> > >>> Should we just get rid of it and provide non-normative text showing > >>> how it could be implemented? > >>> > >>> -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 > >>> ----------------------------------------------------------- > >>> > >> > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kos...@ Fri May 6 15:46:02 2011 From: kos...@ (David Sheets) Date: Fri, 6 May 2011 15:46:02 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: > Maybe. Of course you know if that server ever goes down then every page > using that jquery directly would go down as well. > Since we're only talking about a script that helps users who CAN'T run webgl > it doesn't seem worth the trade off that 60% of your users and climbing have > to download a script they don't need (ie, WebGL works for them so they don't > need the script) The script can be dynamically loaded when WebGL fails. The loading stub would be static and quite small. The key is that web developers would like a reference to a troubleshooting resource that reflects the current state of WebGL support. The current solution is to make that reference in the form of a web site that users must be linked to. These users will consume get.webgl.org resources and will potentially have left the application site or given up on WebGL altogether. The proposed solution is to make the reference in the form of a conditionally downloaded, centrally maintained diagnostic script that lets users stay on an application site. The alternative is that the small WebGL players use get.webgl.org and suffer the UX and friction while the big WebGL players actively maintain their own diagnostics (at considerable expense) for better UX and lower friction. This harms adoption. Why isn't get.webgl.org open source? Who are its current maintainers? Why don't we produce a little conditional include snippet for authors to use? >> >> - Remi >> >> ________________________________ >> From: "Gregg Tavares (wrk)" >> Sender: owner-public_webgl...@ >> Date: Fri, 6 May 2011 12:30:20 -0700 >> To: Mikko Mononen >> Cc: Glenn Maynard; Kenneth Russell; Tim >> Johansson; Cedric Vivier; Mark >> Callow; >> Subject: Re: [Public WebGL] Re: [whatwg] Canvas.getContext error handling >> >> >> On Fri, May 6, 2011 at 2:17 AM, Mikko Mononen wrote: >>> >>> Ideally I would like to include a script from http://get.webgl.org, >>> add a div to my webgl fault page, call init() with div id, and make >>> the script do it's magic to populate the div with similar content that >>> you get currently when you visit the page. That way the script could >>> be always up to date, and I could give instructions directly on my >>> sites fault page. >> >> There's no way get.webgl.org can handle the traffic for every WebGL page >> on the planet including a script. >> Just detect and send them there. That way only people for whom webgl is >> not working will make it there and that number should get smaller and >> smaller over time. >> >>> >>> In our experience, we loose users at each step that needs to be done >>> to resolve a problem. I'll check if we track on how many users fail >>> webgl and how many of them actually tries to seek help. >>> >>> >>> --mikko >>> >>> >>> On Fri, May 6, 2011 at 10:13 AM, Gregg Tavares (wrk) >>> wrote: >>> > >>> > >>> > On Thu, May 5, 2011 at 11:34 PM, Mikko Mononen >>> > wrote: >>> >> >>> >> On Fri, May 6, 2011 at 4:09 AM, Glenn Maynard wrote: >>> >> > >>> >> > On Thu, May 5, 2011 at 8:00 PM, Kenneth Russell >>> >> > wrote: >>> >> >> It sounds like my earlier objection may have caused an impasse. >>> >> > >>> >> > Well, we're waiting for a response on whatwg. ?There's always a >>> >> > response, but it can take a while (overburdened spec editors, I >>> >> > assume). >>> >> > >>> >> >> To clarify, the reason for the objection was the following. If the >>> >> >> GPU >>> >> >> is >>> >> >> blacklisted, or some rare and unexpected error happens during >>> >> >> OpenGL >>> >> >> context creation, then it is important to be able to communicate >>> >> >> that >>> >> >> fact clearly to the developer, and from there to the end user. >>> >> > >>> >> > I know what you're saying, but to interject here: hopefully the >>> >> > common >>> >> > case for displaying errors won't be from the developer to the end >>> >> > user, but from the browser directly to the end user. ?(They aren't >>> >> > doing this at all yet.) >>> >> >>> >> As a developer I have to disagree with the idea of browser directly >>> >> talking to the user. IMHO This is different situation that a missing >>> >> plugin. >>> >> >>> >> Currently the situation is that a lot of the folks coming to a webgl >>> >> site can indeed see the content (in our case I think it is something >>> >> like >60%). A great deal of the rest of users can be encourage to >>> >> upgrade to a more fresh browser to make things work. That leaves us >>> >> about 10% of users who either have old or weird os/driver combination. >>> >> Those people need to be handled with developers support, because it >>> >> generally is too complicated for them to triage the problem >>> >> themselves, or it is too complicated to write comprehensive guide how >>> >> to fix things*. >>> >> >>> >> There is no way my mum could understand what to do if she gets "Cannot >>> >> initialize webgl" alert box when entering a home planner site. If >>> >> simple request of upgrading a browser on developers site cannot fix >>> >> the problem, then the user needs to be channeled to the developer >>> >> support, and in that case the developer should be able to have as much >>> >> information as possible (such as the messages explained below) so the >>> >> the support can explain the user why the problem exists. Most of the >>> >> time the answer will be "you have too old computer/os", but it is nice >>> >> to be able to tell that in person, if that is the way the company >>> >> wants to handle support. >>> >> >>> >> *) http://get.webgl.org/troubleshooting/ is currently so dodgy that I >>> >> do not dare to direct people there. Any change to be able to embed the >>> >> script to your own site? >>> > >>> > What do you need fixed and we'll get it fixed. >>> > It would be bad IMO for developers to put this on they're own site >>> > because >>> > they are unlikely to update it as new browsers, pages and platforms >>> > appear. >>> > It's also unlikely that most devs >>> > >>> >> >>> >> > FWIW, I don't have any strong opinion either way on this. >>> >> > ?Personally, >>> >> > I suspect the errors for the real uncommon cases (that is, anything >>> >> > except "GPU blacklisted", "GPU/drivers insufficient" or "browser >>> >> > doesn't support WebGL at all, I think) will probably not give very >>> >> > useful error messages anyway. ?It'd be nice to get error messages >>> >> > like >>> >> > "D3D surface creation failed: error code", "WebGL not supported; >>> >> > hardware ID: Voodoo 3" or "GPU blacklisted; reason: crashy nVidia >>> >> > driver", since that would give developers a way to give at least a >>> >> > bare amount of support to their users, but I doubt browsers will >>> >> > ever >>> >> > expose that level of detail. ?(They don't even expose a real >>> >> > GL_VENDOR.) >>> >> > >>> >> > -- >>> >> > Glenn Maynard >>> >> > ----------------------------------------------------------- >>> >> > 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 >>> >> > ----------------------------------------------------------- >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Mikko Mononen, Software Engineer >>> >> http://tinkercad.com?- Solid modeling for artists & makers >>> >> >>> >> ----------------------------------------------------------- >>> >> 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 >>> >> ----------------------------------------------------------- >>> >> >>> > >>> > >>> >>> >>> >>> -- >>> Mikko Mononen, Software Engineer >>> http://tinkercad.com?- Solid modeling for artists & makers >> > > ----------------------------------------------------------- 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 gle...@ Fri May 6 16:25:28 2011 From: gle...@ (Glenn Maynard) Date: Fri, 6 May 2011 19:25:28 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: On Fri, May 6, 2011 at 6:46 PM, David Sheets wrote: > The proposed solution is to make the reference in the form of a > conditionally downloaded, centrally maintained diagnostic script that > lets users stay on an application site. This isn't a solution at all. A remote script can't provide real diagnostics for installing WebGL, since a remote script doesn't have access to the necessary information: driver versions, GPU manufacturer and product, the browser's current GPU blacklist, and so on. > The alternative is that the small WebGL players use get.webgl.org and > suffer the UX and friction while the big WebGL players actively > maintain their own diagnostics (at considerable expense) for better UX > and lower friction. This harms adoption. This is the only way that can actually give a useful UI to end users for anything but trivial cases that can be detected browser-side (eg. checking whether WebGL interfaces exist and known browser version checks). However, this isn't an "alternative". They're not mutually exclusive, and browsers will always have the option of doing this. (I'm not really sure what you're suggesting "harms adoption" here, either. It seems like you're saying that major browsers giving better diagnostic UI would harm adoption.) -- Glenn Maynard ----------------------------------------------------------- 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 kos...@ Fri May 6 17:09:45 2011 From: kos...@ (David Sheets) Date: Fri, 6 May 2011 17:09:45 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: On Fri, May 6, 2011 at 4:25 PM, Glenn Maynard wrote: > On Fri, May 6, 2011 at 6:46 PM, David Sheets wrote: >> The proposed solution is to make the reference in the form of a >> conditionally downloaded, centrally maintained diagnostic script that >> lets users stay on an application site. > > This isn't a solution at all. ?A remote script can't provide real > diagnostics for installing WebGL, since a remote script doesn't have > access to the necessary information: driver versions, GPU manufacturer > and product, the browser's current GPU blacklist, and so on. This is the same situation as with the current get.webgl.org site. >> The alternative is that the small WebGL players use get.webgl.org and >> suffer the UX and friction while the big WebGL players actively >> maintain their own diagnostics (at considerable expense) for better UX >> and lower friction. This harms adoption. > > This is the only way that can actually give a useful UI to end users > for anything but trivial cases that can be detected browser-side (eg. > checking whether WebGL interfaces exist and known browser version > checks). I am still talking about in-site detection. If browser vendors want to implement diagnostics that is separate from in-site detection, great. I'll believe it when I see it. Everything I have said still holds for small vs. large WebGL application authors. > However, this isn't an "alternative". ?They're not mutually exclusive, > and browsers will always have the option of doing this. ?(I'm not > really sure what you're suggesting "harms adoption" here, either. ?It > seems like you're saying that major browsers giving better diagnostic > UI would harm adoption.) Again, I am not saying anything about browser vendor diagnostics. The alternative here is between: A the coder-on-the-street linking to get.webgl.org and every commercial enterprise rolling their own in-site diagnostics or giving up on WebGL as glitchy and broken and choosing a proprietary 3-d solution OR B encapsulating the get.webgl.org logic and providing a simple means to use it without pointing users off-site I am saying that A harms adoption. It seems increasingly unlikely that in-browser diagnostic interfaces will be standardized before Molehill/Silverlight make all of this irrelevant. Browser vendors can of course implement these systems and hopefully will. Simply telling application authors to wait for browser vendors and send their users to get.webgl.org seems like a great way to discourage adoption. We have the means to provide a pretty good experience /today/. The major limitations are the opacity of get.webgl.org and the intentional removal of hardware information by browser vendors. Browser-level diagnostics are great. Protecting user privacy is great. Unfortunately, the browser vendors have removed diagnostic information but not provided their own diagnostic systems. This is bad for adoption as diagnosing problems is well beyond most users. David Sheets > -- > Glenn Maynard > ----------------------------------------------------------- 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 gle...@ Fri May 6 17:32:16 2011 From: gle...@ (Glenn Maynard) Date: Fri, 6 May 2011 20:32:16 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: On Fri, May 6, 2011 at 8:09 PM, David Sheets wrote: > On Fri, May 6, 2011 at 4:25 PM, Glenn Maynard wrote: >> On Fri, May 6, 2011 at 6:46 PM, David Sheets wrote: >>> The proposed solution is to make the reference in the form of a >>> conditionally downloaded, centrally maintained diagnostic script that >>> lets users stay on an application site. >> >> This isn't a solution at all. ?A remote script can't provide real >> diagnostics for installing WebGL, since a remote script doesn't have >> access to the necessary information: driver versions, GPU manufacturer >> and product, the browser's current GPU blacklist, and so on. > > This is the same situation as with the current get.webgl.org site. It's get.webgl.org I'm talking about. This discussion is about in-browser diagnostics (provided by the browser, with full access to the system) versus in-site diagnostics like get.webgl.org, and how useful the error messages provided to scripts by getContext are to the latter in practice. If you're just talking about how to implement in-site diagnostics, please start another thread so this one isn't derailed. Thanks. -- Glenn Maynard ----------------------------------------------------------- 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 jda...@ Fri May 6 18:50:37 2011 From: jda...@ (John Davis) Date: Fri, 6 May 2011 20:50:37 -0500 Subject: [Public WebGL] Looking for webgl applications which use vertex textures In-Reply-To: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> References: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> Message-ID: I can try and put some stuff together if it's in the chrome canary build. Is it in there? On Fri, May 6, 2011 at 11:07 AM, Daniel Koch wrote: > Hi folks, > > We're currently implementing support for vertex texture lookups in ANGLE > and are looking for additional content to test the implementation. > > If you have any Webgl applications which either require vertex texture > fetch, or will take advantage of this when advertised, can you please > provide a link to the page in the ANGLE issue tracker: > http://code.google.com/p/angleproject/issues/detail?id=95 > > Thanks, > Daniel > > --- > Daniel Koch -+- daniel...@ > Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan...@ Fri May 6 19:04:03 2011 From: dan...@ (Daniel Koch) Date: Fri, 6 May 2011 22:04:03 -0400 Subject: [Public WebGL] Looking for webgl applications which use vertex textures In-Reply-To: References: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> Message-ID: No it's not been checked in yet. We were hoping to do some broader testing on it first :-) Daniel On 2011-05-06, at 9:50 PM, John Davis wrote: > I can try and put some stuff together if it's in the chrome canary build. Is it in there? > > On Fri, May 6, 2011 at 11:07 AM, Daniel Koch wrote: > Hi folks, > > We're currently implementing support for vertex texture lookups in ANGLE and are looking for additional content to test the implementation. > > If you have any Webgl applications which either require vertex texture fetch, or will take advantage of this when advertised, can you please provide a link to the page in the ANGLE issue tracker: http://code.google.com/p/angleproject/issues/detail?id=95 > > Thanks, > Daniel --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Fri May 6 19:20:12 2011 From: gle...@ (Glenn Maynard) Date: Fri, 6 May 2011 22:20:12 -0400 Subject: [Public WebGL] Looking for webgl applications which use vertex textures In-Reply-To: References: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> Message-ID: On Fri, May 6, 2011 at 9:50 PM, John Davis wrote: > I can try and put some stuff together if it's in the chrome canary build. If you want to force the issue, try starting Chrome with -use-gl=desktop; last I checked that enabled vertex texture sampling for me. It causes other issues in the process, of course, but it might help you here. -- Glenn Maynard ----------------------------------------------------------- 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 kos...@ Fri May 6 21:03:18 2011 From: kos...@ (David Sheets) Date: Fri, 6 May 2011 21:03:18 -0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: > It's get.webgl.org I'm talking about. ?This discussion is about > in-browser diagnostics (provided by the browser, with full access to > the system) versus in-site diagnostics like get.webgl.org, and how > useful the error messages provided to scripts by getContext are to the > latter in practice. Unfortunately, the most useful pieces of information (GPU vendor, driver version) appear to be verboten from crossing the sandbox boundary. Given this constraint, why not return a triple in the exception: localized error string standardized error code/object in-browser (chrome:? about:?) URL for diagnostics or graphics driver upgrade redirect (to protect vendor info) This gives the application developer control of the initial error condition and provides a link to a secure system to test the user's graphics subsystem and recommend further action. In many cases, the next time the user will return to the application site will necessarily be after a browser or OS restart and the diagnostic page is more noticeable and more usable than an infobar. Additionally, the diagnostic trigger is the standard web action of clicking a link and can be integrated into the application site. I don't know what the current feeling is on implementing web APIs that mandate Open Web -> In-browser links. I suppose this could be subverted for phishing attacks against graphics driver downloads. An on-error info bar doesn't seem quite right, however, as it takes control away from content developers who may wish to provide seamless fallbacks or handle certain known errors in special ways. Perhaps the error link could trigger a difficult-to-forge browser behavior like a native dialog or on-demand infobar. > If you're just talking about how to implement > in-site diagnostics, please start another thread so this one isn't > derailed. ?Thanks. My aim with discussing in-site diagnostics was entirely to emphasize the abstraction of troubleshooting and error management. There had been discussion about developer burden and I was proposing a simple way to ease that burden by opening up an existing troubleshooting mechanism (get.webgl.org). I apologize for veering off-topic. David Sheets > -- > Glenn Maynard > ----------------------------------------------------------- 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 mik...@ Sun May 8 01:52:51 2011 From: mik...@ (Mikko Mononen) Date: Sun, 8 May 2011 11:52:51 +0300 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> <4DAE42F7.1000202@hicorp.co.jp> <4DB7F9EA.9030104@opera.com> <4DB94531.3070705@opera.com> <4DB98F47.3010107@opera.com> <463023552-1304711218-cardhu_decombobulator_blackberry.rim.net-1629701559-@bda501.bisx.prod.on.blackberry> Message-ID: I included the get.webgl.org since it has been promoted at the main vessel to help people to solve webgl issues. This discussion ties into what the returned error message should be, and how is responsible to deal with the error. IMHO Error reporting is always more of an UX issue, than a code issue. For that reason, I hope that there would a clear guideline (from webgl) on what should be done in case of webgl errors (like console TCRs) and a simple default implementation to help adobtation (like webgl-utils). +1 for David's proposal. I would be really happy if with the situation that the browser could directly provide a browser specific link to a trouble shooting site in the case the browser supports webgl, but it could not be initialized (blacklisted, internal error, etc). I'm fine with banner message boxes too as mentioned earlier. Would that be something all browser vendors agree on implementing? I.e. it is something I can refer to in the site copy? What if user chooses to ignore it? What should I do in other cases, direct people to get.webgl.org? For me the biggest problem with get.webgl.org is that it does not look something I can trust. It needs to look professional and it needs branding which ties it to browser makers (I doupt the public knows about khronos). I would be fine if get.webgl.org/troubleshooting would be just just redirect service to browser vendors troubleshooting pages. The mainpage should be more informative and written in a way that it expects the user to come there because he/she does not not have up to date browser or webgl is not supported in her platform. One thing will always be missing here is what to do when none of the upgrade options match the user's profile. I apologize for dragging the discussion into tangent. My point is that the decision you guys make on the error message has effect all the way up to the end user. What I gather from the current proposals, it is not clear who is responsible for trying to resolve the problem of the end user. --mikko On Sat, May 7, 2011 at 7:03 AM, David Sheets wrote: >> It's get.webgl.org I'm talking about. ?This discussion is about >> in-browser diagnostics (provided by the browser, with full access to >> the system) versus in-site diagnostics like get.webgl.org, and how >> useful the error messages provided to scripts by getContext are to the >> latter in practice. > > Unfortunately, the most useful pieces of information (GPU vendor, > driver version) appear to be verboten from crossing the sandbox > boundary. Given this constraint, why not return a triple in the > exception: > > localized error string > standardized error code/object > in-browser (chrome:? about:?) URL for diagnostics or graphics driver > upgrade redirect (to protect vendor info) > > This gives the application developer control of the initial error > condition and provides a link to a secure system to test the user's > graphics subsystem and recommend further action. In many cases, the > next time the user will return to the application site will > necessarily be after a browser or OS restart and the diagnostic page > is more noticeable and more usable than an infobar. Additionally, the > diagnostic trigger is the standard web action of clicking a link and > can be integrated into the application site. > > I don't know what the current feeling is on implementing web APIs that > mandate Open Web -> In-browser links. I suppose this could be > subverted for phishing attacks against graphics driver downloads. An > on-error info bar doesn't seem quite right, however, as it takes > control away from content developers who may wish to provide seamless > fallbacks or handle certain known errors in special ways. > > Perhaps the error link could trigger a difficult-to-forge browser > behavior like a native dialog or on-demand infobar. > >> If you're just talking about how to implement >> in-site diagnostics, please start another thread so this one isn't >> derailed. ?Thanks. > > My aim with discussing in-site diagnostics was entirely to emphasize > the abstraction of troubleshooting and error management. There had > been discussion about developer burden and I was proposing a simple > way to ease that burden by opening up an existing troubleshooting > mechanism (get.webgl.org). I apologize for veering off-topic. > > David Sheets > >> -- >> Glenn Maynard >> > -- Mikko Mononen, Software Engineer http://tinkercad.com?- Solid modeling for artists & makers ----------------------------------------------------------- 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 jda...@ Sun May 8 03:58:25 2011 From: jda...@ (John Davis) Date: Sun, 8 May 2011 05:58:25 -0500 Subject: [Public WebGL] WebCL In-Reply-To: <8F9C33DBA4D7C645A1E833BDDDD2CFB3039A05@008-AM1MPN1-013.mgdnok.nokia.com> References: <1377301503.70891.1303215456873.JavaMail.root@cm-mail03.mozilla.org> <8F9C33DBA4D7C645A1E833BDDDD2CFB3039A05@008-AM1MPN1-013.mgdnok.nokia.com> Message-ID: Any updates on the WebCL mailing list? On Tue, May 3, 2011 at 10:01 AM, wrote: > Benoit, all, > > > > I?m expecting a public WebCL mailing list to be set up within the next few > days, we?re only waiting for a final ?OK? from the Khronos board. > > > > Meanwhile, you may want to try out our WebCL prototype at > http://webcl.nokiaresearch.com. Be forewarned that it probably won?t work > out of the box, unless you have very recent NVIDIA or AMD display drivers > already installed (which may actually be the case for most people on this > mailing list, but not the general public). The source code is available > under LGPL. > > > > We would appreciate any feedback, either directly to me or via the upcoming > WebCL public mailing list. Thanks in advance! > > > > Best regards, > > Tomi > > _____________________ > > Tomi Aarnio > > Senior Research Engineer > > Nokia Research Center > > Tampere, Finland > > > > *From:* owner-public_webgl...@ [mailto: > owner-public_webgl...@] *On Behalf Of *ext Benoit Jacob > *Sent:* 19. huhtikuuta 2011 15:18 > *To:* jdavis...@ > *Cc:* public webgl > *Subject:* Re: [Public WebGL] WebCL > > > > I, too, am eagerly waiting for the creation of a public WebCL list. I know > at least 3 people working on WebCL-ish stuff who do not have access to the > private list. > > Benoit > ------------------------------ > > When will the mailing list go public? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom...@ Mon May 9 00:09:01 2011 From: tom...@ (tom...@) Date: Mon, 9 May 2011 07:09:01 +0000 Subject: [Public WebGL] WebCL In-Reply-To: References: <1377301503.70891.1303215456873.JavaMail.root@cm-mail03.mozilla.org> <8F9C33DBA4D7C645A1E833BDDDD2CFB3039A05@008-AM1MPN1-013.mgdnok.nokia.com> Message-ID: <8F9C33DBA4D7C645A1E833BDDDD2CFB303B56F@008-AM1MPN1-013.mgdnok.nokia.com> John, all, The public WebCL mailing list is now live. Please visit https://www.khronos.org/webcl/public-mailing-list/ to join. Best regards, Tomi From: unicomp21...@ [mailto:unicomp21...@] On Behalf Of ext John Davis Sent: 8. toukokuuta 2011 13:58 To: Aarnio Tomi (Nokia-NRC/Tampere) Cc: bjacob...@; public_webgl...@ Subject: Re: [Public WebGL] WebCL Any updates on the WebCL mailing list? On Tue, May 3, 2011 at 10:01 AM, > wrote: Benoit, all, I'm expecting a public WebCL mailing list to be set up within the next few days, we're only waiting for a final "OK" from the Khronos board. Meanwhile, you may want to try out our WebCL prototype at http://webcl.nokiaresearch.com. Be forewarned that it probably won't work out of the box, unless you have very recent NVIDIA or AMD display drivers already installed (which may actually be the case for most people on this mailing list, but not the general public). The source code is available under LGPL. We would appreciate any feedback, either directly to me or via the upcoming WebCL public mailing list. Thanks in advance! Best regards, Tomi _____________________ Tomi Aarnio Senior Research Engineer Nokia Research Center Tampere, Finland From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of ext Benoit Jacob Sent: 19. huhtikuuta 2011 15:18 To: jdavis...@ Cc: public webgl Subject: Re: [Public WebGL] WebCL I, too, am eagerly waiting for the creation of a public WebCL list. I know at least 3 people working on WebCL-ish stuff who do not have access to the private list. Benoit ________________________________ When will the mailing list go public? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue May 10 05:52:07 2011 From: bja...@ (Benoit Jacob) Date: Tue, 10 May 2011 05:52:07 -0700 (PDT) Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <35981305.66834.1305031615149.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hi List, We have had a patch ready for the OES_texture_float extension for some time, but we can't easily pass the conformance test because of this part: function runUniqueObjectTest() { debug("Testing that getExtension() returns the same object each time"); gl.getExtension("OES_texture_float").myProperty = 2; if (window.GCController) { window.GCController.collect(); } else { attemptToForceGC(); } shouldBe('gl.getExtension("OES_texture_float").myProperty', '2'); } These semantics are nontrivial to implement on our side. Not impossible, but not trivial either. I feel compelled to ask: What benefit do these semantics bring to the user? The other concern about this test is the GC part. What is window.GCController? Is that a WebKit-ism? Do we really want to have browser-specific code in conformance tests? Other browsers will use attemptToForceGC() which may or may not actually result in a GC run, giving non-deterministic results. In short, I question whether it's a good idea for a conformance test to rely on GC runs. Finally, I don't really see where in the spec these semantics are required. Section 5.13.14 says "Multiple calls to getExtension with the same extension string shall return the same object" but it's not entirely clear to me what that means in the case where the user modified that object in between, as we then have to choose between returning the modified object (behavior required by the test) or an object that is identical to the object that was returned the first time (which would be easy to implement). Cheers, Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cvi...@ Tue May 10 06:46:07 2011 From: cvi...@ (Cedric Vivier) Date: Tue, 10 May 2011 20:46:07 +0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <35981305.66834.1305031615149.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, May 10, 2011 at 19:52, Benoit Jacob wrote: > The other concern about this test is the GC part. What is window.GCController? Is that a WebKit-ism? Do we really want to have browser-specific code in conformance tests? Other browsers will use attemptToForceGC() which may or may not actually result in a GC run, giving non-deterministic results. In short, I question whether it's a good idea for a conformance test to rely on GC runs. I assume the intent is to test that the JavaScript object representing a WebGLExtension cannot ever be collected while the owner WebGLRenderingContext is alive, in order to provide singleton semantics within the context lifetime. Technically this means an extension object instance must have a GC root to the WebGLRenderingContext object instance (ie. https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_AddRoot) > > Section 5.13.14 says "Multiple calls to getExtension with the same extension string shall return the same object" but it's not entirely clear to me what that means in the case where the user modified that object in between, as we then have to choose between returning the modified object (behavior required by the test) or an object that is identical to the object that was returned the first time (which would be easy to implement). Afaik the intent of the spec is that former. These semantics makes sense as an extension object should work no differently than other DOM JavaScript objects. We should probably take the opportunity to clarify getExtension spec using imperative style (getContext-style) : [proposal] getExtensions(name) method of the WebGLRenderingContext, when invoked, must run the following steps: 1. Let name be the first argument to the method. 2. If extension name is not supported by this context, return null and abort these steps. 3. If the getExtension method has already been invoked on this context for the same extension name, return the same object as was returned that time, and abort these steps. 4. Return a new extension object. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tan...@ Tue May 10 07:07:50 2011 From: tan...@ (tansel halic) Date: Tue, 10 May 2011 10:07:50 -0400 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: It is not directly related to the topic discussed here but probably, you may be knowing..Can we load/use browser plugin from web worker?. My experience is that; browser plugin and javascript communication is bottleneck when there is large data transfer involved. It would be nice if there is way to take over this communication and put in a separate thread(such as in web worker). This would also be wonderful for webgl apps. tansel On Fri, May 6, 2011 at 4:49 PM, Gregg Tavares (wrk) wrote: > > > On Thu, May 5, 2011 at 5:54 PM, Kenneth Russell wrote: > >> >> After looking at Brian's example below and giving this more thought >> I'm inclined to leave the new slice() method on ArrayBuffer. Doing so >> avoids the creation of two temporary Uint8Arrays, and I've received >> requests for this functionality from multiple individuals doing large >> file I/O, indicating it's worth providing it in the API rather than >> relying on third-party libraries to provide it. >> > > I don't care either way but I'm missing the issue > > // This is the original buffer. With or without slice you'll have this > var buffer = DataView.buffer; > > // This is just a VIEW to the original buffer. > var tmpToCopy = new Uint8Array(buffer, start, end); // Even though the > data is not all Uint8s > > // This is a copy. This is actually the same copy that slice would make. > var tmpCopied = new Uint8Array(tmpToCopy); > > // This is a reference to the new buffer. > var subBuffer = tmpToCopy.buffer; > > // This is a VIEW on the buffer. We still only have 2 buffers. The > original and the copied subsection. > var subView = new DataView(subBuffer); > > > There's no more or less copies than slice. There's just a couple of small > temp VIEWs. > > > >> -Ken >> >> On Mon, May 2, 2011 at 2:10 PM, Ben Vanik wrote: >> > Yeah - this is the scenario I'm concerned about, and as you pointed out >> that >> > code is non-obvious and dirty. Just saying 'wrap it in function and drop >> it >> > on a prototype' is a cop-out for clean API design. >> > >> > -- >> > Ben Vanik >> > http://www.noxa.org >> > >> > >> > On Mon, May 2, 2011 at 1:37 PM, Brian Cornell >> wrote: >> >> >> >> So if you are using just an ArrayBuffer with a DataView and want to >> copy a >> >> subset of it (so the rest can be garbage collected, just keep a small >> part >> >> of it), is the recommendation to do the following? >> >> var buffer = DataView.buffer; >> >> var tmpToCopy = new Uint8Array(buffer, start, end); // Even though the >> >> data is not all Uint8s >> >> var tmpCopied = new Uint8Array(tmpToCopy); >> >> var subBuffer = tmpToCopy.buffer; >> >> var subView = new DataView(subBuffer); >> >> That seems convoluted and unobvious, especially the fact that I have to >> >> treat my many-typed data as all Uint8s just because only TypedArrays >> have >> >> ways to copy data. >> >> -Brian >> >> >> >> On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell >> wrote: >> >>> >> >>> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin >> wrote: >> >>> > >> >>> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: >> >>> > >> >>> >> >> >>> >> ... >> >>> >> As part of the planned Typed Array API changes to support efficient >> >>> >> communication with web workers, the plan is to add convenience >> methods >> >>> >> to copy ArrayBuffers and possibly sub-portions of them. I think we >> >>> >> should invest our time in moving those changes forward. >> >>> > >> >>> > Why is it necessary to have functions to copy ArrayBuffers. Isn't >> the >> >>> > copy constructor in the TypedArrays sufficient? >> >>> >> >>> That's a fair point. During one of the face-to-face meetings with >> >>> Mozilla it seemed that if we used transfer-of-ownership for >> >>> ArrayBuffers sent via postMessage, then we had to make it easy to copy >> >>> them. You're right, though, that the slice() operation can be easily >> >>> implemented in pure JavaScript, with the only cost the creation of two >> >>> temporary Uint8Arrays. >> >>> >> >>> Should we just get rid of it and provide non-normative text showing >> >>> how it could be implemented? >> >>> >> >>> -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 >> >>> ----------------------------------------------------------- >> >>> >> >> >> > >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue May 10 09:52:22 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 10 May 2011 09:52:22 -0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: References: <35981305.66834.1305031615149.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, May 10, 2011 at 6:46 AM, Cedric Vivier wrote: > > On Tue, May 10, 2011 at 19:52, Benoit Jacob wrote: >> The other concern about this test is the GC part. What is window.GCController? Is that a WebKit-ism? Do we really want to have browser-specific code in conformance tests? Other browsers will use attemptToForceGC() which may or may not actually result in a GC run, giving non-deterministic results. In short, I question whether it's a good idea for a conformance test to rely on GC runs. > > I assume the intent is to test that the JavaScript object representing > a WebGLExtension cannot ever be collected while the owner > WebGLRenderingContext is alive, in order to provide singleton > semantics within the context lifetime. That's correct. This behavior matches the semantics of Canvas.getContext(). See http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-getcontext . For what it's worth, it wasn't completely trivial to make this work in WebKit either, but since the spec was written in this way and since Canvas.getContext() works similarly, we pushed to implement it. The GCController is an interface available only in WebKit's automated test harness. I agree it's not ideal to have browser-specific constructs in the conformance suite, but using this interface makes the test completely repeatable. Testing this behavior is important to avoid regressions. If Firefox has a similar construct you should feel free to add an arm to the test to use it. Also, if you have ideas for how to make the attemptToForceGC function more deterministic, please file bugs against the conformance suite. > Technically this means an extension object instance must have a GC > root to the WebGLRenderingContext object instance (ie. > https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_AddRoot) > > >> >> Section 5.13.14 says "Multiple calls to getExtension with the same extension string shall return the same object" but it's not entirely clear to me what that means in the case where the user modified that object in between, as we then have to choose between returning the modified object (behavior required by the test) or an object that is identical to the object that was returned the first time (which would be easy to implement). > > Afaik the intent of the spec is that former. > These semantics makes sense as an extension object should work no > differently than other DOM JavaScript objects. > > > We should probably take the opportunity to clarify getExtension spec > using imperative style (getContext-style) : > > [proposal] > getExtensions(name) method of the WebGLRenderingContext, when invoked, > must run the following steps: > 1. Let name be the first argument to the method. > 2. If extension name is not supported by this context, return null and > abort these steps. > 3. If the getExtension method has already been invoked on this context > for the same extension name, return the same object as was returned > that time, and abort these steps. > 4. Return a new extension object. This sounds good to me. -Ken > Regards, > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Tue May 10 10:52:02 2011 From: gle...@ (Glenn Maynard) Date: Tue, 10 May 2011 13:52:02 -0400 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <35981305.66834.1305031615149.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, May 10, 2011 at 8:52 AM, Benoit Jacob wrote: > Finally, I don't really see where in the spec these semantics are required. > Section 5.13.14 says "Multiple calls to getExtension with the same extension > string shall return the same object" but it's not entirely clear to me what > that means in the case where the user modified that object in between, as we > then have to choose between returning the modified object (behavior required > by the test) or an object that is identical to the object that was returned > the first time (which would be easy to implement). > Wouldn't it be saner to do the exact opposite: require that getExtension return a different object each time? This is straightforward to test without any GC complexities getting in the way. This assumes that extension objects don't contain any state of their own; that they only contain functions and constants and any related state is stored in the WebGL context. That seems to be how extensions are meant to be implemented, so that seems reasonable; I don't know if there are any reasonable cases where this might become an unwanted restriction. > These semantics makes sense as an extension object should work no > differently than other DOM JavaScript objects. JavaScript objects don't all work this way. Saving the first result and returning it in the future is a getContext-specific thing; it doesn't necessarily make sense to mimic it here, in a very different sort of API. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Tue May 10 11:12:23 2011 From: ben...@ (Ben Vanik) Date: Tue, 10 May 2011 11:12:23 -0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: References: <35981305.66834.1305031615149.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: I've found the current behavior to be incredibly useful for a variety of applications, as it makes the API feel more javascript-y - the ability to modify objects however you want is one of the things that makes the language so great. I would not have been able to build debugging tools like WebGL Inspector without the persistent objects, and I can imagine future libraries that try to inter-operate requiring the behavior in order to work well. The DOM semantics Cedric mentions are things like getElementById always returning the same object. 'get' is fairly explicit in letting the caller know that it is getting an object - and the assumption (from I'm assuming everyone who has ever coded) would be that a 'get' would not return a new object each time - that would be 'createContext' or 'createExtension', which it is not. The fact that it does the create under the covers on the first call is singleton behavior, and hidden from the caller - for all they know every possible context/extension type is created on startup. The only weirdness here is that getExtension enables the extension on the first call, but that is orthogonal to object persistence. function renderFrame(gl) { var ext0 = gl.getExtension('foo'); var ext1 = gl.getExtension('foo'); assert(ext0 == ext1); }; Having ext0 != ext1 would be odd. Again, 'get' means get, and no one should have to know that 'getExtension' really means 'createExtension'. On Tue, May 10, 2011 at 10:52 AM, Glenn Maynard wrote: > On Tue, May 10, 2011 at 8:52 AM, Benoit Jacob wrote: >> >> Finally, I don't really see where in the spec these semantics are >> required. Section 5.13.14 says "Multiple calls to getExtension with the same >> extension string shall return the same object" but it's not entirely clear >> to me what that means in the case where the user modified that object in >> between, as we then have to choose between returning the modified object >> (behavior required by the test) or an object that is identical to the object >> that was returned the first time (which would be easy to implement). > > Wouldn't it be saner to do the exact opposite: require that getExtension > return a different object each time?? This is straightforward to test > without any GC complexities getting in the way. > > This assumes that extension objects don't contain any state of their own; > that they only contain functions and constants and any related state is > stored in the WebGL context.? That seems to be how extensions are meant to > be implemented, so that seems reasonable; I don't know if there are any > reasonable cases where this might become an unwanted restriction. > >> These semantics makes sense as an extension object should work no >> differently than other DOM JavaScript objects. > > JavaScript objects don't all work this way.? Saving the first result and > returning it in the future is a getContext-specific thing; it doesn't > necessarily make sense to mimic it here, in a very different sort of API. > > -- > Glenn Maynard > > ----------------------------------------------------------- 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 bja...@ Tue May 10 11:20:56 2011 From: bja...@ (Benoit Jacob) Date: Tue, 10 May 2011 11:20:56 -0700 (PDT) Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: Message-ID: <744268980.70902.1305051656903.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > function renderFrame(gl) { > var ext0 = gl.getExtension('foo'); > var ext1 = gl.getExtension('foo'); > assert(ext0 == ext1); > }; > Having ext0 != ext1 would be odd. Again, 'get' means get, and no one > should have to know that 'getExtension' really means > 'createExtension'. Noone is arguing against that, the test is rather: function renderFrame(gl) { var ext0 = gl.getExtension('foo'); ext0.someNewProperty = 'bar'; var ext1 = gl.getExtension('foo'); assert(ext0 == ext1); }; Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jam...@ Tue May 10 11:26:10 2011 From: jam...@ (James Robinson) Date: Tue, 10 May 2011 11:26:10 -0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <744268980.70902.1305051656903.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <744268980.70902.1305051656903.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, May 10, 2011 at 11:20 AM, Benoit Jacob wrote: > > ----- Original Message ----- > > function renderFrame(gl) { > > var ext0 = gl.getExtension('foo'); > > var ext1 = gl.getExtension('foo'); > > assert(ext0 == ext1); > > }; > > Having ext0 != ext1 would be odd. Again, 'get' means get, and no one > > should have to know that 'getExtension' really means > > 'createExtension'. > > Noone is arguing against that, the test is rather: > > function renderFrame(gl) { > var ext0 = gl.getExtension('foo'); > ext0.someNewProperty = 'bar'; > var ext1 = gl.getExtension('foo'); > assert(ext0 == ext1); > }; > Isn't that testing the same thing? Every call to context.getExtension(str) with the same value for 'str' must return the same object, just as every call to document.getElementById(str) that returns the same DOM node must return the same script object (as far as script can observe, anyway). - James > > Benoit > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vla...@ Tue May 10 11:32:47 2011 From: vla...@ (Vladimir Vukicevic) Date: Tue, 10 May 2011 18:32:47 +0000 (GMT) Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <16624568.38725.1305052127425.JavaMail.root@zimbra.off.net> Message-ID: <25133044.38733.1305052367100.JavaMail.root@zimbra.off.net> ----- Original Message ----- > I've found the current behavior to be incredibly useful for a variety > of applications, as it makes the API feel more javascript-y - the > ability to modify objects however you want is one of the things that > makes the language so great. > > I would not have been able to build debugging tools like WebGL > Inspector without the persistent objects, and I can imagine future > libraries that try to inter-operate requiring the behavior in order to > work well. > > The DOM semantics Cedric mentions are things like getElementById > always returning the same object. 'get' is fairly explicit in letting > the caller know that it is getting an object - and the assumption > (from I'm assuming everyone who has ever coded) would be that a 'get' > would not return a new object each time - that would be > 'createContext' or 'createExtension', which it is not. The fact that > it does the create under the covers on the first call is singleton > behavior, and hidden from the caller - for all they know every > possible context/extension type is created on startup. The only > weirdness here is that getExtension enables the extension on the first > call, but that is orthogonal to object persistence. > > function renderFrame(gl) { > var ext0 = gl.getExtension('foo'); > var ext1 = gl.getExtension('foo'); > assert(ext0 == ext1); > }; Having ext0 != ext1 would be odd. Again, 'get' means get, and no > one should have to know that 'getExtension' really means > 'createExtension'. In the Mozilla implementation, ext0 will always be == ext1, regardless of when you call getExtension. The issue is really just whether additional properties that are defined on one object are visible on a later one, after the first one has gone out of JS scope (and been collected). We have code that implements the same thing for some other dom objects, it's just a bit convoluted to add. For most normal users, they can store whatever they want, e.g.: var ext = gl.getExtension('foo'); ext.foo = 123; as long as they hold on to ext somewhere. The only place things break is if the user wants to store a property on the extension object, let all references to it go out of scope, and then get it again from gl.getExtension(). That seems like a really minor edge case, but I do agree that it's least surprising to have it actually work. Even with the current Mozilla implementation, I don't think anyone will ever actually run into any problems, but the test does test a valid edge case. - Vlad > On Tue, May 10, 2011 at 10:52 AM, Glenn Maynard > wrote: > > On Tue, May 10, 2011 at 8:52 AM, Benoit Jacob > > wrote: > >> > >> Finally, I don't really see where in the spec these semantics are > >> required. Section 5.13.14 says "Multiple calls to getExtension with > >> the same > >> extension string shall return the same object" but it's not > >> entirely clear > >> to me what that means in the case where the user modified that > >> object in > >> between, as we then have to choose between returning the modified > >> object (behavior required by the test) or an object that is > >> identical to the object > >> that was returned the first time (which would be easy to > >> implement). > > > > Wouldn't it be saner to do the exact opposite: require that > > getExtension return a different object each time? This is > > straightforward to test > > without any GC complexities getting in the way. > > > > This assumes that extension objects don't contain any state of their > > own; that they only contain functions and constants and any related > > state is > > stored in the WebGL context. That seems to be how extensions are > > meant to > > be implemented, so that seems reasonable; I don't know if there are > > any reasonable cases where this might become an unwanted > > restriction. > > > >> These semantics makes sense as an extension object should work no > >> differently than other DOM JavaScript objects. > > > > JavaScript objects don't all work this way. Saving the first result > > and returning it in the future is a getContext-specific thing; it > > doesn't necessarily make sense to mimic it here, in a very different > > sort of API. > > > > -- Glenn Maynard > > > > > > ----------------------------------------------------------- You are > currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Tue May 10 11:34:42 2011 From: ben...@ (Ben Vanik) Date: Tue, 10 May 2011 11:34:42 -0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: References: <744268980.70902.1305051656903.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: Exactly. Imagine all the awesome creative things that happen in JS DOM land now because of this behavior. Also, I don't see how this is different than the behavior of calls like getParameter: var tex0 = gl.getParameter(gl.TEXTURE_BINDING_2D); var tex1 = gl.getParameter(gl.TEXTURE_BINDING_2D); assert(tex0 == tex1); Without this being true I couldn't do useful things like: tex.width = width; tex.height = height; Or cache the uniform locations on the program object. Etc etc. I think it's pretty simple - if you can modify the WebGLRenderingContext and have those changes persist across getContext calls, you should be able to modify the extensions and have those changes persist across getExtension calls. Anything else is just bad design. And here's a more useful example of why you'd want this stuff: var ext = gl.getExtension('foo'); var origMethod = ext.method; ext.method = function() { console.log('hi!'); origMethod.call(ext); }; ext.helper = function() { console.log('useful!'); }; // ... ext.method(); // <-- yay ext.helper(); // ... someplace else, in another library/etc var ext = gl.getExtension('foo'); ext.method(); // <-- no longer augmented! ext.helper(); // <-- death! On Tue, May 10, 2011 at 11:26 AM, James Robinson wrote: > On Tue, May 10, 2011 at 11:20 AM, Benoit Jacob wrote: >> >> ----- Original Message ----- >> > function renderFrame(gl) { >> > var ext0 = gl.getExtension('foo'); >> > var ext1 = gl.getExtension('foo'); >> > assert(ext0 == ext1); >> > }; >> > Having ext0 != ext1 would be odd. Again, 'get' means get, and no one >> > should have to know that 'getExtension' really means >> > 'createExtension'. >> >> Noone is arguing against that, the test is rather: >> >> function renderFrame(gl) { >> ?var ext0 = gl.getExtension('foo'); >> ?ext0.someNewProperty = 'bar'; >> ?var ext1 = gl.getExtension('foo'); >> ?assert(ext0 == ext1); >> }; > > Isn't that testing the same thing? ?Every call to context.getExtension(str) > with the same value for 'str' must return the same object, just as every > call to document.getElementById(str) that returns the same DOM node must > return the same script object (as far as script can observe, anyway). > - James > >> >> Benoit >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From vla...@ Tue May 10 11:38:24 2011 From: vla...@ (Vladimir Vukicevic) Date: Tue, 10 May 2011 18:38:24 +0000 (GMT) Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <1119662.38745.1305052519428.JavaMail.root@zimbra.off.net> Message-ID: <7359922.38751.1305052704059.JavaMail.root@zimbra.off.net> ----- Original Message ----- > Noone is arguing against that, the test is rather: > > function renderFrame(gl) { > var ext0 = gl.getExtension('foo'); > ext0.someNewProperty = 'bar'; > var ext1 = gl.getExtension('foo'); > assert(ext0 == ext1); > }; The test is actually equivalent to this: var ext0 = gl.getExtension('foo'); ext0.someProperty = 'foo'; ext0 = null; // give up the reference to the actual extension object // force GC somehow: nothing has a reference to the extension object returned by gl.getExtension forceGC(); var ext1 = gl.getExtension('foo'); //assert(ext0 == ext1); // you can't test this -- you already gave up ext0's reference! assert(ext1.someProperty == 'foo'); // this will likely fail -- but it will succeed without the 'ext0 = null' line. implementation-wise, the internal native object has a JS wrapper that's created when it's returned back to JS. When you set arbitrary properties on it, they are set on the wrapper itself. This wrapper is the thing that gets discarded when a GC triggers. The fact that a new wrapper gets created is only observable due to the additional properties -- otherwise there's no way to check equivalence (because you no longer have the first wrapper reference at all -- it was given up so it could get GC'd). - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From vla...@ Tue May 10 11:55:51 2011 From: vla...@ (Vladimir Vukicevic) Date: Tue, 10 May 2011 18:55:51 +0000 (GMT) Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: Message-ID: <13590209.38769.1305053751257.JavaMail.root@zimbra.off.net> ----- Original Message ----- > Exactly. Imagine all the awesome creative things that happen in JS DOM > land now because of this behavior. > > Also, I don't see how this is different than the behavior of calls > like getParameter: > var tex0 = gl.getParameter(gl.TEXTURE_BINDING_2D); > var tex1 = gl.getParameter(gl.TEXTURE_BINDING_2D); > assert(tex0 == tex1); > Without this being true I couldn't do useful things like: > tex.width = width; tex.height = height; > Or cache the uniform locations on the program object. Etc etc. It's not any different. And yep, if you don't hold the tex object, your width/height are liable to disappear on you in Firefox. Sorry :( > I think it's pretty simple - if you can modify the > WebGLRenderingContext and have those changes persist across getContext > calls, you should be able to modify the extensions and have those > changes persist across getExtension calls. Anything else is just bad > design. Same problem! Just noone ever lets go of the rendering context :) I agree that it's useful, it's just not implemented that way. Benoit, did you look into seeing how complex the implementation would be? We just need to find a way to keep the wrappers around -- (sorry rest of list, mozilla-specific stuff here) perhaps we can decorate these various objects' classinfos with a new property that tells xpconnect that we want to preserve the wrapper no matter what? - Vlad ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cvi...@ Tue May 10 12:00:04 2011 From: cvi...@ (Cedric Vivier) Date: Wed, 11 May 2011 02:00:04 +0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <7359922.38751.1305052704059.JavaMail.root@zimbra.off.net> References: <1119662.38745.1305052519428.JavaMail.root@zimbra.off.net> <7359922.38751.1305052704059.JavaMail.root@zimbra.off.net> Message-ID: Hey Vlad, On Wed, May 11, 2011 at 01:38, Vladimir Vukicevic wrote: > implementation-wise, the internal native object has a JS wrapper that's created when it's returned back to JS. ?When you set arbitrary properties on it, they are set on the wrapper itself. ?This wrapper is the thing that gets discarded when a GC triggers. ?The fact that a new wrapper gets created is only observable due to the additional properties -- otherwise there's no way to check equivalence (because you no longer have the first wrapper reference at all -- it was given up so it could get GC'd). No, a new wrapper would still break the identity of ext1===ext2 instance-wise even if no property were ever added. Wouldn't adding the wrapper instance to the GC root of the WebGLContext wrapper just solves the issue wrt garbage collection? This guarantees the wrapper won't get GC'd before the context itself. Interestingly, we might not need/want a wrapper at all for this particular extension (OES_texture_float) as its object does not define any member, it would be legal to return a 'pure' JS object (ie. created with JS_new, equivalent to literal {} - still added to the GC root of the context) ... though this might be undesirable for other reasons (handling "empty" or non-empty extensions the same way). Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Tue May 10 12:06:05 2011 From: bja...@ (Benoit Jacob) Date: Tue, 10 May 2011 12:06:05 -0700 (PDT) Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: <13590209.38769.1305053751257.JavaMail.root@zimbra.off.net> Message-ID: <1426913523.71646.1305054365761.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > I agree that it's useful, it's just not implemented that way. Benoit, > did you look into seeing how complex the implementation would be? We > just need to find a way to keep the wrappers around -- (sorry rest of > list, mozilla-specific stuff here) perhaps we can decorate these > various objects' classinfos with a new property that tells xpconnect > that we want to preserve the wrapper no matter what? Blake gave me hints here: https://bugzilla.mozilla.org/show_bug.cgi?id=630672#c22 I suppose I will just look for some example code. The warning about the risk of introducing leaks is what made me question the usefulness of this whole thing, but OK. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Tue May 10 20:58:36 2011 From: cal...@ (Mark Callow) Date: Wed, 11 May 2011 12:58:36 +0900 Subject: [Public WebGL] Optimization or bug? Message-ID: <4DCA096C.202@hicorp.co.jp> We have discovered an interesting edge case regarding clearing of the drawing buffer after presentation when preserveDrawingBuffer is false where the implementations have different behaviour. A simple test program is attached. The test program clears only the color channels; the alpha channel is masked. Both Chrome & Safari clear the alpha channel to zero as required by the specification. Firefox 4 does not. On the systems I have tested so far, the initial value set by of 1.0 set when the test starts, remains in the alpha channel. Most likely the underlying GL implementations I've been able to test with preserve the drawing buffer across swap giving this result. But is this a bug in Firefox or a smart optimization? One could argue that if the WebGL implementation knows that the GL is preserving the buffer contents and the application has cleared the channel at least once, no further action is necessary to preserve security. What do the list members think? By the way, the spec language needs a small tweak. Section 2.2 says "The table below also shows the value to which these buffers shall be cleared when first created or when the size is changed." It needs to say "... when first created, when the size is changed or after presentation when preserveDrawingBuffer is false." Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From cal...@ Wed May 11 01:54:41 2011 From: cal...@ (Mark Callow) Date: Wed, 11 May 2011 17:54:41 +0900 Subject: [Public WebGL] Optimization or bug? In-Reply-To: <4DCA096C.202@hicorp.co.jp> References: <4DCA096C.202@hicorp.co.jp> Message-ID: <4DCA4ED1.4060201@hicorp.co.jp> It looks like it is a clever optimization. I modified the test so it sets gl.colorMask(gl.TRUE, gl.TRUE, gl.TRUE, gl.FALSE) before the first clear so it never writes to the alpha channel. This gives a transparent canvas. However it is not strictly following the specification and having different results across browsers causes problems, which is why we spotted this in the first place. Regards -Mark On 11/05/2011 12:58, Mark Callow wrote: > > We have discovered an interesting edge case regarding clearing of the > drawing buffer after presentation when preserveDrawingBuffer is false > where the implementations have different behaviour. A simple test > program is attached. > > The test program clears only the color channels; the alpha channel is > masked. Both Chrome & Safari clear the alpha channel to zero as > required by the specification. Firefox 4 does not. On the systems I > have tested so far, the initial value set by of 1.0 set when the test > starts, remains in the alpha channel. Most likely the underlying GL > implementations I've been able to test with preserve the drawing > buffer across swap giving this result. > > But is this a bug in Firefox or a smart optimization? One could argue > that if the WebGL implementation knows that the GL is preserving the > buffer contents and the application has cleared the channel at least > once, no further action is necessary to preserve security. What do the > list members think? > > By the way, the spec language needs a small tweak. Section 2.2 says > > "The table below also shows the value to which these buffers shall > be cleared when first created or when the size is changed." > > It needs to say > > "... when first created, when the size is changed or after > presentation when preserveDrawingBuffer is false." > > Regards > > -Mark > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From bja...@ Wed May 11 05:00:28 2011 From: bja...@ (Benoit Jacob) Date: Wed, 11 May 2011 05:00:28 -0700 (PDT) Subject: [Public WebGL] Optimization or bug? In-Reply-To: <4DCA096C.202@hicorp.co.jp> Message-ID: <956127249.78837.1305115228246.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- We have discovered an interesting edge case regarding clearing of the drawing buffer after presentation when preserveDrawingBuffer is false where the implementations have different behaviour. A simple test program is attached. The test program clears only the color channels; the alpha channel is masked. Both Chrome & Safari clear the alpha channel to zero as required by the specification. Firefox 4 does not. The preserveDrawingBuffer semantics are not implemented in Firefox 4. There is a patch series pending review on our bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=636913 This should enter Nightly very soon and eventually Firefox 6. On the systems I have tested so far, the initial value set by of 1.0 set when the test starts, remains in the alpha channel. Most likely the underlying GL implementations I've been able to test with preserve the drawing buffer across swap giving this result. But is this a bug in Firefox or a smart optimization? One could argue that if the WebGL implementation knows that the GL is preserving the buffer contents and the application has cleared the channel at least once, no further action is necessary to preserve security. What do the list members think? As far as I can see, we don't make any assumption about what channels in the buffer the GL implementation may preserve. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Wed May 11 09:33:43 2011 From: jda...@ (John Davis) Date: Wed, 11 May 2011 11:33:43 -0500 Subject: [Public WebGL] Webgl Message-ID: What's all the hubbub about a webgl exploit? News is spreading like wildfire. ----------------------------------------------------------- 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 bja...@ Wed May 11 10:04:18 2011 From: bja...@ (Benoit Jacob) Date: Wed, 11 May 2011 10:04:18 -0700 (PDT) Subject: [Public WebGL] Webgl In-Reply-To: Message-ID: <1688568665.81459.1305133458620.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> The only real exploit at this point is the cross-domain image stealer http://www.contextis.co.uk/resources/blog/webgl/poc/index.html I'm working on it (speaking only for Mozilla). Aside from that, a bug has been found, either in ANGLE or in D3D9, that causes a crash on an invalid write. While invalid write bugs are of course potentially exploitable, they didn't show exploit for it at this point. This kind of bug is discovered and fixed or worked around all the time, so I don't consider that particularly newsworthy. Regarding the rest of the Context blog, like Fundamentally, WebGL now allows full (Turing Complete) programs from the internet to reach the graphics driver and graphics hardware which operate in what is supposed to be the most protected part of the computer (Kernel Mode). I don't understand what that means. Benoit ----- Original Message ----- > What's all the hubbub about a webgl exploit? News is spreading like > wildfire. > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Wed May 11 18:25:11 2011 From: bja...@ (Benoit Jacob) Date: Wed, 11 May 2011 18:25:11 -0700 (PDT) Subject: [Public WebGL] Webgl In-Reply-To: <1688568665.81459.1305133458620.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1554584517.88050.1305163511836.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Mail original ----- > Aside from that, a bug has been found, either in ANGLE or in D3D9, > that causes a crash on an invalid write. While invalid write bugs are > of course potentially exploitable, they didn't show exploit for it at > this point. This kind of bug is discovered and fixed or worked around > all the time, so I don't consider that particularly newsworthy. That one is actually unconfirmed. So far, only Context has been able to reproduce it. Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Wed May 11 19:07:50 2011 From: cal...@ (Mark Callow) Date: Thu, 12 May 2011 11:07:50 +0900 Subject: [Public WebGL] Optimization or bug? In-Reply-To: <956127249.78837.1305115228246.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <956127249.78837.1305115228246.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4DCB40F6.1060001@hicorp.co.jp> Benoit, Thanks for the information. What happened to Firefox 5? Regards -Mark On 11/05/2011 21:00, Benoit Jacob wrote: > > > ------------------------------------------------------------------------ > The preserveDrawingBuffer semantics are not implemented in Firefox 4. > There is a patch series pending review on our bugzilla: > https://bugzilla.mozilla.org/show_bug.cgi?id=636913 > This should enter Nightly very soon and eventually Firefox 6. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From kbr...@ Wed May 11 19:21:19 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 11 May 2011 19:21:19 -0700 Subject: [Public WebGL] Optimization or bug? In-Reply-To: <4DCA096C.202@hicorp.co.jp> References: <4DCA096C.202@hicorp.co.jp> Message-ID: On Tue, May 10, 2011 at 8:58 PM, Mark Callow wrote: > We have discovered an interesting edge case regarding clearing of the > drawing buffer after presentation when preserveDrawingBuffer is false where > the implementations have different behaviour. A simple test program is > attached. > > The test program clears only the color channels; the alpha channel is > masked. Both Chrome & Safari clear the alpha channel to zero as required by > the specification. Firefox 4 does not. On the systems I have tested so far, > the initial value set by of 1.0 set when the test starts, remains in the > alpha channel. Most likely the underlying GL implementations I've been able > to test with preserve the drawing buffer across swap giving this result. > > But is this a bug in Firefox or a smart optimization? One could argue that > if the WebGL implementation knows that the GL is preserving the buffer > contents and the application has cleared the channel at least once, no > further action is necessary to preserve security. What do the list members > think? > > By the way, the spec language needs a small tweak. Section 2.2 says > > "The table below also shows the value to which these buffers shall be > cleared when first created or when the size is changed." > > It needs to say > > "... when first created, when the size is changed or after presentation when > preserveDrawingBuffer is false." Good catch; I've applied this change to the editor's draft. -Ken > Regards > > -Mark > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Wed May 11 19:22:39 2011 From: cal...@ (Mark Callow) Date: Thu, 12 May 2011 11:22:39 +0900 Subject: [Public WebGL] Webgl In-Reply-To: <1688568665.81459.1305133458620.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1688568665.81459.1305133458620.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4DCB446F.4030301@hicorp.co.jp> An excessive majority of the article is about what Context terms "denial of service" attacks by which they mean it is fairly easy for a webgl app. to make a system unresponsive or even crash (due to shader execution taking a long time and lack of robustness in the graphics driver). These things have been talked about exhaustively on both this list and in the WG and are being addressed by ARB_robustness extensions being added to the graphics drivers. My view, which is shared by many others, is that while such apps could give WebGL a bad name, they are not a security threat and not even a particularly serious problem. If some site/WebGL app causes your system to crash or be unresponsive, you won't go there again. Problem solved. As for cross-domain image stealing, the WG is currently discussing this issue. The ability to incorporate cross-domain images into WebGL scenes provides great utility to developers, so the WG is considering requiring Cross Origin Resource Sharing (CORS) opt-in or other mechanisms to prevent abuse of this capability. Regards -Mark On 12/05/2011 02:04, Benoit Jacob wrote: > The only real exploit at this point is the cross-domain image stealer > http://www.contextis.co.uk/resources/blog/webgl/poc/index.html > I'm working on it (speaking only for Mozilla). > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From bja...@ Wed May 11 19:24:19 2011 From: bja...@ (Benoit Jacob) Date: Wed, 11 May 2011 19:24:19 -0700 (PDT) Subject: [Public WebGL] Optimization or bug? In-Reply-To: <4DCB40F6.1060001@hicorp.co.jp> Message-ID: <1203118164.88358.1305167059548.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Firefox 5 branched a while ago off mozilla-central, it is now entering beta, it's too late for this kind of changes to enter it. Benoit ----- Original Message ----- Benoit, Thanks for the information. What happened to Firefox 5? Regards -Mark On 11/05/2011 21:00, Benoit Jacob wrote: ----- Original Message ----- The preserveDrawingBuffer semantics are not implemented in Firefox 4. There is a patch series pending review on our bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=636913 This should enter Nightly very soon and eventually Firefox 6. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Wed May 11 19:25:50 2011 From: cvi...@ (Cedric Vivier) Date: Thu, 12 May 2011 09:25:50 +0700 Subject: [Public WebGL] oes-texture-float conformance In-Reply-To: References: <35981305.66834.1305031615149.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1020415595.66863.1305031927681.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Tue, May 10, 2011 at 23:52, Kenneth Russell wrote: >> We should probably take the opportunity to clarify getExtension spec >> using imperative style (getContext-style) : >> >> [proposal] >> getExtensions(name) method of the WebGLRenderingContext, when invoked, >> must run the following steps: >> 1. Let name be the first argument to the method. >> 2. If extension name is not supported by this context, return null and >> abort these steps. >> 3. If the getExtension method has already been invoked on this context >> for the same extension name, return the same object as was returned >> that time, and abort these steps. >> 4. Return a new extension object. > > This sounds good to me. > If there is no objection, I'll apply this change to the spec. Cheers, ----------------------------------------------------------- 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 gle...@ Wed May 11 19:37:11 2011 From: gle...@ (Glenn Maynard) Date: Wed, 11 May 2011 22:37:11 -0400 Subject: [Public WebGL] Webgl In-Reply-To: <4DCB446F.4030301@hicorp.co.jp> References: <1688568665.81459.1305133458620.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4DCB446F.4030301@hicorp.co.jp> Message-ID: On Wed, May 11, 2011 at 10:22 PM, Mark Callow wrote: > My view, which is shared by many others, is that while such apps could > give WebGL a bad name, they are not a security threat and not even a > particularly serious problem. If some site/WebGL app causes your system to > crash or be unresponsive, you won't go there again. Problem solved. > I agree it's not equivalent to a security threat, but I strongly disagree that it's not a serious problem if it happens. No site should ever be able to crash my browser, much less my system; any bugs that allow this to happen are very serious. Fortunately, from what I've seen, vendors aren't dismissing this so casually. > As for cross-domain image stealing, the WG is currently discussing this > issue. The ability to incorporate cross-domain images into WebGL scenes > provides great utility to developers, so the WG is considering requiring > Cross Origin Resource Sharing (CORS) opt-in or other mechanisms to prevent > abuse of this capability. > The cross-domain issue Benoit is referring to is different. Browsers already prevent reading images cross-domain directly; the issue here is that you can get around that with timing attacks, which is much harder to prevent. (I agree that CORS or similar is critical.) -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed May 11 20:50:18 2011 From: cal...@ (Mark Callow) Date: Thu, 12 May 2011 12:50:18 +0900 Subject: [Public WebGL] Webgl In-Reply-To: References: <1688568665.81459.1305133458620.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4DCB446F.4030301@hicorp.co.jp> Message-ID: <4DCB58FA.3060804@hicorp.co.jp> On 12/05/2011 11:37, Glenn Maynard wrote: > On Wed, May 11, 2011 at 10:22 PM, Mark Callow > > wrote: > > My view, which is shared by many others, is that while such apps > could give WebGL a bad name, they are not a security threat and > not even a particularly serious problem. If some site/WebGL app > causes your system to crash or be unresponsive, you won't go there > again. Problem solved. > > I agree it's not equivalent to a security threat, but I strongly > disagree that it's not a serious problem if it happens. No site > should ever be able to crash my browser, much less my system; any bugs > that allow this to happen are very serious. Fortunately, from what > I've seen, vendors aren't dismissing this so casually. I am not dismissing it casually. The graphics implementations definitely need to become more robust. If it does happen, it is for sure an unpleasant experience but it is one you can easily avoid repeating. > > As for cross-domain image stealing, the WG is currently discussing > this issue. The ability to incorporate cross-domain images into > WebGL scenes provides great utility to developers, so the WG is > considering requiring Cross Origin Resource Sharing (CORS) opt-in > or other mechanisms to prevent abuse of this capability. > > The cross-domain issue Benoit is referring to is different. Browsers > already prevent reading images cross-domain directly; the issue here > is that you can get around that with timing attacks, which is much > harder to prevent. (I agree that CORS or similar is critical.) It is the same issue. One solution is to forbid the use of cross-domain images as textures; another is CORS. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 412 bytes Desc: not available URL: From gle...@ Wed May 11 23:58:57 2011 From: gle...@ (Glenn Maynard) Date: Thu, 12 May 2011 02:58:57 -0400 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> Message-ID: On Thu, May 12, 2011 at 2:42 AM, Ian Hickson wrote: > On Wed, 13 Apr 2011, Glenn Maynard wrote: > > Calling canvas.getContext("webgl", {async: true}) will cause it to > > discouraged from using this API (deprecating it if possible). > (FYI: while some people have expressed interest in async init for WebGL, I'm not going to push for this myself and nobody else seems to want it badly enough to, so I've dropped this.) -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Thu May 12 02:18:56 2011 From: cvi...@ (Cedric Vivier) Date: Thu, 12 May 2011 16:18:56 +0700 Subject: [Public WebGL] Re: [whatwg] Canvas.getContext error handling In-Reply-To: References: <4DA4198A.2080006@mit.edu> Message-ID: On Thu, May 12, 2011 at 13:58, Glenn Maynard wrote: > (FYI: while some people have expressed interest in async init for WebGL, I'm > not going to push for this myself and nobody else seems to want it badly > enough to, so I've dropped this.) I, for one, badly want it... for a future revision of WebGL though, we need first a minimally intrusive fix to the existing spec. This will greatly help to get more applications to support context loss/resume (something that lacks currently, there's simply no incentive). Also, async init will be necessary for browsers to implement non-blocking/non-modal troubleshooting or permission UI at context creation. For instance a browser (or a browser extension) could ask the user for permission to accept/deny WebGL context creation, similarly to how the user gives permission for a web page to detect his/her location with Geolocation API. While some users might like this by default (hence a browser extension could propose this), more importantly it could allow WebGL to run on a case-by-case basis (when the user trusts the web page) on drivers without ARB_robustness, instead of having WebGL completely disabled. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu May 12 18:03:55 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 12 May 2011 18:03:55 -0700 Subject: [Public WebGL] Typed Array setter for partial arrays (and typed array performance) In-Reply-To: References: <4DB00602.5000002@hicorp.co.jp> Message-ID: On Fri, May 6, 2011 at 1:49 PM, Gregg Tavares (wrk) wrote: > > > On Thu, May 5, 2011 at 5:54 PM, Kenneth Russell wrote: >> >> After looking at Brian's example below and giving this more thought >> I'm inclined to leave the new slice() method on ArrayBuffer. Doing so >> avoids the creation of two temporary Uint8Arrays, and I've received >> requests for this functionality from multiple individuals doing large >> file I/O, indicating it's worth providing it in the API rather than >> relying on third-party libraries to provide it. > > I don't care either way but I'm missing the issue > // This is the original buffer. With or without slice you'll have this > var buffer = DataView.buffer; > // This is just a VIEW to the original buffer. > var tmpToCopy = new Uint8Array(buffer, start, end); ?// Even though the data > is not all Uint8s > // This is a copy. This is actually the same copy that slice would make. > var tmpCopied = new Uint8Array(tmpToCopy); > // This is a reference to the new buffer. > var subBuffer = tmpToCopy.buffer; > // This is a VIEW on the buffer. We still only have 2 buffers. ?The original > and the copied subsection. > var subView = new DataView(subBuffer); > > There's no more or less copies than slice. ?There's just a couple of small > temp VIEWs. That's correct, but we likely want to avoid the allocation of those views. In order to implement the proposed transfer of ownership semantics, ArrayBuffers will likely need to keep weak references to all views referring to them. This will make allocation of new views more expensive. -Ken >> >> -Ken >> >> On Mon, May 2, 2011 at 2:10 PM, Ben Vanik wrote: >> > Yeah - this is the scenario I'm concerned about, and as you pointed out >> > that >> > code is non-obvious and dirty. Just saying 'wrap it in function and drop >> > it >> > on a prototype' is a cop-out for clean API design. >> > >> > -- >> > Ben Vanik >> > http://www.noxa.org >> > >> > >> > On Mon, May 2, 2011 at 1:37 PM, Brian Cornell >> > wrote: >> >> >> >> So if you are using just an ArrayBuffer with a DataView and want to >> >> copy a >> >> subset of it (so the rest can be garbage collected, just keep a small >> >> part >> >> of it), is the recommendation to do the following? >> >> var buffer = DataView.buffer; >> >> var tmpToCopy = new Uint8Array(buffer, start, end); ?// Even though the >> >> data is not all Uint8s >> >> var tmpCopied = new Uint8Array(tmpToCopy); >> >> var subBuffer = tmpToCopy.buffer; >> >> var subView = new DataView(subBuffer); >> >> That seems convoluted and unobvious, especially the fact that I have to >> >> treat my many-typed data as all Uint8s just because only TypedArrays >> >> have >> >> ways to copy data. >> >> -Brian >> >> >> >> On Thu, Apr 28, 2011 at 5:06 PM, Kenneth Russell >> >> wrote: >> >>> >> >>> On Wed, Apr 27, 2011 at 10:48 AM, Chris Marrin >> >>> wrote: >> >>> > >> >>> > On Apr 21, 2011, at 4:12 PM, Kenneth Russell wrote: >> >>> > >> >>> >> >> >>> >> ... >> >>> >> As part of the planned Typed Array API changes to support efficient >> >>> >> communication with web workers, the plan is to add convenience >> >>> >> methods >> >>> >> to copy ArrayBuffers and possibly sub-portions of them. I think we >> >>> >> should invest our time in moving those changes forward. >> >>> > >> >>> > Why is it necessary to have functions to copy ArrayBuffers. Isn't >> >>> > the >> >>> > copy constructor in the TypedArrays sufficient? >> >>> >> >>> That's a fair point. During one of the face-to-face meetings with >> >>> Mozilla it seemed that if we used transfer-of-ownership for >> >>> ArrayBuffers sent via postMessage, then we had to make it easy to copy >> >>> them. You're right, though, that the slice() operation can be easily >> >>> implemented in pure JavaScript, with the only cost the creation of two >> >>> temporary Uint8Arrays. >> >>> >> >>> Should we just get rid of it and provide non-normative text showing >> >>> how it could be implemented? >> >>> >> >>> -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 >> >>> ----------------------------------------------------------- >> >>> >> >> >> > >> > >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Fri May 13 06:56:33 2011 From: bja...@ (Benoit Jacob) Date: Fri, 13 May 2011 06:56:33 -0700 (PDT) Subject: [Public WebGL] Some ARB_robustness questions In-Reply-To: <1162248212.103755.1305294841826.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <1458643557.103778.1305294993229.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hi, Is ARB_robustness only an extension for desktop OpenGL, or is there an ES version of it? If there is, does anyone know how well supported ARB_robustness is on mobile (Android, etc) devices? What about ANGLE's libGLESv2? Which is how most users get WebGL on Windows. Is it possible to implement parts of ARB_robustness on top of D3D9? What's the plan? Sorry if I'm missing an obvious reason why that's not needed. Thanks, Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri May 13 11:38:16 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 13 May 2011 11:38:16 -0700 Subject: [Public WebGL] Some ARB_robustness questions In-Reply-To: <1458643557.103778.1305294993229.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1162248212.103755.1305294841826.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <1458643557.103778.1305294993229.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, May 13, 2011 at 6:56 AM, Benoit Jacob wrote: > > Hi, > > Is ARB_robustness only an extension for desktop OpenGL, or is there an ES version of it? Right now it is only for desktop OpenGL. However, EGL already has a notion of losing the context, currently due to power management events. If the OpenGL ES / EGL drivers also triggered this when a given GPU operation took too long, then a WebGL implementation could build its denial of service defense on top of this mechanism. It would be better, though, if at least a subset of ARB_robustness were ported to EGL so that glGetGraphicsResetStatusARB() (which is supposed to be cheap) would be available. > If there is, does anyone know how well supported ARB_robustness is on mobile (Android, etc) devices? > > What about ANGLE's libGLESv2? Which is how most users get WebGL on Windows. Is it possible to implement parts of ARB_robustness on top of D3D9? What's the plan? Sorry if I'm missing an obvious reason why that's not needed. ANGLE exposes the EGL interface, and when Windows resets the GPU, the D3D9 device lost event is translated into an EGL context lost event. The WebGL implementation can use this as an indication that an "unknown" context reset occurred. Unfortunately, building on D3D, it isn't possible to be more precise and identify guilty vs. innocent contexts (to the best of my knowledge). In Chrome, the current plan is: - When ARB_robustness is available: - If a WebGL context gets a "guilty context reset" status, don't automatically restore it. Tell the user that WebGL caused the GPU to reset. Either tell them that the content won't be restored, or ask them if they want to continue running the content. - For the innocent context reset status, automatically restore the context. - For the unknown reset status, treat it the same as the guilty context reset status, only tell the user that WebGL *might* have caused the GPU to reset and ask if they want to continue running the content. - On Windows with ANGLE / EGL: - If eglMakeCurrent fails and eglGetError returns EGL_CONTEXT_LOST, treat this the same as an unknown reset status with ARB_robustness. -Ken > Thanks, > Benoit > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Fri May 13 12:30:58 2011 From: bja...@ (Benoit Jacob) Date: Fri, 13 May 2011 12:30:58 -0700 (PDT) Subject: [Public WebGL] Some ARB_robustness questions In-Reply-To: Message-ID: <1625718726.108245.1305315058499.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Thanks a lot, Ken, for the explanations. Benoit ----- Original Message ----- > On Fri, May 13, 2011 at 6:56 AM, Benoit Jacob > wrote: > > > > Hi, > > > > Is ARB_robustness only an extension for desktop OpenGL, or is there > > an ES version of it? > > Right now it is only for desktop OpenGL. However, EGL already has a > notion of losing the context, currently due to power management > events. If the OpenGL ES / EGL drivers also triggered this when a > given GPU operation took too long, then a WebGL implementation could > build its denial of service defense on top of this mechanism. It would > be better, though, if at least a subset of ARB_robustness were ported > to EGL so that glGetGraphicsResetStatusARB() (which is supposed to be > cheap) would be available. > > > If there is, does anyone know how well supported ARB_robustness is > > on mobile (Android, etc) devices? > > > > What about ANGLE's libGLESv2? Which is how most users get WebGL on > > Windows. Is it possible to implement parts of ARB_robustness on top > > of D3D9? What's the plan? Sorry if I'm missing an obvious reason why > > that's not needed. > > ANGLE exposes the EGL interface, and when Windows resets the GPU, the > D3D9 device lost event is translated into an EGL context lost event. > The WebGL implementation can use this as an indication that an > "unknown" context reset occurred. Unfortunately, building on D3D, it > isn't possible to be more precise and identify guilty vs. innocent > contexts (to the best of my knowledge). > > In Chrome, the current plan is: > > - When ARB_robustness is available: > - If a WebGL context gets a "guilty context reset" status, don't > automatically restore it. Tell the user that WebGL caused the GPU to > reset. Either tell them that the content won't be restored, or ask > them if they want to continue running the content. > - For the innocent context reset status, automatically restore the > context. > - For the unknown reset status, treat it the same as the guilty > context reset status, only tell the user that WebGL *might* have > caused the GPU to reset and ask if they want to continue running the > content. > > - On Windows with ANGLE / EGL: > - If eglMakeCurrent fails and eglGetError returns > EGL_CONTEXT_LOST, treat this the same as an unknown reset status with > ARB_robustness. > > -Ken > > > Thanks, > > Benoit > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jda...@ Fri May 13 20:53:23 2011 From: jda...@ (John Davis) Date: Fri, 13 May 2011 22:53:23 -0500 Subject: [Public WebGL] Vetex shader texture lookups Message-ID: To those needing a work around for the lack of texture lookups in the current Angle, here is a really cool way to handle noise based vertex displacements. http://www.pcprogramming.com/blog/caverns/caverns.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From xch...@ Fri May 13 21:12:38 2011 From: xch...@ (Bishop Z) Date: Fri, 13 May 2011 23:12:38 -0500 Subject: [Public WebGL] Fwd: WebGL online 3d narrative, future predictions References: <53EF2A96-653E-45D2-ACC7-C13FD5B731F8@designafternext.com> Message-ID: http://www.ro.me/tech/ the video was made with WebGL, which is: http://en.wikipedia.org/wiki/WebGL WebGL (Web-based Graphics Library) is a software library that extends the capability of the JavaScript programming language to allow it to generate interactive 3D graphics within any compatible web browser. This is the technology that the Mozilla Foundation championed through the HTML5 committee. The project was sponsored by Google, and the model viewer below the video only works in Chrome. along with the "online narrative" & examples, they released an Impressive open source 3d framework on top of webGL: https://github.com/mrdoob/three.js/wiki/API-Reference + full 3d transforms animators with a camera model + basic 3d object library + a model import standard (JSON for 3D) + full set of shaders: pong etc + fog, depth of field, basic particle system, sound triggers + render pipeline set for 2D post effects, like flash's pixel bender I expect this technology to see faster adoption that jQuery, which would be: in less than four years, 40% of the 10,000 most popular websites will be using webGL. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan...@ Mon May 16 03:27:40 2011 From: dan...@ (Daniel Koch) Date: Mon, 16 May 2011 06:27:40 -0400 Subject: [Public WebGL] Looking for webgl applications which use vertex textures In-Reply-To: References: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> Message-ID: Hi folks, Vertex texture support has now been implemented in ANGLE (as of r645). This functionality is available in Chrome 13.0.766.0. Thanks, Daniel On 2011-05-06, at 10:04 PM, Daniel Koch wrote: > No it's not been checked in yet. We were hoping to do some broader testing on it first :-) > > Daniel > > On 2011-05-06, at 9:50 PM, John Davis wrote: > >> I can try and put some stuff together if it's in the chrome canary build. Is it in there? >> >> On Fri, May 6, 2011 at 11:07 AM, Daniel Koch wrote: >> Hi folks, >> >> We're currently implementing support for vertex texture lookups in ANGLE and are looking for additional content to test the implementation. >> >> If you have any Webgl applications which either require vertex texture fetch, or will take advantage of this when advertised, can you please provide a link to the page in the ANGLE issue tracker: http://code.google.com/p/angleproject/issues/detail?id=95 >> >> Thanks, >> Daniel --- Daniel Koch -+- daniel...@ Senior Graphics Architect -+- TransGaming Inc. -+- www.transgaming.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon May 16 07:56:44 2011 From: cal...@ (Mark Callow) Date: Mon, 16 May 2011 16:56:44 +0200 Subject: [Public WebGL] Vetex shader texture lookups In-Reply-To: References: Message-ID: <4DD13B2C.7050806@hicorp.co.jp> It is not working for me in either FF4 or WebKit. In both cases, I first of all see a screen with an image and below it the message that I need a WebGL capable browser. That quickly disappears to be replaced by black with a message below telling me I can use the arrow keys to move left & right. Nothing further happens. Regards -Mark On 11/05/14 5:53, John Davis wrote: > To those needing a work around for the lack of texture lookups in the > current Angle, here is a really cool way to handle noise based vertex > displacements. > > http://www.pcprogramming.com/blog/caverns/caverns.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From cal...@ Mon May 16 07:59:16 2011 From: cal...@ (Mark Callow) Date: Mon, 16 May 2011 16:59:16 +0200 Subject: [Public WebGL] Fwd: WebGL online 3d narrative, future predictions In-Reply-To: References: <53EF2A96-653E-45D2-ACC7-C13FD5B731F8@designafternext.com> Message-ID: <4DD13BC4.5040601@hicorp.co.jp> On 11/05/14 6:12, Bishop Z wrote: > and the model viewer below the video only works in Chrome. Why is this? Regards -Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From bja...@ Mon May 16 08:04:36 2011 From: bja...@ (Benoit Jacob) Date: Mon, 16 May 2011 08:04:36 -0700 (PDT) Subject: [Public WebGL] Vetex shader texture lookups In-Reply-To: <4DD13B2C.7050806@hicorp.co.jp> Message-ID: <1471770685.120866.1305558276424.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Firefox is not yet using a recent enough version of ANGLE to have this feature. I will try to update our ANGLE copy as soon as possible, for Firefox 6. Benoit ----- Original Message ----- It is not working for me in either FF4 or WebKit. In both cases, I first of all see a screen with an image and below it the message that I need a WebGL capable browser. That quickly disappears to be replaced by black with a message below telling me I can use the arrow keys to move left & right. Nothing further happens. Regards -Mark On 11/05/14 5:53, John Davis wrote: To those needing a work around for the lack of texture lookups in the current Angle, here is a really cool way to handle noise based vertex displacements. http://www.pcprogramming.com/blog/caverns/caverns.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Mon May 16 08:37:05 2011 From: cal...@ (Mark Callow) Date: Mon, 16 May 2011 17:37:05 +0200 Subject: [Public WebGL] Vetex shader texture lookups In-Reply-To: <1471770685.120866.1305558276424.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1471770685.120866.1305558276424.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <4DD144A1.709@hicorp.co.jp> Umm! Its supposed to not need texture lookups... > To those needing a work around for the lack of texture lookups Regards -Mark On 11/05/16 17:04, Benoit Jacob wrote: > Firefox is not yet using a recent enough version of ANGLE to have this > feature. > > I will try to update our ANGLE copy as soon as possible, for Firefox 6. > > Benoit > > ------------------------------------------------------------------------ > > It is not working for me in either FF4 or WebKit. In both cases, I > first of all see a screen with an image and below it the message > that I need a WebGL capable browser. That quickly disappears to be > replaced by black with a message below telling me I can use the > arrow keys to move left & right. Nothing further happens. > > Regards > > -Mark > > > > > > On 11/05/14 5:53, John Davis wrote: > > To those needing a work around for the lack of texture lookups > in the current Angle, here is a really cool way to handle > noise based vertex displacements. > > http://www.pcprogramming.com/blog/caverns/caverns.html > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 408 bytes Desc: not available URL: From ste...@ Mon May 16 09:50:11 2011 From: ste...@ (ste...@) Date: Mon, 16 May 2011 09:50:11 -0700 Subject: [Public WebGL] Vetex shader texture lookups In-Reply-To: <4DD144A1.709@hicorp.co.jp> References: <1471770685.120866.1305558276424.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4DD144A1.709@hicorp.co.jp> Message-ID: <36d7faf3b331d31b99b86f16e1611821.squirrel@webmail.sjbaker.org> Yeah - to be 100% clear on this: There is hardware out there that is supported by WebGL but which does not support vertex texture lookups. So even after this is fixed in ANGLE and the fixes are on everyone's computers, you STILL cannot 100% rely on there being vertex texture support. The key here being that the specification requires you to query the number of vertex textures available - and the response to that is allowed to be zero - and it most certainly IS zero on a couple of older computers that I own. Hence all applications that use vertex textures should provide a work-around for the lack of them...or, at the very least, a grovelling apology to the user for the total inadequacy of your application! -- Steve > Umm! Its supposed to not need texture lookups... > >> To those needing a work around for the lack of texture lookups > > Regards > > -Mark > > > > > > On 11/05/16 17:04, Benoit Jacob wrote: >> Firefox is not yet using a recent enough version of ANGLE to have this >> feature. >> >> I will try to update our ANGLE copy as soon as possible, for Firefox 6. >> >> Benoit >> >> ------------------------------------------------------------------------ >> >> It is not working for me in either FF4 or WebKit. In both cases, I >> first of all see a screen with an image and below it the message >> that I need a WebGL capable browser. That quickly disappears to be >> replaced by black with a message below telling me I can use the >> arrow keys to move left & right. Nothing further happens. >> >> Regards >> >> -Mark >> >> >> >> >> >> On 11/05/14 5:53, John Davis wrote: >> >> To those needing a work around for the lack of texture lookups >> in the current Angle, here is a really cool way to handle >> noise based vertex displacements. >> >> http://www.pcprogramming.com/blog/caverns/caverns.html >> >> > ----------------------------------------------------------- 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 ale...@ Mon May 16 10:16:11 2011 From: ale...@ (Aleksandar Rodic) Date: Mon, 16 May 2011 10:16:11 -0700 Subject: [Public WebGL] Fwd: WebGL online 3d narrative, future predictions In-Reply-To: <4DD13BC4.5040601@hicorp.co.jp> References: <53EF2A96-653E-45D2-ACC7-C13FD5B731F8@designafternext.com> <4DD13BC4.5040601@hicorp.co.jp> Message-ID: Model viewer is entirely my responsibility. It worked fine in Firefox only few days before the release and I don't remember changing anything since then. I will look into this issue and fix it as soon as possible. Regards, -- Aleksandar Rodi? http://www.aleksandarrodic.com +1 510 761 5522 On Mon, May 16, 2011 at 7:59 AM, Mark Callow wrote: > On 11/05/14 6:12, Bishop Z wrote: > > and the model viewer below the video only works in Chrome. > Why is this? > > Regards > > -Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ale...@ Mon May 16 10:56:05 2011 From: ale...@ (Aleksandar Rodic) Date: Mon, 16 May 2011 10:56:05 -0700 Subject: [Public WebGL] Fwd: WebGL online 3d narrative, future predictions In-Reply-To: References: <53EF2A96-653E-45D2-ACC7-C13FD5B731F8@designafternext.com> <4DD13BC4.5040601@hicorp.co.jp> Message-ID: The bug was not WebGL related. It was a last minute optimization which pauses the rendering before the user scrolls down. For some reason document.body.scrollTop was returning 0 in Firefox. The optimization is now removed and the viewer should work in Firefox as soon as caches update. http://ro.me/tech Please let me know if you notice any other problems. Regards, -- Aleksandar Rodi? http://www.aleksandarrodic.com +1 510 761 5522 On Mon, May 16, 2011 at 10:16 AM, Aleksandar Rodic wrote: > Model viewer is entirely my responsibility. It worked fine in Firefox only > few days before the release and I don't remember changing anything since > then. I will look into this issue and fix it as soon as possible. > > Regards, > -- > Aleksandar Rodi? > http://www.aleksandarrodic.com > +1 510 761 5522 > > > > On Mon, May 16, 2011 at 7:59 AM, Mark Callow wrote: > >> On 11/05/14 6:12, Bishop Z wrote: >> > and the model viewer below the video only works in Chrome. >> Why is this? >> >> Regards >> >> -Mark >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon May 16 12:58:19 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 16 May 2011 12:58:19 -0700 Subject: [Public WebGL] Looking for webgl applications which use vertex textures In-Reply-To: References: <747FE7AE-E920-433A-9147-C0DF9366F077@transgaming.com> Message-ID: Thanks for implementing this! It looks like it is working great. -Ken On Mon, May 16, 2011 at 3:27 AM, Daniel Koch wrote: > Hi folks, > Vertex texture support has now been implemented in ANGLE (as of r645). > ?This?functionality is available in?Chrome 13.0.766.0. > Thanks, > Daniel > On 2011-05-06, at 10:04 PM, Daniel Koch wrote: > > No it's not been checked in yet. ?We were hoping to do some broader testing > on it first :-) > Daniel > On 2011-05-06, at 9:50 PM, John Davis wrote: > > I can try and put some stuff together if it's in the chrome canary build. > ?Is it in there? > > On Fri, May 6, 2011 at 11:07 AM, Daniel Koch wrote: >> >> Hi folks, >> We're currently implementing support for vertex texture lookups in ANGLE >> and are looking for additional content to test the implementation. >> If you have any Webgl applications which either require vertex texture >> fetch, or will take advantage of this when advertised, can you please >> provide a link to the page in the ANGLE issue >> tracker:?http://code.google.com/p/angleproject/issues/detail?id=95 >> Thanks, >> Daniel > > --- > ?? ? ? ? ? ? ? ? ? ? ? ?Daniel Koch -+-?daniel...@ > Senior Graphics Architect?-+-?TransGaming Inc. ?-+-?www.transgaming.com > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Mon May 16 15:11:05 2011 From: bja...@ (Benoit Jacob) Date: Mon, 16 May 2011 15:11:05 -0700 (PDT) Subject: [Public WebGL] Fwd: WebGL online 3d narrative, future predictions In-Reply-To: Message-ID: <1005543031.128294.1305583865740.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Hi Aleksandar, Thanks a lot for the quick fix! In case you're interested, we got a report of a few more issues: https://bugzilla.mozilla.org/show_bug.cgi?id=657118 Let me know if you think they're Firefox bugs. Thanks Benoit ----- Original Message ----- The bug was not WebGL related. It was a last minute optimization which pauses the rendering before the user scrolls down. For some reason document.body.scrollTop was returning 0 in Firefox. The optimization is now removed and the viewer should work in Firefox as soon as caches update. http://ro.me/tech Please let me know if you notice any other problems. Regards, -- Aleksandar Rodi? http://www.aleksandarrodic.com +1 510 761 5522 On Mon, May 16, 2011 at 10:16 AM, Aleksandar Rodic < aleksandar.xyz...@ > wrote: Model viewer is entirely my responsibility. It worked fine in Firefox only few days before the release and I don't remember changing anything since then. I will look into this issue and fix it as soon as possible. Regards, -- Aleksandar Rodi? http://www.aleksandarrodic.com +1 510 761 5522 On Mon, May 16, 2011 at 7:59 AM, Mark Callow < callow_mark...@ > wrote: On 11/05/14 6:12, Bishop Z wrote: > and the model viewer below the video only works in Chrome. Why is this? Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jda...@ Mon May 16 20:30:36 2011 From: jda...@ (John Davis) Date: Mon, 16 May 2011 22:30:36 -0500 Subject: [Public WebGL] Vetex shader texture lookups In-Reply-To: <36d7faf3b331d31b99b86f16e1611821.squirrel@webmail.sjbaker.org> References: <1471770685.120866.1305558276424.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4DD144A1.709@hicorp.co.jp> <36d7faf3b331d31b99b86f16e1611821.squirrel@webmail.sjbaker.org> Message-ID: Try it again in Chrome, should work now. For some reason the facebook link threw an exception on my desktop, but not my laptop (where I develop).. On Mon, May 16, 2011 at 11:50 AM, wrote: > > Yeah - to be 100% clear on this: There is hardware out there that is > supported by WebGL but which does not support vertex texture lookups. > > So even after this is fixed in ANGLE and the fixes are on everyone's > computers, you STILL cannot 100% rely on there being vertex texture > support. The key here being that the specification requires you to query > the number of vertex textures available - and the response to that is > allowed to be zero - and it most certainly IS zero on a couple of older > computers that I own. > > Hence all applications that use vertex textures should provide a > work-around for the lack of them...or, at the very least, a grovelling > apology to the user for the total inadequacy of your application! > > -- Steve > > > > Umm! Its supposed to not need texture lookups... > > > >> To those needing a work around for the lack of texture lookups > > > > Regards > > > > -Mark > > > > > > > > > > > > On 11/05/16 17:04, Benoit Jacob wrote: > >> Firefox is not yet using a recent enough version of ANGLE to have this > >> feature. > >> > >> I will try to update our ANGLE copy as soon as possible, for Firefox 6. > >> > >> Benoit > >> > >> ------------------------------------------------------------------------ > >> > >> It is not working for me in either FF4 or WebKit. In both cases, I > >> first of all see a screen with an image and below it the message > >> that I need a WebGL capable browser. That quickly disappears to be > >> replaced by black with a message below telling me I can use the > >> arrow keys to move left & right. Nothing further happens. > >> > >> Regards > >> > >> -Mark > >> > >> > >> > >> > >> > >> On 11/05/14 5:53, John Davis wrote: > >> > >> To those needing a work around for the lack of texture lookups > >> in the current Angle, here is a really cool way to handle > >> noise based vertex displacements. > >> > >> http://www.pcprogramming.com/blog/caverns/caverns.html > >> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bco...@ Wed May 18 14:35:04 2011 From: bco...@ (Brian Cornell) Date: Wed, 18 May 2011 14:35:04 -0700 Subject: [Public WebGL] More WebGL extensions In-Reply-To: <78D78B33-60B2-41E1-A35F-62784D1561C1@apple.com> References: <4ED589C0-5192-4FA9-B1EE-D70BDECEFE35@apple.com> <9346D4A8-22A1-4589-9D0D-B7289A6803AE@apple.com> <78D78B33-60B2-41E1-A35F-62784D1561C1@apple.com> Message-ID: Has any more thought or action been put into an extension for supporting multisampled renderbuffers? This would be a very useful feature as currently there is no way to render full quality off-screen. -Brian On Thu, Mar 31, 2011 at 12:48 PM, Chris Marrin wrote: > > > On Mar 31, 2011, at 12:33 PM, Kenneth Russell wrote: > > > On Thu, Mar 31, 2011 at 12:20 PM, Chris Marrin > wrote: > >> > >> On Mar 31, 2011, at 12:00 PM, Kenneth Russell wrote: > >> > >>>>> ...Also, we would need to specify interactions with > OES_texture_float. > >>>>> Multisampled floating-point render targets would be extremely useful > >>>>> for high quality HDR rendering. > >>>> > >>>> Sure, but that should be yet another extension, since it is possible > to support one without the other. > >>> > >>> I don't think a third extension is needed. All that's needed is to > >>> specify that if both the OES_texture_float and this multisampling > >>> extension are enabled, then multisampling is enabled for > >>> floating-point renderbuffers (if the implementation supports it -- and > >>> the framebuffer's status will be FRAMEBUFFER_UNSUPPORTED otherwise). > >> > >> I don't know the reality in the drivers, but my concern is that there > may be some drivers that support OES_texture_float and some form of > framebuffer multisampling, but can't do multisampling with floating point > texture buffers. The author needs to know such a situation exists to know > how to allocate the supporting renderbuffers in the framebuffer. > >> > >> But that may be a moot point. Maybe you always get one with the other? > > > > Oops, my fault. I was confusing support for floating-point textures > > and floating-point renderbuffers. Multisampled FBOs require the use of > > renderbuffers, not textures, for the color attachment. Enabling > > OES_texture_float wouldn't affect the behavior of this multisampling > > extension. > > Ah, right. The model would have to be render into a multisample FBO with a > multisample renderbuffer then use a multisample blit (or > glResolveMultisampleFramebufferAPPLE for iOS) to get the result into a > normal, non-multisampled texture. > > > > If we wanted that behavior, you're right, we'd need to spec another > > extension adding floating-point renderbuffers. I don't know whether > > there are any OES extensions for that functionality today. > > Yeah, I haven't seen such a thing yet. But it's interesting that > multisampling essentially results in higher precision pixel values. An > interesting intermediate implementation could blit an integer multisample > renderbuffer into a floating point texture. But that's probably not valuable > enough for anyone to implement. > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed May 18 16:45:38 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 18 May 2011 16:45:38 -0700 Subject: [Public WebGL] More WebGL extensions In-Reply-To: References: <4ED589C0-5192-4FA9-B1EE-D70BDECEFE35@apple.com> <9346D4A8-22A1-4589-9D0D-B7289A6803AE@apple.com> <78D78B33-60B2-41E1-A35F-62784D1561C1@apple.com> Message-ID: No -- other work has taken priority for the WebGL WG in recent weeks. -Ken On Wed, May 18, 2011 at 2:35 PM, Brian Cornell wrote: > Has any more thought or action been put into an extension for supporting > multisampled renderbuffers? This would be a very useful feature as currently > there is no way to render full quality off-screen. > -Brian > > On Thu, Mar 31, 2011 at 12:48 PM, Chris Marrin wrote: >> >> >> On Mar 31, 2011, at 12:33 PM, Kenneth Russell wrote: >> >> > On Thu, Mar 31, 2011 at 12:20 PM, Chris Marrin >> > wrote: >> >> >> >> On Mar 31, 2011, at 12:00 PM, Kenneth Russell wrote: >> >> >> >>>>> ...Also, we would need to specify interactions with >> >>>>> OES_texture_float. >> >>>>> Multisampled floating-point render targets would be extremely useful >> >>>>> for high quality HDR rendering. >> >>>> >> >>>> Sure, but that should be yet another extension, since it is possible >> >>>> to support one without the other. >> >>> >> >>> I don't think a third extension is needed. All that's needed is to >> >>> specify that if both the OES_texture_float and this multisampling >> >>> extension are enabled, then multisampling is enabled for >> >>> floating-point renderbuffers (if the implementation supports it -- and >> >>> the framebuffer's status will be FRAMEBUFFER_UNSUPPORTED otherwise). >> >> >> >> I don't know the reality in the drivers, but my concern is that there >> >> may be some drivers that support OES_texture_float and some form of >> >> framebuffer multisampling, but can't do multisampling with floating point >> >> texture buffers. The author needs to know such a situation exists to know >> >> how to allocate the supporting renderbuffers in the framebuffer. >> >> >> >> But that may be a moot point. Maybe you always get one with the other? >> > >> > Oops, my fault. I was confusing support for floating-point textures >> > and floating-point renderbuffers. Multisampled FBOs require the use of >> > renderbuffers, not textures, for the color attachment. Enabling >> > OES_texture_float wouldn't affect the behavior of this multisampling >> > extension. >> >> Ah, right. The model would have to be render into a multisample FBO with a >> multisample renderbuffer then use a multisample blit (or >> glResolveMultisampleFramebufferAPPLE for iOS) to get the result into a >> normal, non-multisampled texture. >> > >> > If we wanted that behavior, you're right, we'd need to spec another >> > extension adding floating-point renderbuffers. I don't know whether >> > there are any OES extensions for that functionality today. >> >> Yeah, I haven't seen such a thing yet. But it's interesting that >> multisampling essentially results in higher precision pixel values. An >> interesting intermediate implementation could blit an integer multisample >> renderbuffer into a floating point texture. But that's probably not valuable >> enough for anyone to implement. >> >> ----- >> ~Chris >> cmarrin...@ >> >> >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From van...@ Thu May 19 10:37:09 2011 From: van...@ (Vangelis Kokkevis) Date: Thu, 19 May 2011 10:37:09 -0700 Subject: [Public WebGL] How to check for WebGL support Message-ID: A recurring issue with sites that want to use WebGL is that there's currently no good light-weight way to check whether WebGL is supported in a particular client. We have a couple of mechanisms in place but they all have drawbacks: 1. Statically check for window.WebGLRenderingContext : This will return false positives, e.g. when running on blacklisted configurations, when WebGL is explicitly disabled via some user pref, etc. 2. Create a WebGL context and inspect the result : Creating a context is expensive (slow) and when you only need to know whether WebGL is supported the resulting context isn't really needed. One possible solution would be to define window.WebGLRenderingContext only if both the browser supports WebGL and all the blacklist / user-pref / etc. tests succeed. Current pages will have to be tweaked to report a more generic "WebGL is not supported on your configuration" type of message rather than "Your browser does not support WebGL". If they really need to know why it's not supported they can go one step further and try to create the WebGL context and decipher any context creation error. Obviously there will still be some false positives with this mechanism but they will hopefully be rare. Thoughts? Vangelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Thu May 19 10:40:35 2011 From: tpa...@ (Tony Parisi) Date: Thu, 19 May 2011 10:40:35 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: Hey Vangelis I like that idea a lot. Keep it simple and clean for the developers, and efficient. I say yes. Tony On Thu, May 19, 2011 at 10:37 AM, Vangelis Kokkevis wrote: > A recurring issue with sites that want to use WebGL is that there's > currently no good light-weight way to check whether WebGL is supported in a > particular client. We have a couple of mechanisms in place but they all have > drawbacks: > > 1. Statically check for window.WebGLRenderingContext : This will return > false positives, e.g. when running on blacklisted configurations, when WebGL > is explicitly disabled via some user pref, etc. > 2. Create a WebGL context and inspect the result : Creating a context is > expensive (slow) and when you only need to know whether WebGL is supported > the resulting context isn't really needed. > > One possible solution would be to define window.WebGLRenderingContext only > if both the browser supports WebGL and all the blacklist / user-pref / etc. > tests succeed. Current pages will have to be tweaked to report a more > generic "WebGL is not supported on your configuration" type of message > rather than "Your browser does not support WebGL". If they really need to > know why it's not supported they can go one step further and try to create > the WebGL context and decipher any context creation error. > > Obviously there will still be some false positives with this mechanism but > they will hopefully be rare. > > Thoughts? > > > Vangelis > > > > > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu May 19 10:57:41 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 19 May 2011 10:57:41 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 10:37 AM, Vangelis Kokkevis wrote: > A recurring issue with sites that want to use WebGL is that there's > currently no good light-weight way to check whether WebGL is supported in a > particular client. We have a couple of mechanisms in place but they all have > drawbacks: > 1. Statically check for?window.WebGLRenderingContext : ?This will return > false positives, e.g. when running on blacklisted configurations, when WebGL > is explicitly disabled via some user pref, etc. > 2. Create a WebGL context and inspect the result : Creating a context is > expensive (slow) and when you only need to know whether WebGL is supported > the resulting context isn't really needed. In my opinion the problem with creating a context is not really that doing so is expensive; there have been other discussions recently about making WebGL context creation asynchronous, and the conclusion so far was that it's fast enough to not warrant the spec change right now. The main issue is that implementations are still not robust enough to ensure that creating a context won't cause problems. For example, there was a bug in Chrome a couple of releases ago where if WebGL context creation failed, the page would freeze. > One possible solution would be to define window.WebGLRenderingContext only > if both the browser supports WebGL and all the blacklist / user-pref / etc. > ?tests succeed. ?Current pages will have to be tweaked to report a more > generic "WebGL is not supported on your configuration" type of message > rather than "Your browser does not support WebGL". ?If they really need to > know why it's not supported they can go one step further and try to create > the WebGL context and decipher any context creation error. > Obviously there will still be some false positives with this mechanism but > they will hopefully be rare. I'd like to point out that Chrome used to behave in this way, but the behavior was deliberately changed based on feedback from Mark Callow; see http://crbug.com/77110 . I don't have a strong opinion about whether to revert to the earlier behavior and formally specify it. -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 bja...@ Thu May 19 10:59:16 2011 From: bja...@ (Benoit Jacob) Date: Thu, 19 May 2011 10:59:16 -0700 (PDT) Subject: [Public WebGL] How to check for WebGL support In-Reply-To: Message-ID: <1501815257.164908.1305827956483.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- A recurring issue with sites that want to use WebGL is that there's currently no good light-weight way to check whether WebGL is supported in a particular client. We have a couple of mechanisms in place but they all have drawbacks: 1. Statically check for window.WebGLRenderingContext : This will return false positives, e.g. when running on blacklisted configurations, when WebGL is explicitly disabled via some user pref, etc. 2. Create a WebGL context and inspect the result : Creating a context is expensive (slow) and when you only need to know whether WebGL is supported the resulting context isn't really needed. One possible solution would be to define window.WebGLRenderingContext only if both the browser supports WebGL and all the blacklist / user-pref / etc. tests succeed. Current pages will have to be tweaked to report a more generic "WebGL is not supported on your configuration" type of message rather than "Your browser does not support WebGL". If they really need to know why it's not supported they can go one step further and try to create the WebGL context and decipher any context creation error. Obviously there will still be some false positives with this mechanism but they will hopefully be rare. Thoughts? In any case, in order to get a 100% reliable answer, there is no way around creating an OpenGL context. Indeed, even if the setup is not explicitly blacklisted, there could be a problem with it that we only detect when creating an OpenGL context, and also a WebGL implementation may require the OpenGL implementation to meet certain requirements that can only be checked from an OpenGL context, say with glGetIntegerv. So, for a 100% reliable answer, calling getContext() isn't much costlier than is necessary. If one wanted your proposal to be 100% reliable, it would have to do essentially the same at startup, as (as far as I know?) the WebGLRenderingContext interface would have to be defined at startup to ensure that it's defined before scripts start checking for its existence (correct me if I'm wrong here?). Another disadvantage is that in the common case where the user only uses one WebGL context during his browsing session, one would now be creating 2 WebGL contexts instead of 1. If a less-than-100% reliable answer is enough, so that we don't need to create a OpenGL context, I'm still afraid of having to check the WebGL blacklist on startup before knowing whether it's going to be used. I do agree with the need to offer better information about WebGL context creation failure, either via an exception or via webglcontextcreation error, what I don't know is if there can be any better API to detect WebGL availability than just calling getContext(). Cheers, Benoit Vangelis -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu May 19 11:07:01 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 19 May 2011 11:07:01 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 10:37 AM, Vangelis Kokkevis wrote: > A recurring issue with sites that want to use WebGL is that there's > currently no good light-weight way to check whether WebGL is supported in a > particular client. We have a couple of mechanisms in place but they all have > drawbacks: > > 1. Statically check for window.WebGLRenderingContext : This will return > false positives, e.g. when running on blacklisted configurations, when WebGL > is explicitly disabled via some user pref, etc. > 2. Create a WebGL context and inspect the result : Creating a context is > expensive (slow) and when you only need to know whether WebGL is supported > the resulting context isn't really needed. > > One possible solution would be to define window.WebGLRenderingContext only > if both the browser supports WebGL and all the blacklist / user-pref / etc. > tests succeed. Current pages will have to be tweaked to report a more > generic "WebGL is not supported on your configuration" type of message > rather than "Your browser does not support WebGL". If they really need to > know why it's not supported they can go one step further and try to create > the WebGL context and decipher any context creation error. > That doesn't seem like it would not be a good solution because it means the app will have no way to tell the user "hey, if you just update your drivers you can run my app". If window.WebGLRenderingContext does not exist then it makes no sense to be able to call context.getContext("webgl") since that's what it's supposed to return. > > Obviously there will still be some false positives with this mechanism but > they will hopefully be rare. > > Thoughts? > > > Vangelis > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From van...@ Thu May 19 11:10:59 2011 From: van...@ (Vangelis Kokkevis) Date: Thu, 19 May 2011 11:10:59 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: <1501815257.164908.1305827956483.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1501815257.164908.1305827956483.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, May 19, 2011 at 10:59 AM, Benoit Jacob wrote: > > > ------------------------------ > > A recurring issue with sites that want to use WebGL is that there's > currently no good light-weight way to check whether WebGL is supported in a > particular client. We have a couple of mechanisms in place but they all have > drawbacks: > > 1. Statically check for window.WebGLRenderingContext : This will return > false positives, e.g. when running on blacklisted configurations, when WebGL > is explicitly disabled via some user pref, etc. > 2. Create a WebGL context and inspect the result : Creating a context is > expensive (slow) and when you only need to know whether WebGL is supported > the resulting context isn't really needed. > > One possible solution would be to define window.WebGLRenderingContext only > if both the browser supports WebGL and all the blacklist / user-pref / etc. > tests succeed. Current pages will have to be tweaked to report a more > generic "WebGL is not supported on your configuration" type of message > rather than "Your browser does not support WebGL". If they really need to > know why it's not supported they can go one step further and try to create > the WebGL context and decipher any context creation error. > > Obviously there will still be some false positives with this mechanism but > they will hopefully be rare. > > Thoughts? > > In any case, in order to get a 100% reliable answer, there is no way around > creating an OpenGL context. Indeed, even if the setup is not explicitly > blacklisted, there could be a problem with it that we only detect when > creating an OpenGL context, and also a WebGL implementation may require the > OpenGL implementation to meet certain requirements that can only be checked > from an OpenGL context, say with glGetIntegerv. > > So, for a 100% reliable answer, calling getContext() isn't much costlier > than is necessary. If one wanted your proposal to be 100% reliable, it would > have to do essentially the same at startup, as (as far as I know?) the > WebGLRenderingContext interface would have to be defined at startup to > ensure that it's defined before scripts start checking for its existence > (correct me if I'm wrong here?). > > Another disadvantage is that in the common case where the user only uses > one WebGL context during his browsing session, one would now be creating 2 > WebGL contexts instead of 1. > > If a less-than-100% reliable answer is enough, so that we don't need to > create a OpenGL context, I'm still afraid of having to check the WebGL > blacklist on startup before knowing whether it's going to be used. > > I would settle for a less-than-100% solution that's quick. I know that at least in Chrome we do the blacklist checks on startup so it wouldn't affect performance. I would imagine that any h/w accelerated browser these days would have to check its gpu blacklist very early on, not just for WebGL. Do we really have many cases where h/w isn't blacklisted but still fails context creation due to lack of specific capabilities. And if so maybe these cases need to be identified and put in the blacklist. The point is that if I only want to know whether WebGL is supported on the system (say I want to know whether to display a link to the 3D version of my product or not) then creating a context and subsequently deleting it is a very heavy handed approach. > I do agree with the need to offer better information about WebGL context > creation failure, either via an exception or via webglcontextcreation error, > what I don't know is if there can be any better API to detect WebGL > availability than just calling getContext(). > > Cheers, > Benoit > > > > Vangelis > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu May 19 11:13:03 2011 From: bja...@ (Benoit Jacob) Date: Thu, 19 May 2011 11:13:03 -0700 (PDT) Subject: [Public WebGL] How to check for WebGL support In-Reply-To: Message-ID: <1114468600.165106.1305828783906.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Thu, May 19, 2011 at 10:37 AM, Vangelis Kokkevis > wrote: > > A recurring issue with sites that want to use WebGL is that there's > > currently no good light-weight way to check whether WebGL is > > supported in a > > particular client. We have a couple of mechanisms in place but they > > all have > > drawbacks: > > 1. Statically check for window.WebGLRenderingContext : This will > > return > > false positives, e.g. when running on blacklisted configurations, > > when WebGL > > is explicitly disabled via some user pref, etc. > > 2. Create a WebGL context and inspect the result : Creating a > > context is > > expensive (slow) and when you only need to know whether WebGL is > > supported > > the resulting context isn't really needed. > > In my opinion the problem with creating a context is not really that > doing so is expensive; there have been other discussions recently > about making WebGL context creation asynchronous, and the conclusion > so far was that it's fast enough to not warrant the spec change right > now. The main issue is that implementations are still not robust > enough to ensure that creating a context won't cause problems. I don't see any other solution to this problem than blacklists (unless perhaps one would go to the extreme of running WebGL in a separate process). The idea of defining WebGLRenderingContext only if it's not blacklisted, does not seem to offer any more protection: if the system is blacklisted, then getContext doesn't cause problems anyway. Benoit > For > example, there was a bug in Chrome a couple of releases ago where if > WebGL context creation failed, the page would freeze. > > > One possible solution would be to define > > window.WebGLRenderingContext only > > if both the browser supports WebGL and all the blacklist / user-pref > > / etc. > > ?tests succeed. Current pages will have to be tweaked to report a > > ?more > > generic "WebGL is not supported on your configuration" type of > > message > > rather than "Your browser does not support WebGL". If they really > > need to > > know why it's not supported they can go one step further and try to > > create > > the WebGL context and decipher any context creation error. > > Obviously there will still be some false positives with this > > mechanism but > > they will hopefully be rare. > > I'd like to point out that Chrome used to behave in this way, but the > behavior was deliberately changed based on feedback from Mark Callow; > see http://crbug.com/77110 . I don't have a strong opinion about > whether to revert to the earlier behavior and formally specify it. > > -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 > ----------------------------------------------------------- ----------------------------------------------------------- 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 cvi...@ Thu May 19 11:16:59 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 20 May 2011 01:16:59 +0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: On Fri, May 20, 2011 at 01:07, Gregg Tavares (wrk) wrote: > That doesn't seem like it would not be a good solution because it means the > app will have no way to tell the user "hey, if you just update your drivers > you can run my app". And as discussed elsewhere, the app should not even care, browsers should take care of this (last but not least because exposing to applications driver version or even the fact that the user is using an outdated driver might be a privacy/security issue). Ideally it's a yes/no for the app to the question "Can I use WebGL now?". Information and/or troubleshooting can/should be done by the browser. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From van...@ Thu May 19 11:18:31 2011 From: van...@ (Vangelis Kokkevis) Date: Thu, 19 May 2011 11:18:31 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 11:07 AM, Gregg Tavares (wrk) wrote: > > > On Thu, May 19, 2011 at 10:37 AM, Vangelis Kokkevis wrote: > >> A recurring issue with sites that want to use WebGL is that there's >> currently no good light-weight way to check whether WebGL is supported in a >> particular client. We have a couple of mechanisms in place but they all have >> drawbacks: >> >> 1. Statically check for window.WebGLRenderingContext : This will return >> false positives, e.g. when running on blacklisted configurations, when WebGL >> is explicitly disabled via some user pref, etc. >> 2. Create a WebGL context and inspect the result : Creating a context is >> expensive (slow) and when you only need to know whether WebGL is supported >> the resulting context isn't really needed. >> >> One possible solution would be to define window.WebGLRenderingContext >> only if both the browser supports WebGL and all the blacklist / user-pref / >> etc. tests succeed. Current pages will have to be tweaked to report a more >> generic "WebGL is not supported on your configuration" type of message >> rather than "Your browser does not support WebGL". If they really need to >> know why it's not supported they can go one step further and try to create >> the WebGL context and decipher any context creation error. >> > > > That doesn't seem like it would not be a good solution because it means the > app will have no way to tell the user "hey, if you just update your drivers > you can run my app". > If window.WebGLRenderingContext does not exist then it makes no sense to be > able to call context.getContext("webgl") since that's what it's supposed to > return. > > Hmm, fair point but it comes down to what we define the presence of window.WebGLRenderingContext to really mean. window.myFantasicRenderingContext isn't defined but that doesn't prevent me from calling canvas.getContext("myFantasticRenderingContext") . It will just return null.. CSS has media queries for checking whether various features are available. It feels that we need something similar here too. > >> >> Obviously there will still be some false positives with this mechanism but >> they will hopefully be rare. >> >> Thoughts? >> >> >> Vangelis >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu May 19 11:21:48 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 19 May 2011 11:21:48 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: I guess I don't understand the use case. Either you want to use WebGL in which case you are going to have to call canvas.getContext("webgl") with whatever parameters your app needs and see if it succeeds. You have to pay the startup cost since you are using WebGL. If it fails (blacklisted, no webgl) there is no startup cost or shouldn't be. Why do you need another way to check? -------------- next part -------------- An HTML attachment was scrubbed... URL: From van...@ Thu May 19 11:23:52 2011 From: van...@ (Vangelis Kokkevis) Date: Thu, 19 May 2011 11:23:52 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 11:21 AM, Gregg Tavares (wrk) wrote: > I guess I don't understand the use case. > > Either you want to use WebGL in which case you are going to have to call > canvas.getContext("webgl") with whatever parameters your app needs and see > if it succeeds. You have to pay the startup cost since you are using WebGL. > > If it fails (blacklisted, no webgl) there is no startup cost or shouldn't > be. > > Why do you need another way to check? > > Because I have a page that needs to decide whether to offer links to WebGL content or not but the page itself doesn't need the gl contexts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gle...@ Thu May 19 11:27:55 2011 From: gle...@ (Glenn Maynard) Date: Thu, 19 May 2011 14:27:55 -0400 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: Message-ID: On Thu, May 19, 2011 at 1:37 PM, Vangelis Kokkevis wrote: > > One possible solution would be to define window.WebGLRenderingContext only > if both the browser supports WebGL and all the blacklist / user-pref / etc. > tests succeed. > A problem someone pointed out at one point is that browsers (Chrome, as I recall) want to be able to update the GPU blacklist at runtime while the browser is running, without forcing a browser restart. However, once you expose WebGLRenderingContext to a window, you can't remove it. I think there's nothing wrong with browsers not exposing WebGL interfaces when it's known in advance that WebGL isn't available, but pages still couldn't depend on it. They'd still end up having to create a context to check whether it actually works. On Thu, May 19, 2011 at 2:21 PM, Gregg Tavares (wrk) wrote: > I guess I don't understand the use case. > Either you want to use WebGL in which case you are going to have to call canvas.getContext("webgl") with whatever parameters your app needs and see if it succeeds. You have to pay the startup cost since you are using WebGL. > If it fails (blacklisted, no webgl) there is no startup cost or shouldn't be. > Why do you need another way to check? You may want to grey out or remove WebGL-related features from your site if it's known in advance that it's not going to work, instead of presenting the user with unusable features. Not every use of WebGL is something that's started up immediately when a page loads. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu May 19 11:37:27 2011 From: bja...@ (Benoit Jacob) Date: Thu, 19 May 2011 11:37:27 -0700 (PDT) Subject: [Public WebGL] How to check for WebGL support In-Reply-To: Message-ID: <10921292.165452.1305830247715.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- On Thu, May 19, 2011 at 10:59 AM, Benoit Jacob < bjacob...@ > wrote: A recurring issue with sites that want to use WebGL is that there's currently no good light-weight way to check whether WebGL is supported in a particular client. We have a couple of mechanisms in place but they all have drawbacks: 1. Statically check for window.WebGLRenderingContext : This will return false positives, e.g. when running on blacklisted configurations, when WebGL is explicitly disabled via some user pref, etc. 2. Create a WebGL context and inspect the result : Creating a context is expensive (slow) and when you only need to know whether WebGL is supported the resulting context isn't really needed. One possible solution would be to define window.WebGLRenderingContext only if both the browser supports WebGL and all the blacklist / user-pref / etc. tests succeed. Current pages will have to be tweaked to report a more generic "WebGL is not supported on your configuration" type of message rather than "Your browser does not support WebGL". If they really need to know why it's not supported they can go one step further and try to create the WebGL context and decipher any context creation error. Obviously there will still be some false positives with this mechanism but they will hopefully be rare. Thoughts? In any case, in order to get a 100% reliable answer, there is no way around creating an OpenGL context. Indeed, even if the setup is not explicitly blacklisted, there could be a problem with it that we only detect when creating an OpenGL context, and also a WebGL implementation may require the OpenGL implementation to meet certain requirements that can only be checked from an OpenGL context, say with glGetIntegerv. So, for a 100% reliable answer, calling getContext() isn't much costlier than is necessary. If one wanted your proposal to be 100% reliable, it would have to do essentially the same at startup, as (as far as I know?) the WebGLRenderingContext interface would have to be defined at startup to ensure that it's defined before scripts start checking for its existence (correct me if I'm wrong here?). Another disadvantage is that in the common case where the user only uses one WebGL context during his browsing session, one would now be creating 2 WebGL contexts instead of 1. If a less-than-100% reliable answer is enough, so that we don't need to create a OpenGL context, I'm still afraid of having to check the WebGL blacklist on startup before knowing whether it's going to be used. I would settle for a less-than-100% solution that's quick. I know that at least in Chrome we do the blacklist checks on startup so it wouldn't affect performance. I would imagine that any h/w accelerated browser these days would have to check its gpu blacklist very early on, not just for WebGL. That's true, but even so, each blacklist lookup has a cost, and I think we're all equally paranoid about startup performance ;-) I guess my main concern here is that it's not really needed to make that a startup cost. Why not instead offer a isWebGLAvailable() function that would do the work when it's first called? Do we really have many cases where h/w isn't blacklisted but still fails context creation due to lack of specific capabilities. And if so maybe these cases need to be identified and put in the blacklist. Currently we have quite a few cases, for example Intel 945 in Ubuntu 11.04 doesn't have OpenGL 2, and we don't have an explicit blacklist entry for that, we currently rely on context creation to fail. We don't currently require any particular OpenGL parameter for WebGL, but I find it conceivable that an implementation would. For example, an implementation could decide to require DEPTH_STENCIL renderbuffers, or it could require the presence of certain texture formats, etc. I agree that any of that could be added to the blacklist. It's just that it's nice not having to add more blacklist entries, when we could instead check the actual OpenGL parameters. Benoit -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu May 19 11:38:41 2011 From: bja...@ (Benoit Jacob) Date: Thu, 19 May 2011 11:38:41 -0700 (PDT) Subject: [Public WebGL] How to check for WebGL support In-Reply-To: Message-ID: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- On Thu, May 19, 2011 at 1:37 PM, Vangelis Kokkevis < vangelis...@ > wrote: One possible solution would be to define window.WebGLRenderingContext only if both the browser supports WebGL and all the blacklist / user-pref / etc. tests succeed. A problem someone pointed out at one point is that browsers (Chrome, as I recall) want to be able to update the GPU blacklist at runtime while the browser is running, without forcing a browser restart. However, once you expose WebGLRenderingContext to a window, you can't remove it. Good point; see my isWebGLAvailable() suggestion in the other email I just sent --- that would also address that concern. Benoit I think there's nothing wrong with browsers not exposing WebGL interfaces when it's known in advance that WebGL isn't available, but pages still couldn't depend on it. They'd still end up having to create a context to check whether it actually works. On Thu, May 19, 2011 at 2:21 PM, Gregg Tavares (wrk) < gman...@ > wrote: > I guess I don't understand the use case. > Either you want to use WebGL in which case you are going to have to call canvas.getContext("webgl") with whatever parameters your app needs and see if it succeeds. You have to pay the startup cost since you are using WebGL. > If it fails (blacklisted, no webgl) there is no startup cost or shouldn't be. > Why do you need another way to check? You may want to grey out or remove WebGL-related features from your site if it's known in advance that it's not going to work, instead of presenting the user with unusable features. Not every use of WebGL is something that's started up immediately when a page loads. -- Glenn Maynard -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Thu May 19 11:49:53 2011 From: tpa...@ (Tony Parisi) Date: Thu, 19 May 2011 11:49:53 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: I would caution that we be careful expanding the blacklist for reasons like this... Tony On Thu, May 19, 2011 at 11:38 AM, Benoit Jacob wrote: > > > ------------------------------ > > On Thu, May 19, 2011 at 1:37 PM, Vangelis Kokkevis wrote: >> >> One possible solution would be to define window.WebGLRenderingContext >> only if both the browser supports WebGL and all the blacklist / user-pref / >> etc. tests succeed. >> > > A problem someone pointed out at one point is that browsers (Chrome, as I > recall) want to be able to update the GPU blacklist at runtime while the > browser is running, without forcing a browser restart. However, once you > expose WebGLRenderingContext to a window, you can't remove it. > > Good point; see my isWebGLAvailable() suggestion in the other email I just > sent --- that would also address that concern. > > Benoit > > > I think there's nothing wrong with browsers not exposing WebGL interfaces > when it's known in advance that WebGL isn't available, but pages still > couldn't depend on it. They'd still end up having to create a context to > check whether it actually works. > > > On Thu, May 19, 2011 at 2:21 PM, Gregg Tavares (wrk) > wrote: > > I guess I don't understand the use case. > > Either you want to use WebGL in which case you are going to have to call > canvas.getContext("webgl") with whatever parameters your app needs and see > if it succeeds. You have to pay the startup cost since you are using WebGL. > > If it fails (blacklisted, no webgl) there is no startup cost or shouldn't > be. > > Why do you need another way to check? > > You may want to grey out or remove WebGL-related features from your site if > it's known in advance that it's not going to work, instead of presenting the > user with unusable features. Not every use of WebGL is something that's > started up immediately when a page loads. > > -- > Glenn Maynard > > > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe -------------- next part -------------- An HTML attachment was scrubbed... URL: From van...@ Thu May 19 11:56:27 2011 From: van...@ (Vangelis Kokkevis) Date: Thu, 19 May 2011 11:56:27 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, May 19, 2011 at 11:38 AM, Benoit Jacob wrote: > > > ------------------------------ > > On Thu, May 19, 2011 at 1:37 PM, Vangelis Kokkevis wrote: >> >> One possible solution would be to define window.WebGLRenderingContext >> only if both the browser supports WebGL and all the blacklist / user-pref / >> etc. tests succeed. >> > > A problem someone pointed out at one point is that browsers (Chrome, as I > recall) want to be able to update the GPU blacklist at runtime while the > browser is running, without forcing a browser restart. However, once you > expose WebGLRenderingContext to a window, you can't remove it. > > Good point; see my isWebGLAvailable() suggestion in the other email I just > sent --- that would also address that concern. > Chrome does indeed support out-of-band blacklist updates but the results typically only take effect in new tabs. We won't shut down a running WebGL context and cannot change the behavior of already loaded pages. Defining a query method would work fine too although having both a variable defined on window and a method will be confusing. Vangelis > > Benoit > > > I think there's nothing wrong with browsers not exposing WebGL interfaces > when it's known in advance that WebGL isn't available, but pages still > couldn't depend on it. They'd still end up having to create a context to > check whether it actually works. > > > On Thu, May 19, 2011 at 2:21 PM, Gregg Tavares (wrk) > wrote: > > I guess I don't understand the use case. > > Either you want to use WebGL in which case you are going to have to call > canvas.getContext("webgl") with whatever parameters your app needs and see > if it succeeds. You have to pay the startup cost since you are using WebGL. > > If it fails (blacklisted, no webgl) there is no startup cost or shouldn't > be. > > Why do you need another way to check? > > You may want to grey out or remove WebGL-related features from your site if > it's known in advance that it's not going to work, instead of presenting the > user with unusable features. Not every use of WebGL is something that's > started up immediately when a page loads. > > -- > Glenn Maynard > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu May 19 11:58:43 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 19 May 2011 11:58:43 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: So I know suspect some browsers are planning to fallback to software rendering if a user's card is blacklisted. In that case you'll almost never fail and isWebGLAvailable will be useless. I'm sure some will be upset that software rendering is slow and they'd like to know if they are going to get software rendering beforehand but in reality lots of GPUs are slow, some are even slower than a good software renderer so knowing that you have hardware or software is not going to help you know if your app will run reasonably. The only way to know is to try it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Thu May 19 12:01:29 2011 From: tpa...@ (Tony Parisi) Date: Thu, 19 May 2011 12:01:29 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: <1438627242.165466.1305830321112.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: It would sure be nice as a web developer to know whether the software fallback is going to happen or not, via some other defined property. I don't think it is reasonable to hide it from the developer... On Thu, May 19, 2011 at 11:58 AM, Gregg Tavares (wrk) wrote: > So I know suspect some browsers are planning to fallback to software > rendering if a user's card is blacklisted. > In that case you'll almost never fail and isWebGLAvailable will be useless. > > I'm sure some will be upset that software rendering is slow and they'd like > to know if they are going > to get software rendering beforehand but in reality lots of GPUs are slow, > some are even slower than > a good software renderer so knowing that you have hardware or software is > not going to help you know > if your app will run reasonably. > > The only way to know is to try it. > > > > > > > > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Thu May 19 12:04:32 2011 From: bja...@ (Benoit Jacob) Date: Thu, 19 May 2011 12:04:32 -0700 (PDT) Subject: [Public WebGL] How to check for WebGL support In-Reply-To: Message-ID: <1839080360.165737.1305831871958.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> In this respect, the only thing I'm really concerned about is the apps that want to fall back to Canvas 2D if WebGL is not available (Angry Birds, Three.js, etc). If doing 2D with a software OpenGL renderer is going to be slower than using Canvas2D (because, say, Canvas2D implements more stuff in C++) then it's legitimate to want to know and prefer Canvas 2D. Benoit ----- Original Message ----- So I know suspect some browsers are planning to fallback to software rendering if a user's card is blacklisted. In that case you'll almost never fail and isWebGLAvailable will be useless. I'm sure some will be upset that software rendering is slow and they'd like to know if they are going to get software rendering beforehand but in reality lots of GPUs are slow, some are even slower than a good software renderer so knowing that you have hardware or software is not going to help you know if your app will run reasonably. The only way to know is to try it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Thu May 19 12:10:12 2011 From: tpa...@ (Tony Parisi) Date: Thu, 19 May 2011 12:10:12 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: <1839080360.165737.1305831871958.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1839080360.165737.1305831871958.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: thank you, that's the kind of thing I am thinking about. On Thu, May 19, 2011 at 12:04 PM, Benoit Jacob wrote: > In this respect, the only thing I'm really concerned about is the apps that > want to fall back to Canvas 2D if WebGL is not available (Angry Birds, > Three.js, etc). > > If doing 2D with a software OpenGL renderer is going to be slower than > using Canvas2D (because, say, Canvas2D implements more stuff in C++) then > it's legitimate to want to know and prefer Canvas 2D. > > Benoit > > ------------------------------ > > So I know suspect some browsers are planning to fallback to software > rendering if a user's card is blacklisted. > In that case you'll almost never fail and isWebGLAvailable will be useless. > > I'm sure some will be upset that software rendering is slow and they'd like > to know if they are going > to get software rendering beforehand but in reality lots of GPUs are slow, > some are even slower than > a good software renderer so knowing that you have hardware or software is > not going to help you know > if your app will run reasonably. > > The only way to know is to try it. > > > > > > > > > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu May 19 12:21:25 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Thu, 19 May 2011 12:21:25 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: <1839080360.165737.1305831871958.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <1839080360.165737.1305831871958.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, May 19, 2011 at 12:04 PM, Benoit Jacob wrote: > In this respect, the only thing I'm really concerned about is the apps that > want to fall back to Canvas 2D if WebGL is not available (Angry Birds, > Three.js, etc). > > If doing 2D with a software OpenGL renderer is going to be slower than > using Canvas2D (because, say, Canvas2D implements more stuff in C++) then > it's legitimate to want to know and prefer Canvas 2D. > And the only way to know it is to test it. Just because you are using a GPU doesn't mean WebGL will be faster than Canvas2D. > > Benoit > > ------------------------------ > > So I know suspect some browsers are planning to fallback to software > rendering if a user's card is blacklisted. > In that case you'll almost never fail and isWebGLAvailable will be useless. > > I'm sure some will be upset that software rendering is slow and they'd like > to know if they are going > to get software rendering beforehand but in reality lots of GPUs are slow, > some are even slower than > a good software renderer so knowing that you have hardware or software is > not going to help you know > if your app will run reasonably. > > The only way to know is to try it. > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Thu May 19 14:39:52 2011 From: cma...@ (Chris Marrin) Date: Thu, 19 May 2011 14:39:52 -0700 Subject: [Public WebGL] How to check for WebGL support In-Reply-To: References: <1839080360.165737.1305831871958.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: <90EEC349-12DD-4F52-BD64-FD6AE6052B09@apple.com> On May 19, 2011, at 12:21 PM, Gregg Tavares (wrk) wrote: > > > On Thu, May 19, 2011 at 12:04 PM, Benoit Jacob wrote: > In this respect, the only thing I'm really concerned about is the apps that want to fall back to Canvas 2D if WebGL is not available (Angry Birds, Three.js, etc). > > If doing 2D with a software OpenGL renderer is going to be slower than using Canvas2D (because, say, Canvas2D implements more stuff in C++) then it's legitimate to want to know and prefer Canvas 2D. > > And the only way to know it is to test it. Just because you are using a GPU doesn't mean WebGL will be faster than Canvas2D. And even "am I using a GPU" isn't a question with a definitive answer. Some cards do vertex shaders in software and fragment shaders in hardware. Some "GPU hardware" can be slower than some operations done in software. Some cards use software to render to off-screen buffers and hardware when rendering to the screen. I agree with Gregg that you just have to test if you care. Fortunately it's easy to do that testing with WebGL. You can create a context and not have it displayed anywhere and throw a bunch of WebGL calls at it. I have no doubt this functionality will be in a library someday soon. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From exc...@ Fri May 20 07:26:32 2011 From: exc...@ (Philip Taylor) Date: Fri, 20 May 2011 15:26:32 +0100 Subject: [Public WebGL] Vetex shader texture lookups In-Reply-To: <36d7faf3b331d31b99b86f16e1611821.squirrel@webmail.sjbaker.org> References: <1471770685.120866.1305558276424.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4DD144A1.709@hicorp.co.jp> <36d7faf3b331d31b99b86f16e1611821.squirrel@webmail.sjbaker.org> Message-ID: On Mon, May 16, 2011 at 5:50 PM, wrote: > Yeah - to be 100% clear on this: ?There is hardware out there that is > supported by WebGL but which does not support vertex texture lookups. > > So even after this is fixed in ANGLE and the fixes are on everyone's > computers, you STILL cannot 100% rely on there being vertex texture > support. ?The key here being that the specification requires you to query > the number of vertex textures available - and the response to that is > allowed to be zero - and it most certainly IS zero on a couple of older > computers that I own. In case it's relevant for this kind of issue, http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS_ARB has some recent data about the values reported by devices/drivers that have GL_ARB_vertex_shader. (I set up that site as part of a GL-based game, so there's no data about DirectX capabilities which I presume are what matter for ANGLE, but hopefully it gives some indication.) -- Philip Taylor excors...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Fri May 20 18:50:33 2011 From: kbr...@ (Kenneth Russell) Date: Fri, 20 May 2011 18:50:33 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification Message-ID: In the bufferData and bufferSubData variants taking ArrayBufferView, we failed to specify what happens if a Float64Array is passed. http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that Float64Array can not be used with WebGL, but does not specify what happens if an attempt is made. The other entry points which take ArrayBufferView (readPixels, texImage2D, texSubImage2D) also take a type enum, and generate INVALID_OPERATION if that type enum and the type of the ArrayBufferView do not match. Therefore, these entry points will already generate INVALID_OPERATION in this case. Options seem to be: 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. 2. Change the IDL in the WebGL spec to explicitly enumerate all of the ArrayBufferView subclasses accepted for bufferData, bufferSubData, readPixels, texImage2D, and texSubImage2D. Firefox 4 currently has a bug where it silently accepts Float64Arrays for bufferData, so some change is definitely needed. I would probably recommend (2) despite the slight explosion in the IDL because it's most compatible with the intent of the spec. This would mean that an exception would be raised per the Web IDL spec. -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 gma...@ Fri May 20 20:17:22 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 20 May 2011 20:17:22 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: Why does it matter? in real GL, bufferData and bufferSubData just take void* and a length so it seems like any ArrayBufferView should be valid. I can do this now gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); // upload bytes, gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) // use as floats or visa versa gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); // upload floats, gl.vertexAttribPointer(0, 3, gl.BYTE, ...) // use as bytes so why does it matter that I can upload a Float64Array? What I upload and how I used it are not related in WebGL On Fri, May 20, 2011 at 6:50 PM, Kenneth Russell wrote: > > In the bufferData and bufferSubData variants taking ArrayBufferView, > we failed to specify what happens if a Float64Array is passed. > http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that > Float64Array can not be used with WebGL, but does not specify what > happens if an attempt is made. > > The other entry points which take ArrayBufferView (readPixels, > texImage2D, texSubImage2D) also take a type enum, and generate > INVALID_OPERATION if that type enum and the type of the > ArrayBufferView do not match. Therefore, these entry points will > already generate INVALID_OPERATION in this case. > > Options seem to be: > > 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. > 2. Change the IDL in the WebGL spec to explicitly enumerate all of > the ArrayBufferView subclasses accepted for bufferData, bufferSubData, > readPixels, texImage2D, and texSubImage2D. > > Firefox 4 currently has a bug where it silently accepts Float64Arrays > for bufferData, so some change is definitely needed. > > I would probably recommend (2) despite the slight explosion in the IDL > because it's most compatible with the intent of the spec. This would > mean that an exception would be raised per the Web IDL spec. > > -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Sat May 21 00:16:37 2011 From: kbr...@ (Kenneth Russell) Date: Sat, 21 May 2011 00:16:37 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) wrote: > Why does it matter? > in real GL, bufferData and bufferSubData just take void* and a length so it > seems like any ArrayBufferView should be valid. > I can do this now > gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); ? // upload bytes, > gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) ? // use as floats > or visa versa > gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); ? // upload floats, > gl.vertexAttribPointer(0, 3, gl.BYTE, ...) ? // use as bytes > so why does it matter that I can upload a Float64Array? What I upload and > how I used it are not related in WebGL Misinterpretation or reinterpretation of uploaded data is irrelevant. OpenGL ES 2.0 does not support double-precision floating point values at all and neither does WebGL. Uploading a Float64Array into a buffer object will only result in garbage values that can not be properly referenced as vertex attributes. >From the standpoint of strongly typing the IDL, only the ArrayBufferView subclasses that can legally be used in the API should be accepted. If a future version of WebGL begins to accept double-precision floating-point values, then the IDL could either be changed to add overloads taking Float64Array, or could be changed back to what it is now, taking the superclass ArrayBufferView. -Ken > On Fri, May 20, 2011 at 6:50 PM, Kenneth Russell wrote: >> >> In the bufferData and bufferSubData variants taking ArrayBufferView, >> we failed to specify what happens if a Float64Array is passed. >> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that >> Float64Array can not be used with WebGL, but does not specify what >> happens if an attempt is made. >> >> The other entry points which take ArrayBufferView (readPixels, >> texImage2D, texSubImage2D) also take a type enum, and generate >> INVALID_OPERATION if that type enum and the type of the >> ArrayBufferView do not match. Therefore, these entry points will >> already generate INVALID_OPERATION in this case. >> >> Options seem to be: >> >> ?1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. >> ?2. Change the IDL in the WebGL spec to explicitly enumerate all of >> the ArrayBufferView subclasses accepted for bufferData, bufferSubData, >> readPixels, texImage2D, and texSubImage2D. >> >> Firefox 4 currently has a bug where it silently accepts Float64Arrays >> for bufferData, so some change is definitely needed. >> >> I would probably recommend (2) despite the slight explosion in the IDL >> because it's most compatible with the intent of the spec. This would >> mean that an exception would be raised per the Web IDL spec. >> >> -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 >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- 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 cvi...@ Sat May 21 00:31:32 2011 From: cvi...@ (Cedric Vivier) Date: Sat, 21 May 2011 14:31:32 +0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Sat, May 21, 2011 at 14:16, Kenneth Russell wrote: > From the standpoint of strongly typing the IDL, only the > ArrayBufferView subclasses that can legally be used in the API should > be accepted. If a future version of WebGL begins to accept > double-precision floating-point values, then the IDL could either be > changed to add overloads taking Float64Array, or could be changed back > to what it is now, taking the superclass ArrayBufferView. > How about rather specifying that an INVALID_OPERATION is generated when passing a Float64Array ? We already do that kind of check with texImage2D if the ArrayBufferView type does not correspond with the format. This would keep the IDL lighter and allow extensions to use Float64 buffers with the same API instead of having to declare their own. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gle...@ Sat May 21 01:25:31 2011 From: gle...@ (Glenn Maynard) Date: Sat, 21 May 2011 04:25:31 -0400 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Sat, May 21, 2011 at 3:31 AM, Cedric Vivier wrote: > How about rather specifying that an INVALID_OPERATION is generated > when passing a Float64Array ? > > We already do that kind of check with texImage2D if the > ArrayBufferView type does not correspond with the format. > This would keep the IDL lighter and allow extensions to use Float64 > buffers with the same API instead of having to declare their own. That's consistent with how texture format extensions work, too: OES_texture_float doesn't expose new entry points, it just causes existing ones to no longer fail for certain argument types. Doing it at the IDL level isn't compatible with texImage2D's complex constraints, either ("buffer type must match the specified type"). bufferData doesn't have this problem, but only doing it there doesn't seem worth the inconsistency... -- Glenn Maynard ----------------------------------------------------------- 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 Mit...@ Sat May 21 08:36:55 2011 From: Mit...@ (Mitch Williams) Date: Sat, 21 May 2011 08:36:55 -0700 Subject: [Public WebGL] WebGL 3D demos In-Reply-To: References: Message-ID: <38B385985AB34D7A9FCE39284726BCA3@MitchWilliamPC> Greetings, I'm just getting into some OpenGL ES 3d smart phone development and looking at HTML 5 as well. I have a potential client and pushing toward HTML 5 as a potential solution. Is there a gallery online that demo's HTML5 for 3D? Thanks, Mitch Williams 3D-Online http://www.3D-Online.com Mitch.Williams...@ 310-406-1169 ----------------------------------------------------------- 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 gma...@ Sat May 21 11:14:52 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Sat, 21 May 2011 11:14:52 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: > On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) > wrote: > > Why does it matter? > > in real GL, bufferData and bufferSubData just take void* and a length so > it > > seems like any ArrayBufferView should be valid. > > I can do this now > > gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); // upload bytes, > > gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) // use as floats > > or visa versa > > gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); // upload > floats, > > gl.vertexAttribPointer(0, 3, gl.BYTE, ...) // use as bytes > > so why does it matter that I can upload a Float64Array? What I upload and > > how I used it are not related in WebGL > > Misinterpretation or reinterpretation of uploaded data is irrelevant. > OpenGL ES 2.0 does not support double-precision floating point values > at all and neither does WebGL. Uploading a Float64Array into a buffer > object will only result in garbage values that can not be properly > referenced as vertex attributes. > > From the standpoint of strongly typing the IDL, only the > ArrayBufferView subclasses that can legally be used in the API should > be accepted. If a future version of WebGL begins to accept > double-precision floating-point values, then the IDL could either be > changed to add overloads taking Float64Array, or could be changed back > to what it is now, taking the superclass ArrayBufferView. > I don't agree. bufferData doesn't have a type like texImage2D so you can't validate that they are passing in valid data. It's not worth complicating the IDL or even checking for this case IMO. I can download float32 data and do this var bogusView = new Float64Array(someFloat32Array); gl.bufferData(gl.ARRAY_BUFFER, bogusView); // Shouldn't matter. I'm still uploading Float32 data. Why does it matter? Changing this will not add even 1 bit of safety. In fact as it is now you can upload an ArrayBuffer, untyped. There is zero need to check for Float64Array since the API can't validate any of the other cases. There is no reason to complicate it now for one out of million cases. > > -Ken > > > On Fri, May 20, 2011 at 6:50 PM, Kenneth Russell wrote: > >> > >> In the bufferData and bufferSubData variants taking ArrayBufferView, > >> we failed to specify what happens if a Float64Array is passed. > >> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that > >> Float64Array can not be used with WebGL, but does not specify what > >> happens if an attempt is made. > >> > >> The other entry points which take ArrayBufferView (readPixels, > >> texImage2D, texSubImage2D) also take a type enum, and generate > >> INVALID_OPERATION if that type enum and the type of the > >> ArrayBufferView do not match. Therefore, these entry points will > >> already generate INVALID_OPERATION in this case. > >> > >> Options seem to be: > >> > >> 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. > >> 2. Change the IDL in the WebGL spec to explicitly enumerate all of > >> the ArrayBufferView subclasses accepted for bufferData, bufferSubData, > >> readPixels, texImage2D, and texSubImage2D. > >> > >> Firefox 4 currently has a bug where it silently accepts Float64Arrays > >> for bufferData, so some change is definitely needed. > >> > >> I would probably recommend (2) despite the slight explosion in the IDL > >> because it's most compatible with the intent of the spec. This would > >> mean that an exception would be raised per the Web IDL spec. > >> > >> -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 > >> ----------------------------------------------------------- > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon May 23 11:23:46 2011 From: cma...@ (Chris Marrin) Date: Mon, 23 May 2011 11:23:46 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> On May 20, 2011, at 6:50 PM, Kenneth Russell wrote: > > In the bufferData and bufferSubData variants taking ArrayBufferView, > we failed to specify what happens if a Float64Array is passed. > http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that > Float64Array can not be used with WebGL, but does not specify what > happens if an attempt is made. > > The other entry points which take ArrayBufferView (readPixels, > texImage2D, texSubImage2D) also take a type enum, and generate > INVALID_OPERATION if that type enum and the type of the > ArrayBufferView do not match. Therefore, these entry points will > already generate INVALID_OPERATION in this case. > > Options seem to be: > > 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. > 2. Change the IDL in the WebGL spec to explicitly enumerate all of > the ArrayBufferView subclasses accepted for bufferData, bufferSubData, > readPixels, texImage2D, and texSubImage2D. > > Firefox 4 currently has a bug where it silently accepts Float64Arrays > for bufferData, so some change is definitely needed. > > I would probably recommend (2) despite the slight explosion in the IDL > because it's most compatible with the intent of the spec. This would > mean that an exception would be raised per the Web IDL spec. Enumerating types wouldn't prevent errors in all cases. If you pass an ArrayBuffer that happens to contain Float64 data, either in its entirety or interleaved with other types of data, there would be no way to detect the error. There's also no way to detect the error when you pass a Float32 array and you should have passed in an Int32 array. There are cases where it might be perfectly valid to pass a Float64Array to bufferData. The author might be storing 64 bit floats interleaved with other data types. With proper offsets the 64 bit floats would be ignored by the WebGL drawing commands. The author might be passing the data as a Float64Array because the first data value happens to be a 64 bit float and passing it makes the offsets come out right. I'm not saying that's the best way to manage your WebGL buffers, but it is a reasonable thing to do. I don't think we can or should put any restrictions the types passed to bufferData. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon May 23 11:28:24 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 23 May 2011 11:28:24 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Sat, May 21, 2011 at 12:31 AM, Cedric Vivier wrote: > On Sat, May 21, 2011 at 14:16, Kenneth Russell wrote: >> From the standpoint of strongly typing the IDL, only the >> ArrayBufferView subclasses that can legally be used in the API should >> be accepted. If a future version of WebGL begins to accept >> double-precision floating-point values, then the IDL could either be >> changed to add overloads taking Float64Array, or could be changed back >> to what it is now, taking the superclass ArrayBufferView. >> > > How about rather specifying that an INVALID_OPERATION is generated > when passing a Float64Array ? > > We already do that kind of check with texImage2D if the > ArrayBufferView type does not correspond with the format. > This would keep the IDL lighter and allow extensions to use Float64 > buffers with the same API instead of having to declare their own. That's definitely an option -- see the first message in this thread. All things considered it may be the best one -- although I think it should be an INVALID_VALUE error, because under the current API constraints, a value of type Float64Array is never valid (as opposed to occasionally valid, depending on context state). -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 kbr...@ Mon May 23 11:33:57 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 23 May 2011 11:33:57 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: > > > On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >> >> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >> wrote: >> > Why does it matter? >> > in real GL, bufferData and bufferSubData just take void* and a length so >> > it >> > seems like any ArrayBufferView should be valid. >> > I can do this now >> > gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); ? // upload bytes, >> > gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) ? // use as floats >> > or visa versa >> > gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); ? // upload >> > floats, >> > gl.vertexAttribPointer(0, 3, gl.BYTE, ...) ? // use as bytes >> > so why does it matter that I can upload a Float64Array? What I upload >> > and >> > how I used it are not related in WebGL >> >> Misinterpretation or reinterpretation of uploaded data is irrelevant. >> OpenGL ES 2.0 does not support double-precision floating point values >> at all and neither does WebGL. Uploading a Float64Array into a buffer >> object will only result in garbage values that can not be properly >> referenced as vertex attributes. >> >> From the standpoint of strongly typing the IDL, only the >> ArrayBufferView subclasses that can legally be used in the API should >> be accepted. If a future version of WebGL begins to accept >> double-precision floating-point values, then the IDL could either be >> changed to add overloads taking Float64Array, or could be changed back >> to what it is now, taking the superclass ArrayBufferView. > > I don't agree. bufferData doesn't have a type like texImage2D so you can't > validate that they are passing in valid data. It's not worth complicating > the IDL or even checking for this case IMO. > I can download float32 data and do this > var bogusView = new Float64Array(someFloat32Array); > gl.bufferData(gl.ARRAY_BUFFER, bogusView); ?// Shouldn't matter. I'm still > uploading Float32 data. > Why does it matter? Changing this will not add even 1 bit of safety. In fact > as it is now you can upload an ArrayBuffer, untyped. There is zero need to > check for Float64Array since the API can't validate any of the other cases. > There is no reason to complicate it now for one out of million cases. Supporting uploading of Float64Arrays with no error reporting at all gives the incorrect impression that such data can somehow be validly referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a minimum I think that an OpenGL error should be raised if one is passed to bufferData or bufferSubData. -Ken >> >> -Ken >> >> > On Fri, May 20, 2011 at 6:50 PM, Kenneth Russell wrote: >> >> >> >> In the bufferData and bufferSubData variants taking ArrayBufferView, >> >> we failed to specify what happens if a Float64Array is passed. >> >> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that >> >> Float64Array can not be used with WebGL, but does not specify what >> >> happens if an attempt is made. >> >> >> >> The other entry points which take ArrayBufferView (readPixels, >> >> texImage2D, texSubImage2D) also take a type enum, and generate >> >> INVALID_OPERATION if that type enum and the type of the >> >> ArrayBufferView do not match. Therefore, these entry points will >> >> already generate INVALID_OPERATION in this case. >> >> >> >> Options seem to be: >> >> >> >> ?1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. >> >> ?2. Change the IDL in the WebGL spec to explicitly enumerate all of >> >> the ArrayBufferView subclasses accepted for bufferData, bufferSubData, >> >> readPixels, texImage2D, and texSubImage2D. >> >> >> >> Firefox 4 currently has a bug where it silently accepts Float64Arrays >> >> for bufferData, so some change is definitely needed. >> >> >> >> I would probably recommend (2) despite the slight explosion in the IDL >> >> because it's most compatible with the intent of the spec. This would >> >> mean that an exception would be raised per the Web IDL spec. >> >> >> >> -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 >> >> ----------------------------------------------------------- >> >> >> > >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon May 23 11:46:33 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 23 May 2011 11:46:33 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: On Mon, May 23, 2011 at 11:23 AM, Chris Marrin wrote: > > On May 20, 2011, at 6:50 PM, Kenneth Russell wrote: > >> >> In the bufferData and bufferSubData variants taking ArrayBufferView, >> we failed to specify what happens if a Float64Array is passed. >> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that >> Float64Array can not be used with WebGL, but does not specify what >> happens if an attempt is made. >> >> The other entry points which take ArrayBufferView (readPixels, >> texImage2D, texSubImage2D) also take a type enum, and generate >> INVALID_OPERATION if that type enum and the type of the >> ArrayBufferView do not match. Therefore, these entry points will >> already generate INVALID_OPERATION in this case. >> >> Options seem to be: >> >> 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. >> 2. Change the IDL in the WebGL spec to explicitly enumerate all of >> the ArrayBufferView subclasses accepted for bufferData, bufferSubData, >> readPixels, texImage2D, and texSubImage2D. >> >> Firefox 4 currently has a bug where it silently accepts Float64Arrays >> for bufferData, so some change is definitely needed. >> >> I would probably recommend (2) despite the slight explosion in the IDL >> because it's most compatible with the intent of the spec. This would >> mean that an exception would be raised per the Web IDL spec. > > Enumerating types wouldn't prevent errors in all cases. If you pass an ArrayBuffer that happens to contain Float64 data, either in its entirety or interleaved with other types of data, there would be no way to detect the error. There's also no way to detect the error when you pass a Float32 array and you should have passed in an Int32 array. Yes, both of these are true. > There are cases where it might be perfectly valid to pass a Float64Array to bufferData. The author might be storing 64 bit floats interleaved with other data types. ?With proper offsets the 64 bit floats would be ignored by the WebGL drawing commands. The author might be passing the data as a Float64Array because the first data value happens to be a 64 bit float and passing it makes the offsets come out right. I'm not saying that's the best way to manage your WebGL buffers, but it is a reasonable thing to do. This sounds like a pretty esoteric use case. The 64-bit floating point data would only be legally accessible on the CPU due to OpenGL ES 2.0 API restrictions, but the rest of the data would be being uploaded to the GPU. Presumably once the other data is uploaded to the GPU, the CPU side copy should be discarded, but that wouldn't be possible because of the data interleaving. This would result in two times the space being consumed, part on the GPU and part on the CPU, than otherwise should be. > I don't think we can or should put any restrictions the types passed to bufferData. I think that at least some error check should be done here since it's very unlikely that a developer would intentionally try to upload a Float64Array. Generating an INVALID_VALUE OpenGL error would be fine but I think that at least some check is needed. -Ken > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cvi...@ Mon May 23 11:46:46 2011 From: cvi...@ (Cedric Vivier) Date: Tue, 24 May 2011 01:46:46 +0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: On Tue, May 24, 2011 at 01:33, Kenneth Russell wrote: > Supporting uploading of Float64Arrays with no error reporting at all > gives the incorrect impression that such data can somehow be validly > referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a > minimum I think that an OpenGL error should be raised if one is passed > to bufferData or bufferSubData. I agree with Ken, as long the IDL is kept flexible as it is now. An INVALID_VALUE would help debug invalid/garbage output a developer would be seeing because of a simple 'typo'. People doing advanced stuff like interleaving with 64-bit floats would still be able to use their buffers, casting to Float32 first (which better expresses the intent [ie. "this ArrayBuffer is interleaved with 64-bit floats but I want to use 32-bit floats with this GL buffer"]). Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Mon May 23 12:20:43 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 23 May 2011 12:20:43 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: I don't think we should disallow passing Float64Array to bufferData or bufferSubData Let me put this another way with an example // Get some data (this could be replaced by XHRing the data) // The data is in the format float[3] position, uint8[4] color, double[2] normalUsedInJS var untypedBuffer = new ArrayBuffer(96); var asFloats = new Float32Array(untypedBuffer); var asUint8s = new Uint8Array(untypedBuffer); var asDoubles = new Float64Array(untypedBuffer); // Triangle positions asFloats[0] = 0.0; asFloats[1] = 0.5; asFloats[2] = 0; asFloats[12] = 0.5; asFloats[13] = -0.5; asFloats[14] = 0; asFloats[24] = 0.5; asFloats[25] = -0.05; asFloats[26] = 0; // Colors asUint8s[12] = 255; asUnit8s[13] = 0; asUnit8s[14] = 0; asUnit8s[15] = 255; asUint8s[44] = 255; asUnit8s[45] = 0; asUnit8s[46] = 0; asUnit8s[47] = 255; asUint8s[76] = 255; asUnit8s[77] = 0; asUnit8s[78] = 0; asUnit8s[79] = 255; // other data, to be used by JavaScript asDoubles[3] = Math.sin(0); asDoubles[4] = Math.cos(0); asDoubles[7] = Math.sin(Math.PI * 2 / 3); asDoubles[8] = Math.cos(Math.PI * 2 / 3); asDoubles[11] = Math.sin(-Math.PI * 2 / 3); asDoubles[12] = Math.cos(-Math.PI * 2 / 3); Would might not do this directly in JS but I would XHR that data it so I had 1 XHR for all my data instead of 2 XHRs and I'd be happy to upload it all to the card to avoid having the split it at runtime. Given that, All of these should work and accomplish the exact same thing gl.bufferData(gl.ARRAY_BUFFER, untypedBuffer, ..); // uploads all 96 bytes of mixed data gl.bufferData(gl.ARRAY_BUFFER, asFloats, ..); // uploads all 96 bytes of mixed data gl.bufferData(gl.ARRAY_BUFFER, asUint8, ..); // uploads all 96 bytes of mixed data gl.bufferData(gl.ARRAY_BUFFER, asDoubles, ..); // uploads all 96 bytes of mixed data Disallowing the last line doesn't give us one iota of type safety so why specifically disallow it? All 4 statements are doing exactly the same thing. Uploading mixed data and lying about the type of data in the buffer. Well, I suppose the first one isn't lying since it's not claiming any type but the other 3 are. If we're serious about type safety we'd track the type used to put data in the buffer and disallow other uses on vertexAttribPointer. We aren't going to do that.The API allows the user to upload any crap they want. Adding one exception out of 9 types of ArrayBufferViews, the other 8 of which do not actually guarantee what's in them is silly. On Mon, May 23, 2011 at 11:46 AM, Kenneth Russell wrote: > > On Mon, May 23, 2011 at 11:23 AM, Chris Marrin wrote: > > > > On May 20, 2011, at 6:50 PM, Kenneth Russell wrote: > > > >> > >> In the bufferData and bufferSubData variants taking ArrayBufferView, > >> we failed to specify what happens if a Float64Array is passed. > >> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that > >> Float64Array can not be used with WebGL, but does not specify what > >> happens if an attempt is made. > >> > >> The other entry points which take ArrayBufferView (readPixels, > >> texImage2D, texSubImage2D) also take a type enum, and generate > >> INVALID_OPERATION if that type enum and the type of the > >> ArrayBufferView do not match. Therefore, these entry points will > >> already generate INVALID_OPERATION in this case. > >> > >> Options seem to be: > >> > >> 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. > >> 2. Change the IDL in the WebGL spec to explicitly enumerate all of > >> the ArrayBufferView subclasses accepted for bufferData, bufferSubData, > >> readPixels, texImage2D, and texSubImage2D. > >> > >> Firefox 4 currently has a bug where it silently accepts Float64Arrays > >> for bufferData, so some change is definitely needed. > >> > >> I would probably recommend (2) despite the slight explosion in the IDL > >> because it's most compatible with the intent of the spec. This would > >> mean that an exception would be raised per the Web IDL spec. > > > > Enumerating types wouldn't prevent errors in all cases. If you pass an > ArrayBuffer that happens to contain Float64 data, either in its entirety or > interleaved with other types of data, there would be no way to detect the > error. There's also no way to detect the error when you pass a Float32 array > and you should have passed in an Int32 array. > > Yes, both of these are true. > > > There are cases where it might be perfectly valid to pass a Float64Array > to bufferData. The author might be storing 64 bit floats interleaved with > other data types. With proper offsets the 64 bit floats would be ignored by > the WebGL drawing commands. The author might be passing the data as a > Float64Array because the first data value happens to be a 64 bit float and > passing it makes the offsets come out right. I'm not saying that's the best > way to manage your WebGL buffers, but it is a reasonable thing to do. > > This sounds like a pretty esoteric use case. The 64-bit floating point > data would only be legally accessible on the CPU due to OpenGL ES 2.0 > API restrictions, but the rest of the data would be being uploaded to > the GPU. Presumably once the other data is uploaded to the GPU, the > CPU side copy should be discarded, but that wouldn't be possible > because of the data interleaving. This would result in two times the > space being consumed, part on the GPU and part on the CPU, than > otherwise should be. > > > I don't think we can or should put any restrictions the types passed to > bufferData. > > I think that at least some error check should be done here since it's > very unlikely that a developer would intentionally try to upload a > Float64Array. Generating an INVALID_VALUE OpenGL error would be fine > but I think that at least some check is needed. > > -Ken > > > ----- > > ~Chris > > cmarrin...@ > > > > > > > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Mon May 23 12:53:26 2011 From: cvi...@ (Cedric Vivier) Date: Tue, 24 May 2011 02:53:26 +0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: On Tue, May 24, 2011 at 02:20, Gregg Tavares (wrk) wrote: > gl.bufferData(gl.ARRAY_BUFFER, asDoubles, ..); ?// uploads all 96 bytes of > mixed data > Disallowing the last line doesn't give us one iota of type safety so why > specifically disallow it? Imho Kenneth's idea is not about type safety, _we can always cast_, this is about having better reporting for simple errors/types by better expressing the intent of the data you send to GL. Consider a much simpler example : readModelInto(float64ArrayThatHasBeenCreatedElsewhere); //this fills the values of any passed TypedArray from another source eg. a JSON array. gl.bufferData(gl.ARRAY_BUFFER, float64ArrayThatHasBeenCreatedElsewhere); This will result in unintended/unexpected results that the developer might have hard time to track down as there is absolutely no warning/error given to something that is semantically wrong. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Mon May 23 13:02:42 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 23 May 2011 13:02:42 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: On Mon, May 23, 2011 at 12:53 PM, Cedric Vivier wrote: > On Tue, May 24, 2011 at 02:20, Gregg Tavares (wrk) > wrote: > > gl.bufferData(gl.ARRAY_BUFFER, asDoubles, ..); // uploads all 96 bytes > of > > mixed data > > Disallowing the last line doesn't give us one iota of type safety so why > > specifically disallow it? > > Imho Kenneth's idea is not about type safety, _we can always cast_, > this is about having better reporting for simple errors/types by > better expressing the intent of the data you send to GL. > > Consider a much simpler example : > > readModelInto(float64ArrayThatHasBeenCreatedElsewhere); //this fills > the values of any passed TypedArray from another source eg. a JSON > array. > gl.bufferData(gl.ARRAY_BUFFER, float64ArrayThatHasBeenCreatedElsewhere); > > > This will result in unintended/unexpected results that the developer > might have hard time to track down as there is absolutely no > warning/error given to something that is semantically wrong. > No it won't. There is no gl.DOUBLE to pass to gl.vertexAttribPointer. Matching the type uploaded to the type used in gl.vertexAttribPointer is always something the developer has to deal with. Most samples that used mixed types upload all their data through a UInt8Array or Float32Array even though their data is not uniformly gl.UNSIGNED_BYTE or gl.FLOAT Disallowing Float64Array will not help the developer in any way and unnecessarily clutters and complicates the spec. > > Regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon May 23 14:24:05 2011 From: cma...@ (Chris Marrin) Date: Mon, 23 May 2011 14:24:05 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: > > On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: >> >> >> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >>> >>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >>> wrote: >>>> Why does it matter? >>>> in real GL, bufferData and bufferSubData just take void* and a length so >>>> it >>>> seems like any ArrayBufferView should be valid. >>>> I can do this now >>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); // upload bytes, >>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) // use as floats >>>> or visa versa >>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); // upload >>>> floats, >>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) // use as bytes >>>> so why does it matter that I can upload a Float64Array? What I upload >>>> and >>>> how I used it are not related in WebGL >>> >>> Misinterpretation or reinterpretation of uploaded data is irrelevant. >>> OpenGL ES 2.0 does not support double-precision floating point values >>> at all and neither does WebGL. Uploading a Float64Array into a buffer >>> object will only result in garbage values that can not be properly >>> referenced as vertex attributes. >>> >>> From the standpoint of strongly typing the IDL, only the >>> ArrayBufferView subclasses that can legally be used in the API should >>> be accepted. If a future version of WebGL begins to accept >>> double-precision floating-point values, then the IDL could either be >>> changed to add overloads taking Float64Array, or could be changed back >>> to what it is now, taking the superclass ArrayBufferView. >> >> I don't agree. bufferData doesn't have a type like texImage2D so you can't >> validate that they are passing in valid data. It's not worth complicating >> the IDL or even checking for this case IMO. >> I can download float32 data and do this >> var bogusView = new Float64Array(someFloat32Array); >> gl.bufferData(gl.ARRAY_BUFFER, bogusView); // Shouldn't matter. I'm still >> uploading Float32 data. >> Why does it matter? Changing this will not add even 1 bit of safety. In fact >> as it is now you can upload an ArrayBuffer, untyped. There is zero need to >> check for Float64Array since the API can't validate any of the other cases. >> There is no reason to complicate it now for one out of million cases. > > Supporting uploading of Float64Arrays with no error reporting at all > gives the incorrect impression that such data can somehow be validly > referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a > minimum I think that an OpenGL error should be raised if one is passed > to bufferData or bufferSubData. It can be validly uploaded. To WebGL, it's just a bunch of bytes. The interpretation on the other end is up to the GPU. WebGL doesn't define support for 64 bit floats. But it would be completely reasonable to define some sort of extension that would require its support. So I think it would be a mistake to add logic to disallow it. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Mon May 23 14:27:39 2011 From: cma...@ (Chris Marrin) Date: Mon, 23 May 2011 14:27:39 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: <289C04D8-AF38-441D-A1F6-25C7E841540F@apple.com> On May 23, 2011, at 11:46 AM, Kenneth Russell wrote: > On Mon, May 23, 2011 at 11:23 AM, Chris Marrin wrote: >> >> On May 20, 2011, at 6:50 PM, Kenneth Russell wrote: >> >>> >>> In the bufferData and bufferSubData variants taking ArrayBufferView, >>> we failed to specify what happens if a Float64Array is passed. >>> http://www.khronos.org/registry/webgl/specs/latest/#5.12 mentions that >>> Float64Array can not be used with WebGL, but does not specify what >>> happens if an attempt is made. >>> >>> The other entry points which take ArrayBufferView (readPixels, >>> texImage2D, texSubImage2D) also take a type enum, and generate >>> INVALID_OPERATION if that type enum and the type of the >>> ArrayBufferView do not match. Therefore, these entry points will >>> already generate INVALID_OPERATION in this case. >>> >>> Options seem to be: >>> >>> 1. Generate an INVALID_VALUE OpenGL error if a Float64Array is passed. >>> 2. Change the IDL in the WebGL spec to explicitly enumerate all of >>> the ArrayBufferView subclasses accepted for bufferData, bufferSubData, >>> readPixels, texImage2D, and texSubImage2D. >>> >>> Firefox 4 currently has a bug where it silently accepts Float64Arrays >>> for bufferData, so some change is definitely needed. >>> >>> I would probably recommend (2) despite the slight explosion in the IDL >>> because it's most compatible with the intent of the spec. This would >>> mean that an exception would be raised per the Web IDL spec. >> >> Enumerating types wouldn't prevent errors in all cases. If you pass an ArrayBuffer that happens to contain Float64 data, either in its entirety or interleaved with other types of data, there would be no way to detect the error. There's also no way to detect the error when you pass a Float32 array and you should have passed in an Int32 array. > > Yes, both of these are true. > >> There are cases where it might be perfectly valid to pass a Float64Array to bufferData. The author might be storing 64 bit floats interleaved with other data types. With proper offsets the 64 bit floats would be ignored by the WebGL drawing commands. The author might be passing the data as a Float64Array because the first data value happens to be a 64 bit float and passing it makes the offsets come out right. I'm not saying that's the best way to manage your WebGL buffers, but it is a reasonable thing to do. > > This sounds like a pretty esoteric use case. The 64-bit floating point > data would only be legally accessible on the CPU due to OpenGL ES 2.0 > API restrictions, but the rest of the data would be being uploaded to > the GPU. Presumably once the other data is uploaded to the GPU, the > CPU side copy should be discarded, but that wouldn't be possible > because of the data interleaving. This would result in two times the > space being consumed, part on the GPU and part on the CPU, than > otherwise should be. But doing such a thing would be legal and I see no reason to protect an author from doing it. The amount of data being transferred might be minuscule compared to the convenience of keeping the data together. That's for the author to decide. > > >> I don't think we can or should put any restrictions the types passed to bufferData. > > I think that at least some error check should be done here since it's > very unlikely that a developer would intentionally try to upload a > Float64Array. Generating an INVALID_VALUE OpenGL error would be fine > but I think that at least some check is needed. As I mentioned in my other post, we may have extensions in the near future that require 64 bit float support. I wouldn't want to avoid such error checking when such an extension were enabled. I just don't see why we should prevent this... ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Mon May 23 14:32:51 2011 From: cma...@ (Chris Marrin) Date: Mon, 23 May 2011 14:32:51 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: Message-ID: <275D19BC-4293-4021-8381-9DC07C0269F5@apple.com> On May 23, 2011, at 11:46 AM, Cedric Vivier wrote: > > On Tue, May 24, 2011 at 01:33, Kenneth Russell wrote: >> Supporting uploading of Float64Arrays with no error reporting at all >> gives the incorrect impression that such data can somehow be validly >> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a >> minimum I think that an OpenGL error should be raised if one is passed >> to bufferData or bufferSubData. > > I agree with Ken, as long the IDL is kept flexible as it is now. > An INVALID_VALUE would help debug invalid/garbage output a developer > would be seeing because of a simple 'typo'. I don't think Float64Array vs Float32Array is a simple typo. It is a basic misunderstanding by the author. There are so many other ways an author can make a mistake sending data to the GPU, catching this one isn't going to help much. All we'd be doing would be tying the hands of authors who are being clever. > > People doing advanced stuff like interleaving with 64-bit floats would > still be able to use their buffers, casting to Float32 first (which > better expresses the intent [ie. "this ArrayBuffer is interleaved with > 64-bit floats but I want to use 32-bit floats with this GL buffer"]). There are plenty of workarounds. But why do this check when it would have little or no real value? That is, of course, my opinion. But I don't like the idea of putting in error checking unless there is good evidence that there is a real problem to be addressed. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Mon May 23 14:47:14 2011 From: kbr...@ (Kenneth Russell) Date: Mon, 23 May 2011 14:47:14 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> Message-ID: On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: > > On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: > >> >> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: >>> >>> >>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >>>> >>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >>>> wrote: >>>>> Why does it matter? >>>>> in real GL, bufferData and bufferSubData just take void* and a length so >>>>> it >>>>> seems like any ArrayBufferView should be valid. >>>>> I can do this now >>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); ? // upload bytes, >>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) ? // use as floats >>>>> or visa versa >>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); ? // upload >>>>> floats, >>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) ? // use as bytes >>>>> so why does it matter that I can upload a Float64Array? What I upload >>>>> and >>>>> how I used it are not related in WebGL >>>> >>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. >>>> OpenGL ES 2.0 does not support double-precision floating point values >>>> at all and neither does WebGL. Uploading a Float64Array into a buffer >>>> object will only result in garbage values that can not be properly >>>> referenced as vertex attributes. >>>> >>>> From the standpoint of strongly typing the IDL, only the >>>> ArrayBufferView subclasses that can legally be used in the API should >>>> be accepted. If a future version of WebGL begins to accept >>>> double-precision floating-point values, then the IDL could either be >>>> changed to add overloads taking Float64Array, or could be changed back >>>> to what it is now, taking the superclass ArrayBufferView. >>> >>> I don't agree. bufferData doesn't have a type like texImage2D so you can't >>> validate that they are passing in valid data. It's not worth complicating >>> the IDL or even checking for this case IMO. >>> I can download float32 data and do this >>> var bogusView = new Float64Array(someFloat32Array); >>> gl.bufferData(gl.ARRAY_BUFFER, bogusView); ?// Shouldn't matter. I'm still >>> uploading Float32 data. >>> Why does it matter? Changing this will not add even 1 bit of safety. In fact >>> as it is now you can upload an ArrayBuffer, untyped. There is zero need to >>> check for Float64Array since the API can't validate any of the other cases. >>> There is no reason to complicate it now for one out of million cases. >> >> Supporting uploading of Float64Arrays with no error reporting at all >> gives the incorrect impression that such data can somehow be validly >> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a >> minimum I think that an OpenGL error should be raised if one is passed >> to bufferData or bufferSubData. > > It can be validly uploaded. To WebGL, it's just a bunch of bytes. The interpretation on the other end is up to the GPU. WebGL doesn't define support for 64 bit floats. But it would be completely reasonable to define some sort of extension that would require its support. So I think it would be a mistake to add logic to disallow it. OpenGL ES 2.0 does not support 64-bit floats at all, not even via an extension, and I think it is unlikely that support will be added to mobile hardware within at least several years, if ever. Therefore any WebGL extension adding 64-bit float support would be desktop-only, and so far the working group has shied away from defining such extensions. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Mon May 23 14:56:44 2011 From: ben...@ (Ben Vanik) Date: Mon, 23 May 2011 14:56:44 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> Message-ID: I haven't been keeping up on WebCL, but that may likely have 64-bit float support and want to add it for interop with WebGL. In such a case that they do this (probably via an extension) you'd want symmetry between the APIs for all the buffer sharing scenarios and end up adding a WebGL extension to support DOUBLE. On Mon, May 23, 2011 at 2:47 PM, Kenneth Russell wrote: > > On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: > > > > On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: > > > >> > >> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) > wrote: > >>> > >>> > >>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell > wrote: > >>>> > >>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) > > >>>> wrote: > >>>>> Why does it matter? > >>>>> in real GL, bufferData and bufferSubData just take void* and a length > so > >>>>> it > >>>>> seems like any ArrayBufferView should be valid. > >>>>> I can do this now > >>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); // upload > bytes, > >>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) // use as floats > >>>>> or visa versa > >>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); // upload > >>>>> floats, > >>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) // use as bytes > >>>>> so why does it matter that I can upload a Float64Array? What I upload > >>>>> and > >>>>> how I used it are not related in WebGL > >>>> > >>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. > >>>> OpenGL ES 2.0 does not support double-precision floating point values > >>>> at all and neither does WebGL. Uploading a Float64Array into a buffer > >>>> object will only result in garbage values that can not be properly > >>>> referenced as vertex attributes. > >>>> > >>>> From the standpoint of strongly typing the IDL, only the > >>>> ArrayBufferView subclasses that can legally be used in the API should > >>>> be accepted. If a future version of WebGL begins to accept > >>>> double-precision floating-point values, then the IDL could either be > >>>> changed to add overloads taking Float64Array, or could be changed back > >>>> to what it is now, taking the superclass ArrayBufferView. > >>> > >>> I don't agree. bufferData doesn't have a type like texImage2D so you > can't > >>> validate that they are passing in valid data. It's not worth > complicating > >>> the IDL or even checking for this case IMO. > >>> I can download float32 data and do this > >>> var bogusView = new Float64Array(someFloat32Array); > >>> gl.bufferData(gl.ARRAY_BUFFER, bogusView); // Shouldn't matter. I'm > still > >>> uploading Float32 data. > >>> Why does it matter? Changing this will not add even 1 bit of safety. In > fact > >>> as it is now you can upload an ArrayBuffer, untyped. There is zero need > to > >>> check for Float64Array since the API can't validate any of the other > cases. > >>> There is no reason to complicate it now for one out of million cases. > >> > >> Supporting uploading of Float64Arrays with no error reporting at all > >> gives the incorrect impression that such data can somehow be validly > >> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a > >> minimum I think that an OpenGL error should be raised if one is passed > >> to bufferData or bufferSubData. > > > > It can be validly uploaded. To WebGL, it's just a bunch of bytes. The > interpretation on the other end is up to the GPU. WebGL doesn't define > support for 64 bit floats. But it would be completely reasonable to define > some sort of extension that would require its support. So I think it would > be a mistake to add logic to disallow it. > > OpenGL ES 2.0 does not support 64-bit floats at all, not even via an > extension, and I think it is unlikely that support will be added to > mobile hardware within at least several years, if ever. Therefore any > WebGL extension adding 64-bit float support would be desktop-only, and > so far the working group has shied away from defining such extensions. > > -Ken > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Mon May 23 15:10:28 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 23 May 2011 15:10:28 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> Message-ID: Whether or not WebGL supports Float64 internally is irrelevant. bufferData and bufferSubData do NOT use the type information from the buffer views. Pretending they do by banning one of the views is pointless. On Mon, May 23, 2011 at 2:47 PM, Kenneth Russell wrote: > On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: > > > > On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: > > > >> > >> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) > wrote: > >>> > >>> > >>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell > wrote: > >>>> > >>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) > > >>>> wrote: > >>>>> Why does it matter? > >>>>> in real GL, bufferData and bufferSubData just take void* and a length > so > >>>>> it > >>>>> seems like any ArrayBufferView should be valid. > >>>>> I can do this now > >>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); // upload > bytes, > >>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) // use as floats > >>>>> or visa versa > >>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); // upload > >>>>> floats, > >>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) // use as bytes > >>>>> so why does it matter that I can upload a Float64Array? What I upload > >>>>> and > >>>>> how I used it are not related in WebGL > >>>> > >>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. > >>>> OpenGL ES 2.0 does not support double-precision floating point values > >>>> at all and neither does WebGL. Uploading a Float64Array into a buffer > >>>> object will only result in garbage values that can not be properly > >>>> referenced as vertex attributes. > >>>> > >>>> From the standpoint of strongly typing the IDL, only the > >>>> ArrayBufferView subclasses that can legally be used in the API should > >>>> be accepted. If a future version of WebGL begins to accept > >>>> double-precision floating-point values, then the IDL could either be > >>>> changed to add overloads taking Float64Array, or could be changed back > >>>> to what it is now, taking the superclass ArrayBufferView. > >>> > >>> I don't agree. bufferData doesn't have a type like texImage2D so you > can't > >>> validate that they are passing in valid data. It's not worth > complicating > >>> the IDL or even checking for this case IMO. > >>> I can download float32 data and do this > >>> var bogusView = new Float64Array(someFloat32Array); > >>> gl.bufferData(gl.ARRAY_BUFFER, bogusView); // Shouldn't matter. I'm > still > >>> uploading Float32 data. > >>> Why does it matter? Changing this will not add even 1 bit of safety. In > fact > >>> as it is now you can upload an ArrayBuffer, untyped. There is zero need > to > >>> check for Float64Array since the API can't validate any of the other > cases. > >>> There is no reason to complicate it now for one out of million cases. > >> > >> Supporting uploading of Float64Arrays with no error reporting at all > >> gives the incorrect impression that such data can somehow be validly > >> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a > >> minimum I think that an OpenGL error should be raised if one is passed > >> to bufferData or bufferSubData. > > > > It can be validly uploaded. To WebGL, it's just a bunch of bytes. The > interpretation on the other end is up to the GPU. WebGL doesn't define > support for 64 bit floats. But it would be completely reasonable to define > some sort of extension that would require its support. So I think it would > be a mistake to add logic to disallow it. > > OpenGL ES 2.0 does not support 64-bit floats at all, not even via an > extension, and I think it is unlikely that support will be added to > mobile hardware within at least several years, if ever. Therefore any > WebGL extension adding 64-bit float support would be desktop-only, and > so far the working group has shied away from defining such extensions. > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvi...@ Mon May 23 22:18:12 2011 From: cvi...@ (Cedric Vivier) Date: Tue, 24 May 2011 12:18:12 +0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: On Tue, May 24, 2011 at 03:02, Gregg Tavares (wrk) wrote: >> Consider a much simpler example : >> >> readModelInto(float64ArrayThatHasBeenCreatedElsewhere); //this fills >> the values of any passed TypedArray from another source eg. a JSON >> array. >> gl.bufferData(gl.ARRAY_BUFFER, float64ArrayThatHasBeenCreatedElsewhere); >> >> This will result in unintended/unexpected results that the developer >> might have hard time to track down as there is absolutely no >> warning/error given to something that is semantically wrong. > > No it won't. There is no gl.DOUBLE to pass to gl.vertexAttribPointer. That's the problem, vertexAttribPointer will be set to gl.FLOAT already, the output will be garbage and there won't be any error reported. In conjunction with the fact that all numbers are double-precision 64-bit in Javascript, this not obey the principle of least surprise. > Most samples that used > mixed types upload all their data through a UInt8Array or Float32Array even > though their data is not uniformly gl.UNSIGNED_BYTE or gl.FLOAT Uniformity is not relevant here. If you upload an UInt8Array, you convey the intent that you will likely use at least one attrib of UNSIGNED_BYTE. If you upload an Float32Array, you convey the intent that you will likely use at least one attrib of FLOAT. As you'll never be able to use one attrib of DOUBLE, it breaks this "contract". > Disallowing Float64Array will not help the developer in any way As clarified above, I still think it can help the developer for simple typos/mistakes that would otherwise take some time to figure out. Not feeling strongly about inclusion in the spec though, it could be done out of spec by tools like WebGL Inspector. Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Mon May 23 22:44:45 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Mon, 23 May 2011 22:44:45 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: On Mon, May 23, 2011 at 10:18 PM, Cedric Vivier wrote: > On Tue, May 24, 2011 at 03:02, Gregg Tavares (wrk) > wrote: > >> Consider a much simpler example : > >> > >> readModelInto(float64ArrayThatHasBeenCreatedElsewhere); //this fills > >> the values of any passed TypedArray from another source eg. a JSON > >> array. > >> gl.bufferData(gl.ARRAY_BUFFER, float64ArrayThatHasBeenCreatedElsewhere); > >> > >> This will result in unintended/unexpected results that the developer > >> might have hard time to track down as there is absolutely no > >> warning/error given to something that is semantically wrong. > > > > No it won't. There is no gl.DOUBLE to pass to gl.vertexAttribPointer. > > That's the problem, vertexAttribPointer will be set to gl.FLOAT > already, the output will be garbage and there won't be any error > reported. > And there won't be any error reported if you upload Uint8 and use gl.FLOAT in vertexAttribPointer. Nor will there be an error if upload sets of 2 float followed by 4 uint8s and set your size to 3. Nor will there an error if you set your stride to 4. > In conjunction with the fact that all numbers are double-precision > 64-bit in Javascript, this not obey the principle of least surprise. > > > > Most samples that used > > mixed types upload all their data through a UInt8Array or Float32Array > even > > though their data is not uniformly gl.UNSIGNED_BYTE or gl.FLOAT > > Uniformity is not relevant here. > If you upload an UInt8Array, you convey the intent that you will > likely use at least one attrib of UNSIGNED_BYTE. > If you upload an Float32Array, you convey the intent that you will > likely use at least one attrib of FLOAT. > > As you'll never be able to use one attrib of DOUBLE, it breaks this > "contract". > There is no such contract. > > > > Disallowing Float64Array will not help the developer in any way > > As clarified above, I still think it can help the developer for simple > typos/mistakes that would otherwise take some time to figure out. > > Not feeling strongly about inclusion in the spec though, it could be > done out of spec by tools like WebGL Inspector. > > Regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom...@ Tue May 24 05:09:25 2011 From: tom...@ (tom...@) Date: Tue, 24 May 2011 12:09:25 +0000 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> Message-ID: <8F9C33DBA4D7C645A1E833BDDDD2CFB304C948@008-AM1MPN1-013.mgdnok.nokia.com> The ARM Mali-T604 does in fact support double-precision floating point: http://blogs.arm.com/multimedia/355-arm-mali-t604-gpu-ready-for-post-32-bit-world-and-real-computing/ It's true that there is no OpenGL ES 2.0 extension for 64-bit floats as of yet, but it won't take long to write one when the time is right. Best regards, Tomi -----Original Message----- From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of ext Kenneth Russell Sent: 24. toukokuuta 2011 0:47 To: Chris Marrin Cc: Gregg Tavares (wrk); public webgl Subject: Re: [Public WebGL] Oversight in bufferData and bufferSubData specification On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: > > On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: > >> >> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: >>> >>> >>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >>>> >>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >>>> >>>> wrote: >>>>> Why does it matter? >>>>> in real GL, bufferData and bufferSubData just take void* and a >>>>> length so it seems like any ArrayBufferView should be valid. >>>>> I can do this now >>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); ? // upload >>>>> bytes, gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) ? // use as >>>>> floats or visa versa gl.bufferData(gl.ARRAY_BUFFER, >>>>> someFloat32BufferView); ? // upload floats, >>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) ? // use as bytes so >>>>> why does it matter that I can upload a Float64Array? What I upload >>>>> and how I used it are not related in WebGL >>>> >>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. >>>> OpenGL ES 2.0 does not support double-precision floating point >>>> values at all and neither does WebGL. Uploading a Float64Array into >>>> a buffer object will only result in garbage values that can not be >>>> properly referenced as vertex attributes. >>>> >>>> From the standpoint of strongly typing the IDL, only the >>>> ArrayBufferView subclasses that can legally be used in the API >>>> should be accepted. If a future version of WebGL begins to accept >>>> double-precision floating-point values, then the IDL could either >>>> be changed to add overloads taking Float64Array, or could be >>>> changed back to what it is now, taking the superclass ArrayBufferView. >>> >>> I don't agree. bufferData doesn't have a type like texImage2D so you >>> can't validate that they are passing in valid data. It's not worth >>> complicating the IDL or even checking for this case IMO. >>> I can download float32 data and do this var bogusView = new >>> Float64Array(someFloat32Array); gl.bufferData(gl.ARRAY_BUFFER, >>> bogusView); ?// Shouldn't matter. I'm still uploading Float32 data. >>> Why does it matter? Changing this will not add even 1 bit of safety. >>> In fact as it is now you can upload an ArrayBuffer, untyped. There >>> is zero need to check for Float64Array since the API can't validate any of the other cases. >>> There is no reason to complicate it now for one out of million cases. >> >> Supporting uploading of Float64Arrays with no error reporting at all >> gives the incorrect impression that such data can somehow be validly >> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a >> minimum I think that an OpenGL error should be raised if one is >> passed to bufferData or bufferSubData. > > It can be validly uploaded. To WebGL, it's just a bunch of bytes. The interpretation on the other end is up to the GPU. WebGL doesn't define support for 64 bit floats. But it would be completely reasonable to define some sort of extension that would require its support. So I think it would be a mistake to add logic to disallow it. OpenGL ES 2.0 does not support 64-bit floats at all, not even via an extension, and I think it is unlikely that support will be added to mobile hardware within at least several years, if ever. Therefore any WebGL extension adding 64-bit float support would be desktop-only, and so far the working group has shied away from defining such extensions. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- 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 cma...@ Tue May 24 09:00:29 2011 From: cma...@ (Chris Marrin) Date: Tue, 24 May 2011 09:00:29 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> Message-ID: <4FF2A214-E39C-4714-8667-9ACB6F789E9C@apple.com> On May 23, 2011, at 2:47 PM, Kenneth Russell wrote: > On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: >> >> On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: >> >>> >>> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: >>>> >>>> >>>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >>>>> >>>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >>>>> wrote: >>>>>> Why does it matter? >>>>>> in real GL, bufferData and bufferSubData just take void* and a length so >>>>>> it >>>>>> seems like any ArrayBufferView should be valid. >>>>>> I can do this now >>>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); // upload bytes, >>>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) // use as floats >>>>>> or visa versa >>>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); // upload >>>>>> floats, >>>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) // use as bytes >>>>>> so why does it matter that I can upload a Float64Array? What I upload >>>>>> and >>>>>> how I used it are not related in WebGL >>>>> >>>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. >>>>> OpenGL ES 2.0 does not support double-precision floating point values >>>>> at all and neither does WebGL. Uploading a Float64Array into a buffer >>>>> object will only result in garbage values that can not be properly >>>>> referenced as vertex attributes. >>>>> >>>>> From the standpoint of strongly typing the IDL, only the >>>>> ArrayBufferView subclasses that can legally be used in the API should >>>>> be accepted. If a future version of WebGL begins to accept >>>>> double-precision floating-point values, then the IDL could either be >>>>> changed to add overloads taking Float64Array, or could be changed back >>>>> to what it is now, taking the superclass ArrayBufferView. >>>> >>>> I don't agree. bufferData doesn't have a type like texImage2D so you can't >>>> validate that they are passing in valid data. It's not worth complicating >>>> the IDL or even checking for this case IMO. >>>> I can download float32 data and do this >>>> var bogusView = new Float64Array(someFloat32Array); >>>> gl.bufferData(gl.ARRAY_BUFFER, bogusView); // Shouldn't matter. I'm still >>>> uploading Float32 data. >>>> Why does it matter? Changing this will not add even 1 bit of safety. In fact >>>> as it is now you can upload an ArrayBuffer, untyped. There is zero need to >>>> check for Float64Array since the API can't validate any of the other cases. >>>> There is no reason to complicate it now for one out of million cases. >>> >>> Supporting uploading of Float64Arrays with no error reporting at all >>> gives the incorrect impression that such data can somehow be validly >>> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a >>> minimum I think that an OpenGL error should be raised if one is passed >>> to bufferData or bufferSubData. >> >> It can be validly uploaded. To WebGL, it's just a bunch of bytes. The interpretation on the other end is up to the GPU. WebGL doesn't define support for 64 bit floats. But it would be completely reasonable to define some sort of extension that would require its support. So I think it would be a mistake to add logic to disallow it. > > OpenGL ES 2.0 does not support 64-bit floats at all, not even via an > extension, and I think it is unlikely that support will be added to > mobile hardware within at least several years, if ever. Therefore any > WebGL extension adding 64-bit float support would be desktop-only, and > so far the working group has shied away from defining such extensions. We can never know what the future holds. Mobile hardware is advancing at an incredible rate. 16 bit per component frame buffers and textures (which would require a 64 bit value) don't seem out of the question within the next few years. I just think putting in a restriction like this is not worth the future problems it might cause. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Tue May 24 09:03:19 2011 From: cma...@ (Chris Marrin) Date: Tue, 24 May 2011 09:03:19 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: <362CAC1A-E386-4193-A290-088AC3C5AB39@apple.com> On May 23, 2011, at 10:18 PM, Cedric Vivier wrote: > On Tue, May 24, 2011 at 03:02, Gregg Tavares (wrk) wrote: >>> Consider a much simpler example : >>> >>> readModelInto(float64ArrayThatHasBeenCreatedElsewhere); //this fills >>> the values of any passed TypedArray from another source eg. a JSON >>> array. >>> gl.bufferData(gl.ARRAY_BUFFER, float64ArrayThatHasBeenCreatedElsewhere); >>> >>> This will result in unintended/unexpected results that the developer >>> might have hard time to track down as there is absolutely no >>> warning/error given to something that is semantically wrong. >> >> No it won't. There is no gl.DOUBLE to pass to gl.vertexAttribPointer. > > That's the problem, vertexAttribPointer will be set to gl.FLOAT > already, the output will be garbage and there won't be any error > reported. > In conjunction with the fact that all numbers are double-precision > 64-bit in Javascript, this not obey the principle of least surprise. You have to make a very conscious effort to make a Float64Array, so the native size of JS float is not the point. If I pass an Int32Array and set the type to gl.FLOAT that's an error that will not be reported. This is an issue developers have to be careful about no matter how we treat Float64Array. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Tue May 24 09:08:42 2011 From: cma...@ (Chris Marrin) Date: Tue, 24 May 2011 09:08:42 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <067E2642-944E-41BF-83D0-1FC1790DF893@apple.com> Message-ID: On May 23, 2011, at 10:18 PM, Cedric Vivier wrote: > > ...Uniformity is not relevant here. > If you upload an UInt8Array, you convey the intent that you will > likely use at least one attrib of UNSIGNED_BYTE. > If you upload an Float32Array, you convey the intent that you will > likely use at least one attrib of FLOAT. > > As you'll never be able to use one attrib of DOUBLE, it breaks this "contract". If I were using an interleaved buffer I would use ArrayBuffer to avoid the confusion of passing a buffer of a particular type that actually contains other types. So I haven't signed any contract in that case. The only contract you make when using bufferData() is that you promise that the type(s) of data in the buffer will match your use of them in the GPU. It's one of the areas a WebGL developer has to use care. Unless we make a complete system of always guaranteeing type match between bufferData and the use of the data, which we discussed and deemed too cumbersome, we can't really protect the author in any meaningful way. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue May 24 10:24:14 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 24 May 2011 10:24:14 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: <4FF2A214-E39C-4714-8667-9ACB6F789E9C@apple.com> References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> <4FF2A214-E39C-4714-8667-9ACB6F789E9C@apple.com> Message-ID: On Tue, May 24, 2011 at 9:00 AM, Chris Marrin wrote: > > On May 23, 2011, at 2:47 PM, Kenneth Russell wrote: > >> On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: >>> >>> On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: >>> >>>> >>>> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: >>>>> >>>>> >>>>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >>>>>> >>>>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >>>>>> wrote: >>>>>>> Why does it matter? >>>>>>> in real GL, bufferData and bufferSubData just take void* and a length so >>>>>>> it >>>>>>> seems like any ArrayBufferView should be valid. >>>>>>> I can do this now >>>>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); ? // upload bytes, >>>>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) ? // use as floats >>>>>>> or visa versa >>>>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); ? // upload >>>>>>> floats, >>>>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) ? // use as bytes >>>>>>> so why does it matter that I can upload a Float64Array? What I upload >>>>>>> and >>>>>>> how I used it are not related in WebGL >>>>>> >>>>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. >>>>>> OpenGL ES 2.0 does not support double-precision floating point values >>>>>> at all and neither does WebGL. Uploading a Float64Array into a buffer >>>>>> object will only result in garbage values that can not be properly >>>>>> referenced as vertex attributes. >>>>>> >>>>>> From the standpoint of strongly typing the IDL, only the >>>>>> ArrayBufferView subclasses that can legally be used in the API should >>>>>> be accepted. If a future version of WebGL begins to accept >>>>>> double-precision floating-point values, then the IDL could either be >>>>>> changed to add overloads taking Float64Array, or could be changed back >>>>>> to what it is now, taking the superclass ArrayBufferView. >>>>> >>>>> I don't agree. bufferData doesn't have a type like texImage2D so you can't >>>>> validate that they are passing in valid data. It's not worth complicating >>>>> the IDL or even checking for this case IMO. >>>>> I can download float32 data and do this >>>>> var bogusView = new Float64Array(someFloat32Array); >>>>> gl.bufferData(gl.ARRAY_BUFFER, bogusView); ?// Shouldn't matter. I'm still >>>>> uploading Float32 data. >>>>> Why does it matter? Changing this will not add even 1 bit of safety. In fact >>>>> as it is now you can upload an ArrayBuffer, untyped. There is zero need to >>>>> check for Float64Array since the API can't validate any of the other cases. >>>>> There is no reason to complicate it now for one out of million cases. >>>> >>>> Supporting uploading of Float64Arrays with no error reporting at all >>>> gives the incorrect impression that such data can somehow be validly >>>> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a >>>> minimum I think that an OpenGL error should be raised if one is passed >>>> to bufferData or bufferSubData. >>> >>> It can be validly uploaded. To WebGL, it's just a bunch of bytes. The interpretation on the other end is up to the GPU. WebGL doesn't define support for 64 bit floats. But it would be completely reasonable to define some sort of extension that would require its support. So I think it would be a mistake to add logic to disallow it. >> >> OpenGL ES 2.0 does not support 64-bit floats at all, not even via an >> extension, and I think it is unlikely that support will be added to >> mobile hardware within at least several years, if ever. Therefore any >> WebGL extension adding 64-bit float support would be desktop-only, and >> so far the working group has shied away from defining such extensions. > > We can never know what the future holds. Mobile hardware is advancing at an incredible rate. 16 bit per component frame buffers and textures (which would require a 64 bit value) don't seem out of the question within the next few years. > > I just think putting in a restriction like this is not worth the future problems it might cause. I withdraw my suggestion to restrict passing of Float64Array to bufferData and bufferSubData. -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 kbr...@ Tue May 24 11:00:25 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 24 May 2011 11:00:25 -0700 Subject: [Public WebGL] Oversight in bufferData and bufferSubData specification In-Reply-To: References: <9B341143-3B67-4603-86D5-51B9E5BC63F6@apple.com> <4FF2A214-E39C-4714-8667-9ACB6F789E9C@apple.com> Message-ID: On Tue, May 24, 2011 at 10:24 AM, Kenneth Russell wrote: > On Tue, May 24, 2011 at 9:00 AM, Chris Marrin wrote: >> >> On May 23, 2011, at 2:47 PM, Kenneth Russell wrote: >> >>> On Mon, May 23, 2011 at 2:24 PM, Chris Marrin wrote: >>>> >>>> On May 23, 2011, at 11:33 AM, Kenneth Russell wrote: >>>> >>>>> >>>>> On Sat, May 21, 2011 at 11:14 AM, Gregg Tavares (wrk) wrote: >>>>>> >>>>>> >>>>>> On Sat, May 21, 2011 at 12:16 AM, Kenneth Russell wrote: >>>>>>> >>>>>>> On Fri, May 20, 2011 at 8:17 PM, Gregg Tavares (wrk) >>>>>>> wrote: >>>>>>>> Why does it matter? >>>>>>>> in real GL, bufferData and bufferSubData just take void* and a length so >>>>>>>> it >>>>>>>> seems like any ArrayBufferView should be valid. >>>>>>>> I can do this now >>>>>>>> gl.bufferData(gl.ARRAY_BUFFER, someUint8BufferView); ? // upload bytes, >>>>>>>> gl.vertexAttribPointer(0, 3, gl.FLOAT, ...) ? // use as floats >>>>>>>> or visa versa >>>>>>>> gl.bufferData(gl.ARRAY_BUFFER, someFloat32BufferView); ? // upload >>>>>>>> floats, >>>>>>>> gl.vertexAttribPointer(0, 3, gl.BYTE, ...) ? // use as bytes >>>>>>>> so why does it matter that I can upload a Float64Array? What I upload >>>>>>>> and >>>>>>>> how I used it are not related in WebGL >>>>>>> >>>>>>> Misinterpretation or reinterpretation of uploaded data is irrelevant. >>>>>>> OpenGL ES 2.0 does not support double-precision floating point values >>>>>>> at all and neither does WebGL. Uploading a Float64Array into a buffer >>>>>>> object will only result in garbage values that can not be properly >>>>>>> referenced as vertex attributes. >>>>>>> >>>>>>> From the standpoint of strongly typing the IDL, only the >>>>>>> ArrayBufferView subclasses that can legally be used in the API should >>>>>>> be accepted. If a future version of WebGL begins to accept >>>>>>> double-precision floating-point values, then the IDL could either be >>>>>>> changed to add overloads taking Float64Array, or could be changed back >>>>>>> to what it is now, taking the superclass ArrayBufferView. >>>>>> >>>>>> I don't agree. bufferData doesn't have a type like texImage2D so you can't >>>>>> validate that they are passing in valid data. It's not worth complicating >>>>>> the IDL or even checking for this case IMO. >>>>>> I can download float32 data and do this >>>>>> var bogusView = new Float64Array(someFloat32Array); >>>>>> gl.bufferData(gl.ARRAY_BUFFER, bogusView); ?// Shouldn't matter. I'm still >>>>>> uploading Float32 data. >>>>>> Why does it matter? Changing this will not add even 1 bit of safety. In fact >>>>>> as it is now you can upload an ArrayBuffer, untyped. There is zero need to >>>>>> check for Float64Array since the API can't validate any of the other cases. >>>>>> There is no reason to complicate it now for one out of million cases. >>>>> >>>>> Supporting uploading of Float64Arrays with no error reporting at all >>>>> gives the incorrect impression that such data can somehow be validly >>>>> referenced on the GPU, which it can't in the OpenGL ES 2.0 API. At a >>>>> minimum I think that an OpenGL error should be raised if one is passed >>>>> to bufferData or bufferSubData. >>>> >>>> It can be validly uploaded. To WebGL, it's just a bunch of bytes. The interpretation on the other end is up to the GPU. WebGL doesn't define support for 64 bit floats. But it would be completely reasonable to define some sort of extension that would require its support. So I think it would be a mistake to add logic to disallow it. >>> >>> OpenGL ES 2.0 does not support 64-bit floats at all, not even via an >>> extension, and I think it is unlikely that support will be added to >>> mobile hardware within at least several years, if ever. Therefore any >>> WebGL extension adding 64-bit float support would be desktop-only, and >>> so far the working group has shied away from defining such extensions. >> >> We can never know what the future holds. Mobile hardware is advancing at an incredible rate. 16 bit per component frame buffers and textures (which would require a 64 bit value) don't seem out of the question within the next few years. >> >> I just think putting in a restriction like this is not worth the future problems it might cause. > > I withdraw my suggestion to restrict passing of Float64Array to > bufferData and bufferSubData. FYI, I've added a note to http://khronos.org/webgl/wiki/WebGL_and_OpenGL_Differences discussing the lack of double-precision floating-point support in WebGL, and removed the sentence from https://www.khronos.org/registry/webgl/specs/latest/#5.12 regarding Float64Array, since none of the WebGL APIs explicitly forbid its use. -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 jam...@ Tue May 24 13:02:47 2011 From: jam...@ (James Donovan) Date: Tue, 24 May 2011 16:02:47 -0400 Subject: [Public WebGL] WebGL 3D demos In-Reply-To: <38B385985AB34D7A9FCE39284726BCA3@MitchWilliamPC> References: <38B385985AB34D7A9FCE39284726BCA3@MitchWilliamPC> Message-ID: Hi, I'm not much of an openGL developer, but Chrome Experiments has some very impressive examples of webGL http://www.chromeexperiments.com/ On Sat, May 21, 2011 at 11:36 AM, Mitch Williams < Mitch.Williams...@> wrote: > > Greetings, > > I'm just getting into some OpenGL ES 3d smart phone development and looking > at HTML 5 as well. > I have a potential client and pushing toward HTML 5 as a potential > solution. > Is there a gallery online that demo's HTML5 for 3D? > > Thanks, > > Mitch Williams > 3D-Online > http://www.3D-Online.com > Mitch.Williams...@ > 310-406-1169 > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue May 24 14:53:39 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 24 May 2011 14:53:39 -0700 Subject: [Public WebGL] Typed Array 1.0 ratified Message-ID: I'm pleased to announce that Version 1.0 of the Typed Array specification was ratified at the Khronos group meeting in Bremen last week. http://www.khronos.org/registry/typedarray/specs/1.0/ has been updated appropriately. Work continues on advancing the specification to address more use cases. -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 mau...@ Tue May 24 17:21:05 2011 From: mau...@ (Jennifer Maurer) Date: Tue, 24 May 2011 17:21:05 -0700 Subject: [Public WebGL] Typed Array 1.0 ratified In-Reply-To: References: Message-ID: Great news! Now that this is ratified, any idea when we might see Data View implementation in Firefox? ~Jennifer On Tue, May 24, 2011 at 2:53 PM, Kenneth Russell wrote: > > I'm pleased to announce that Version 1.0 of the Typed Array > specification was ratified at the Khronos group meeting in Bremen last > week. http://www.khronos.org/registry/typedarray/specs/1.0/ has been > updated appropriately. > > Work continues on advancing the specification to address more use cases. > > -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed May 25 17:50:10 2011 From: kbr...@ (Kenneth Russell) Date: Wed, 25 May 2011 17:50:10 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: On Sat, Apr 23, 2011 at 10:19 AM, Glenn Maynard wrote: > On Fri, Apr 22, 2011 at 9:20 PM, Kenneth Russell wrote: >> >> The Typed Array editors' draft has been updated: >> >> http://www.khronos.org/registry/typedarray/specs/latest/ >> >> with changes supporting the following functionality: >> >> ?- Ability to copy sections of an ArrayBuffer >> ?- Read-only ArrayBuffers >> ?- Support for zero-copy data transfer via postMessage by defining the >> behavior of ArrayBuffers and ArrayBufferViews under structured clone > > This breaks specs that use structured clone within getter operations: > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#history-traversal > > http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#object-store-retrieval-operation > ? http://dev.w3.org/html5/webstorage/#dom-storage-getitem > > For example, it causes "x = localStorage.arrayBuffer" to clear the > arrayBuffer within localStorage as a side-effect of retrieving it, which is > clearly unintended. > > Structured clone is a const operation; making a structured clone of > something doesn't modify it.? You're changing a fundamental property of > structured clone, which isn't a change one spec should be making to another > spec.? (Has Ian Hickson been involved in this discussion?) > > It also effectively changes every setter API that uses structured clone, > changing them into functions that modify their arguments as well. > > It's also generally inconvenient.? For example, if I have an object > describing the current state and I want to stash it in History, I now have > to be very careful to copy off any ArrayBuffers within it before doing so, > and to update any references to those buffers.? I can currently say > "history.pushState(anything, title, url)" without having to care about what > "anything" is and whether it might be modified; please don't break that. Apologies for the delay in replying. I've spoken with Ian and he suggested that a good direction would be to conditionalize whether the structured cloning algorithm auto-closes ArrayBuffers, and to make the Web Messaging spec auto-close them, leaving the other uses of structured cloning unchanged. These changes have been checked in to the typed array spec. Please review and comment. I'll also post a notice to whatwg asking for comment. -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 cma...@ Thu May 26 10:14:03 2011 From: cma...@ (Chris Marrin) Date: Thu, 26 May 2011 10:14:03 -0700 Subject: [Public WebGL] ANGLE and Unsized array declarations Message-ID: <523CE028-B50B-4CFA-92C8-3F00442C5D7E@apple.com> Section 10.17 of the GLSL ES spec: http://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf it talks about disallowing Unsized Array Declarations. I've never seen this discussed as one of the checks done by ANGLE. Does it do the check today? ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Thu May 26 10:19:46 2011 From: cma...@ (Chris Marrin) Date: Thu, 26 May 2011 10:19:46 -0700 Subject: [Public WebGL] ANGLE Dynamic Indexing of Arrays of Samplers Message-ID: <007DEA16-3D04-4E4F-AACB-2C30508D466B@apple.com> I'm adding the following statement to the differences section: The GLSL ES spec [GLES20GLSL] allows but does not mandate support for dynamic indexing of arrays of samplers. WebGL disallows this support. This is in support of tightening the language about array bounds checking. Does ANGLE currently make this check and disallow such indexing? ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bja...@ Thu May 26 10:37:17 2011 From: bja...@ (Benoit Jacob) Date: Thu, 26 May 2011 10:37:17 -0700 (PDT) Subject: [Public WebGL] Some ARB_robustness questions In-Reply-To: Message-ID: <338409528.36683.1306431437195.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> ----- Original Message ----- > On Fri, May 13, 2011 at 6:56 AM, Benoit Jacob > wrote: > > > > Hi, > > > > Is ARB_robustness only an extension for desktop OpenGL, or is there > > an ES version of it? > > Right now it is only for desktop OpenGL. However, EGL already has a > notion of losing the context, currently due to power management > events. If the OpenGL ES / EGL drivers also triggered this when a > given GPU operation took too long, then a WebGL implementation could > build its denial of service defense on top of this mechanism. It would > be better, though, if at least a subset of ARB_robustness were ported > to EGL so that glGetGraphicsResetStatusARB() (which is supposed to be > cheap) would be available. > > > If there is, does anyone know how well supported ARB_robustness is > > on mobile (Android, etc) devices? > > > > What about ANGLE's libGLESv2? Which is how most users get WebGL on > > Windows. Is it possible to implement parts of ARB_robustness on top > > of D3D9? What's the plan? Sorry if I'm missing an obvious reason why > > that's not needed. > > ANGLE exposes the EGL interface, and when Windows resets the GPU, the > D3D9 device lost event is translated into an EGL context lost event. > The WebGL implementation can use this as an indication that an > "unknown" context reset occurred. Unfortunately, building on D3D, it > isn't possible to be more precise and identify guilty vs. innocent > contexts (to the best of my knowledge). > > In Chrome, the current plan is: > > - When ARB_robustness is available: > - If a WebGL context gets a "guilty context reset" status, don't > automatically restore it. Tell the user that WebGL caused the GPU to > reset. Either tell them that the content won't be restored, or ask > them if they want to continue running the content. > - For the innocent context reset status, automatically restore the > context. How do you plan to implement the part where you restore the context and contine running the content? How can you restore all the GL state, including textures/shaders/buffers? Do you keep around a full copy of GL state, including textures? Or do you assume that GL state, including textures, is not corrupted? > - For the unknown reset status, treat it the same as the guilty > context reset status, only tell the user that WebGL *might* have > caused the GPU to reset and ask if they want to continue running the > content. > > - On Windows with ANGLE / EGL: > - If eglMakeCurrent fails and eglGetError returns > EGL_CONTEXT_LOST, treat this the same as an unknown reset status with > ARB_robustness. Is it really needed here to check the error code? Don't you want to do that anyways, when eglMakeCurrent fails? Benoit ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cvi...@ Thu May 26 10:55:12 2011 From: cvi...@ (Cedric Vivier) Date: Fri, 27 May 2011 00:55:12 +0700 Subject: [Public WebGL] Some ARB_robustness questions In-Reply-To: <338409528.36683.1306431437195.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> References: <338409528.36683.1306431437195.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Fri, May 27, 2011 at 00:37, Benoit Jacob wrote: > How do you plan to implement the part where you restore the context and contine running the content? How can you restore all the GL state, including textures/shaders/buffers? Context restoration does not happen automatically unless the application prevented the default behavior (lose the context forever). All state and data needs to be reinitialized by the application : "" Once the context is restored, WebGL resources such as textures and buffers that were created before the context was lost are no longer valid. The application must reinitialize the context's state and recreate all such resources. "" Regards, ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cma...@ Thu May 26 11:18:08 2011 From: cma...@ (Chris Marrin) Date: Thu, 26 May 2011 11:18:08 -0700 Subject: [Public WebGL] Updated WebGL spec with bounds checking info Message-ID: <0180C242-18C9-4019-A68F-75AFDB0B48FC@apple.com> I've just added two new sections to the WebGL editor's draft: https://www.khronos.org/registry/webgl/specs/latest/#4.5 https://www.khronos.org/registry/webgl/specs/latest/#6.20 Please review for accuracy and clarity... ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu May 26 18:29:15 2011 From: kbr...@ (Kenneth Russell) Date: Thu, 26 May 2011 18:29:15 -0700 Subject: [Public WebGL] Some ARB_robustness questions In-Reply-To: References: <338409528.36683.1306431437195.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> Message-ID: On Thu, May 26, 2011 at 10:55 AM, Cedric Vivier wrote: > On Fri, May 27, 2011 at 00:37, Benoit Jacob wrote: >> How do you plan to implement the part where you restore the context and contine running the content? How can you restore all the GL state, including textures/shaders/buffers? > > Context restoration does not happen automatically unless the > application prevented the default behavior (lose the context forever). > All state and data needs to be reinitialized by the application : > > "" > Once the context is restored, WebGL resources such as textures and > buffers that were created before the context was lost are no longer > valid. The application must reinitialize the context's state and > recreate all such resources. > "" That's right -- in the earlier emails on this thread, restoring the context involves sending a webglcontextrestored event to the canvas. Regarding the error produced by eglMakeCurrent, a WebGL implementation might need to respond differently if some other sort of error than EGL_CONTEXT_LOST was generated. I don't have a concrete example though. -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 cal...@ Thu May 26 20:27:48 2011 From: cal...@ (Mark Callow) Date: Fri, 27 May 2011 12:27:48 +0900 Subject: [Public WebGL] Updated WebGL spec with bounds checking info In-Reply-To: <0180C242-18C9-4019-A68F-75AFDB0B48FC@apple.com> References: <0180C242-18C9-4019-A68F-75AFDB0B48FC@apple.com> Message-ID: <4DDF1A34.2050909@hicorp.co.jp> The text in the non-normative box of 4.5 sounds very normative: "...runtime checks must be added to ensure compliant behavior." Section 6.2 gives indexing with a constant expression as an example of dynamic indexing. What is dynamic about it? Regards -Mark On 11/05/27 3:18, Chris Marrin wrote: > > I've just added two new sections to the WebGL editor's draft: > > https://www.khronos.org/registry/webgl/specs/latest/#4.5 > https://www.khronos.org/registry/webgl/specs/latest/#6.20 > > Please review for accuracy and clarity... > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From tim...@ Thu May 26 23:28:00 2011 From: tim...@ (Tim Johansson) Date: Fri, 27 May 2011 08:28:00 +0200 Subject: [Public WebGL] Updated WebGL spec with bounds checking info In-Reply-To: <0180C242-18C9-4019-A68F-75AFDB0B48FC@apple.com> References: <0180C242-18C9-4019-A68F-75AFDB0B48FC@apple.com> Message-ID: <4DDF4470.1090307@opera.com> Some comments:

Out-of-Range Array Accesses

Dynamic Indexing of Arrays

The lack of in these headers breaks rendering for me. In 6.20 there is no mention of array of samplers (which are uniforms), I really think we should disallow arrays of samplers as they will not work on all GLES implementations, we have already run into at least one where it does not work. What should happen if you try to index using a non constant expression? I would prefer if compilation fails as it is an error in the shader, this is how gles implementations seems to handle it and it would make writing conformance tests for it easy. Do we need to mention this or is it implied? //Tim On 2011-05-26 20:18, Chris Marrin wrote: > > I've just added two new sections to the WebGL editor's draft: > > https://www.khronos.org/registry/webgl/specs/latest/#4.5 > https://www.khronos.org/registry/webgl/specs/latest/#6.20 > > Please review for accuracy and clarity... > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tim...@ Thu May 26 23:58:50 2011 From: tim...@ (Tim Johansson) Date: Fri, 27 May 2011 08:58:50 +0200 Subject: [Public WebGL] ANGLE Dynamic Indexing of Arrays of Samplers In-Reply-To: <007DEA16-3D04-4E4F-AACB-2C30508D466B@apple.com> References: <007DEA16-3D04-4E4F-AACB-2C30508D466B@apple.com> Message-ID: <4DDF4BAA.2060903@opera.com> On 2011-05-26 19:19, Chris Marrin wrote: > > I'm adding the following statement to the differences section: > > The GLSL ES spec[GLES20GLSL] allows but does not mandate support for dynamic > indexing of arrays of samplers. WebGL disallows this support. > > This is in support of tightening the language about array bounds checking. Does ANGLE currently make this check and disallow such indexing? > I would be very surprised if it did as it could not possible pass the conformance tests if it did. The test gl-min-textures.html has a shader which looks like: "uniform sampler2D uni[8]; void main() { vec4 c = vec4(0,0,0,0); for (int ii = 0; ii < NUM_TEXTURES; ++ii) { c += texture2D(uni[ii], vec2(0.5, 0.5)); } gl_FragColor = c; }" That is preventing us from passing the conformance tests on some GLES implementations. There is also an unrolled version of the test which does not use dynamic indexing of sampler arrays - gl-min-textures-unroll.html. Do the persons who wrote those two tests (svn indicates Gregg and Mo) know if there are any known problems with the unrolled version or if we can just switch to using that? //Tim > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Fri May 27 09:12:12 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Fri, 27 May 2011 09:12:12 -0700 Subject: [Public WebGL] ANGLE Dynamic Indexing of Arrays of Samplers In-Reply-To: <4DDF4BAA.2060903@opera.com> References: <007DEA16-3D04-4E4F-AACB-2C30508D466B@apple.com> <4DDF4BAA.2060903@opera.com> Message-ID: On Thu, May 26, 2011 at 11:58 PM, Tim Johansson wrote: > On 2011-05-26 19:19, Chris Marrin wrote: > >> >> I'm adding the following statement to the differences section: >> >> The GLSL ES spec[GLES20GLSL] allows but >> does not mandate support for dynamic >> indexing of arrays of samplers. WebGL disallows this support. >> >> This is in support of tightening the language about array bounds checking. >> Does ANGLE currently make this check and disallow such indexing? >> >> I would be very surprised if it did as it could not possible pass the > conformance tests if it did. > > The test gl-min-textures.html has a shader which looks like: > > "uniform sampler2D uni[8]; > void main() > { > vec4 c = vec4(0,0,0,0); > for (int ii = 0; ii < NUM_TEXTURES; ++ii) { > c += texture2D(uni[ii], vec2(0.5, 0.5)); > } > gl_FragColor = c; > }" > Is that dynamic indexing? I thought since NUM_TEXTURES is replaced by a constant it's static. I assumed dynamic meant that the indices can change depending on the input. For example uniform sampler2D ab[2]; uniform int aOrB; void main () { gl_FragColor = texture2D(ab[aOrB], vec2(0.5, 0.5)); } is dynamic indexing since it can not be unrolled. > That is preventing us from passing the conformance tests on some GLES > implementations. > > There is also an unrolled version of the test which does not use dynamic > indexing of sampler arrays - gl-min-textures-unroll.html. Do the persons who > wrote those two tests (svn indicates Gregg and Mo) know if there are any > known problems with the unrolled version or if we can just switch to using > that? > > //Tim > > > ----- >> ~Chris >> cmarrin...@ >> >> >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Sat May 28 08:23:13 2011 From: cma...@ (Chris Marrin) Date: Sat, 28 May 2011 08:23:13 -0700 Subject: [Public WebGL] ANGLE Dynamic Indexing of Arrays of Samplers In-Reply-To: <4DDF4BAA.2060903@opera.com> References: <007DEA16-3D04-4E4F-AACB-2C30508D466B@apple.com> <4DDF4BAA.2060903@opera.com> Message-ID: <398868D5-D8DC-4A81-A2A1-C79C9EBC16AB@apple.com> On May 26, 2011, at 11:58 PM, Tim Johansson wrote: > On 2011-05-26 19:19, Chris Marrin wrote: >> >> I'm adding the following statement to the differences section: >> >> The GLSL ES spec[GLES20GLSL] allows but does not mandate support for dynamic >> indexing of arrays of samplers. WebGL disallows this support. >> >> This is in support of tightening the language about array bounds checking. Does ANGLE currently make this check and disallow such indexing? >> > I would be very surprised if it did as it could not possible pass the conformance tests if it did. > > The test gl-min-textures.html has a shader which looks like: > > "uniform sampler2D uni[8]; > void main() > { > vec4 c = vec4(0,0,0,0); > for (int ii = 0; ii < NUM_TEXTURES; ++ii) { > c += texture2D(uni[ii], vec2(0.5, 0.5)); > } > gl_FragColor = c; > }" I sent this out too soon. We actually allow support for loop index array deref, which is what the above case is. Sorry for the confusion ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Sun May 29 01:52:29 2011 From: ste...@ (stephen white) Date: Sun, 29 May 2011 18:22:29 +0930 Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? Message-ID: Could ANGLE target the Flash shader assembly AGAL, so a Flash plug-in could be used from Javascript like a WebGL canvas? -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From mit...@ Sun May 29 08:35:01 2011 From: mit...@ (=?utf-8?B?bWl0Y2gud2lsbGlhbXNAM2Qtb25saW5lLmNvbQ==?=) Date: Sun, 29 May 2011 08:35:01 -0700 Subject: [Public WebGL] =?utf-8?B?UmU6IFtQdWJsaWMgV2ViR0xdIENvdWxkIEZsYXNoIHJ1biBPcGVuR0wgRVMgMi4wIHNoYWRlcnM/?= Message-ID: <201105291535.p4TFYnNP014329@secure2.khronos.org> Sent from my HTC on the Now Network from Sprint! ----- Reply message ----- From: "stephen white" Date: Sun, May 29, 2011 1:52 am Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? To: "public webgl" Could ANGLE target the Flash shader assembly AGAL, so a Flash plug-in could be used from Javascript like a WebGL canvas? -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim...@ Mon May 30 04:39:39 2011 From: tim...@ (Tim Johansson) Date: Mon, 30 May 2011 13:39:39 +0200 Subject: [Public WebGL] ANGLE Dynamic Indexing of Arrays of Samplers In-Reply-To: References: <007DEA16-3D04-4E4F-AACB-2C30508D466B@apple.com> <4DDF4BAA.2060903@opera.com> Message-ID: <4DE381FB.4080705@opera.com> On 2011-05-27 18:12, Gregg Tavares (wrk) wrote: > > > On Thu, May 26, 2011 at 11:58 PM, Tim Johansson > wrote: > > On 2011-05-26 19:19, Chris Marrin wrote: > > > I'm adding the following statement to the differences section: > > The GLSL ES spec[GLES20GLSL] > allows but does not mandate support for dynamic > indexing of arrays of samplers. WebGL disallows this support. > > This is in support of tightening the language about array > bounds checking. Does ANGLE currently make this check and > disallow such indexing? > > I would be very surprised if it did as it could not possible pass > the conformance tests if it did. > > The test gl-min-textures.html has a shader which looks like: > > "uniform sampler2D uni[8]; > void main() > { > vec4 c = vec4(0,0,0,0); > for (int ii = 0; ii < NUM_TEXTURES; ++ii) { > c += texture2D(uni[ii], vec2(0.5, 0.5)); > } > gl_FragColor = c; > }" > > > > Is that dynamic indexing? I thought since NUM_TEXTURES is replaced by > a constant it's static. I assumed dynamic meant that the indices can > change depending on the input. For example > You're right of cause, it is not dynamic so it must be a bug in the that specific OpenGL ES implementation. I'll just try to add a workaround for it instead. //Tim > uniform sampler2D ab[2]; > uniform int aOrB; > > void main () { > gl_FragColor = texture2D(ab[aOrB], vec2(0.5, 0.5)); > } > > is dynamic indexing since it can not be unrolled. > > > That is preventing us from passing the conformance tests on some > GLES implementations. > > There is also an unrolled version of the test which does not use > dynamic indexing of sampler arrays - gl-min-textures-unroll.html. > Do the persons who wrote those two tests (svn indicates Gregg and > Mo) know if there are any known problems with the unrolled version > or if we can just switch to using that? > > //Tim > > > ----- > ~Chris > cmarrin...@ > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > . > To unsubscribe, send an email to majordomo...@ > with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Mon May 30 07:19:13 2011 From: ste...@ (stephen white) Date: Mon, 30 May 2011 23:49:13 +0930 Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? Message-ID: On 30/05/2011, at 1:05 AM, mitch.williams...@ wrote: > > > Sent from my HTC on the Now Network from Sprint! > There was no text, sorry. I'm still interested in the answer though. :) Steve. > ----- Reply message ----- > From: "stephen white" > Date: Sun, May 29, 2011 1:52 am > Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? > To: "public webgl" > > > Could ANGLE target the Flash shader assembly AGAL, so a Flash plug-in could be used from Javascript like a WebGL canvas? -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Mon May 30 08:27:54 2011 From: ste...@ (Steve Baker) Date: Mon, 30 May 2011 10:27:54 -0500 Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? In-Reply-To: References: Message-ID: <4DE3B77A.10408@sjbaker.org> > Could ANGLE target the Flash shader assembly AGAL, so a Flash plug-in could be used from Javascript like a WebGL canvas? In principle - one turing-complete computational system can do what any other can - so long as it can plot pixels to the screen, it's could do it. HOWEVER, the efficiency of such a system would be problematic - and the flash shader language is nasty machine-code so at the very least, we'd have to completely compile GLSL and optimize into the flash shader language. By comparison, GLSL and HLSL are remarkably similar languages and the smallest syntactic tweaks are all that is usually required to get one into the other. But why on earth do such an incredibly nasty thing? We have native WebGL implementations coming on-stream for all of the major platforms. Why layer atop a plugin and go through all that ugliness? -- Steve ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Mon May 30 08:42:23 2011 From: ste...@ (stephen white) Date: Tue, 31 May 2011 01:12:23 +0930 Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? In-Reply-To: <4DE3B77A.10408@sjbaker.org> References: <4DE3B77A.10408@sjbaker.org> Message-ID: On 31/05/2011, at 12:57 AM, Steve Baker wrote: > But why on earth do such an incredibly nasty thing? We have native > WebGL implementations coming on-stream for all of the major platforms. Except IE, and the Flash option wouldn't need installing like the Chrome Frame plugin. I wasn't really thinking of WebGL shader code to AGAL, but more on the driver level where WebGL is compiled to the card's native code anyway. AGAL could just be treated as hardware bytecode? -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ste...@ Mon May 30 10:16:45 2011 From: ste...@ (stephen white) Date: Tue, 31 May 2011 02:46:45 +0930 Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? In-Reply-To: References: <4DE3B77A.10408@sjbaker.org> Message-ID: <07E90CCF-689A-4D08-98BF-57F8B9498A0D@adam.com.au> On 31/05/2011, at 1:12 AM, stephen white wrote: > I wasn't really thinking of WebGL shader code to AGAL, but more on the driver level where WebGL is compiled to the card's native code anyway. AGAL could just be treated as hardware bytecode? To clarify, the compiler would need to be in Javascript to run on IE, and it could compile WebGL shader code to the byte code underlying AGAL to create a Flash block that is the same as canvas3d. -- steve...@ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Mon May 30 14:55:47 2011 From: ben...@ (Ben Vanik) Date: Mon, 30 May 2011 14:55:47 -0700 Subject: [Public WebGL] Could Flash run OpenGL ES 2.0 shaders? In-Reply-To: <07E90CCF-689A-4D08-98BF-57F8B9498A0D@adam.com.au> References: <4DE3B77A.10408@sjbaker.org> <07E90CCF-689A-4D08-98BF-57F8B9498A0D@adam.com.au> Message-ID: I actually started playing with the concept awhile back with the goal of getting WebGL running on Flash Molehill. Unfortunately, the overhead for communicating frame data to Flash was just too high - both in terms of garbage created (causing frequent, long GCs and dropped frames) and the latency (synchronous calls over ExternalInterface, no matter how optimized, suck). It'd work fine for static or pre-defined scenes, but if you are trying to respond to user input it doesn't work well enough to be usable (e.g., games). On Mon, May 30, 2011 at 10:16 AM, stephen white wrote: > > On 31/05/2011, at 1:12 AM, stephen white wrote: > > I wasn't really thinking of WebGL shader code to AGAL, but more on the > driver level where WebGL is compiled to the card's native code anyway. AGAL > could just be treated as hardware bytecode? > > > To clarify, the compiler would need to be in Javascript to run on IE, and > it could compile WebGL shader code to the byte code underlying AGAL to > create a Flash block that is the same as canvas3d. > > -- > steve...@ > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue May 31 10:43:02 2011 From: gma...@ (Gregg Tavares (wrk)) Date: Tue, 31 May 2011 10:43:02 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: So I was thinking this morning, what's the point of the readonly flag and how does it work? It seemed like the point was to make an XHR returned buffer readonly but then that adds a new problem. There are 2 use cases 1) I want to read the data in a readonly buffer. To do that I want to create a view and I want that view not to make a copy and therefore the view is readonly 2) I want a copy of the data in the buffer. How do I do this? Are there now 2 constructors for views? One to make a copy and one to make view? Does it work as is or does it need more? On Fri, Apr 22, 2011 at 6:20 PM, Kenneth Russell wrote: > > The Typed Array editors' draft has been updated: > > http://www.khronos.org/registry/typedarray/specs/latest/ > > with changes supporting the following functionality: > > - Ability to copy sections of an ArrayBuffer > - Read-only ArrayBuffers > - Support for zero-copy data transfer via postMessage by defining the > behavior of ArrayBuffers and ArrayBufferViews under structured clone > > The changes are clearly highlighted in the spec with "Strawman proposal". > > The strawman proposal for the behavior of ArrayBuffers and views under > structured clone was discussed informally between Mozilla and Google, > and has undergone some iteration. (Earlier iterations involved making > an explicit API call to achieve transfer of ownership, and having the > default behavior perform a copy.) The current behavior was preferred > by members of the TC-39 committee, because it achieves unsurprising > performance characteristics. > > We believe that these changes will be efficiently implementable in > current JavaScript engines and web browsers. > > Your feedback on these changes would be greatly appreciated. Please > send them to the list. > > Thanks, > > -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 > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue May 31 13:14:08 2011 From: kbr...@ (Kenneth Russell) Date: Tue, 31 May 2011 13:14:08 -0700 Subject: [Public WebGL] Typed Array spec updates: strawman proposals In-Reply-To: References: Message-ID: On Tue, May 31, 2011 at 10:43 AM, Gregg Tavares (wrk) wrote: > So I was thinking this morning, what's the point of the readonly flag and > how does it work? > It seemed like the point was to make an XHR returned buffer readonly but > then that adds a new problem. There are 2 use cases > 1) I want to read the data in a readonly buffer. To do that I want to create > a view and I want that view not to make a copy and therefore the view is > readonly You would just instantiate the view against the ArrayBuffer; this operation never causes a copy. The indexed setter, if called, would throw an exception. So far the consensus is that in all modern JavaScript engines it will be possible to implement the read-only check without a test per store, which was the primary concern. > 2) I want a copy of the data in the buffer. How do I do this? Are there now > 2 constructors for views? One to make a copy and one to make view? > Does it work as is or does it need more? The simplest way would be to call "buffer.slice(0)". -Ken > On Fri, Apr 22, 2011 at 6:20 PM, Kenneth Russell wrote: >> >> The Typed Array editors' draft has been updated: >> >> http://www.khronos.org/registry/typedarray/specs/latest/ >> >> with changes supporting the following functionality: >> >> ?- Ability to copy sections of an ArrayBuffer >> ?- Read-only ArrayBuffers >> ?- Support for zero-copy data transfer via postMessage by defining the >> behavior of ArrayBuffers and ArrayBufferViews under structured clone >> >> The changes are clearly highlighted in the spec with "Strawman proposal". >> >> The strawman proposal for the behavior of ArrayBuffers and views under >> structured clone was discussed informally between Mozilla and Google, >> and has undergone some iteration. (Earlier iterations involved making >> an explicit API call to achieve transfer of ownership, and having the >> default behavior perform a copy.) The current behavior was preferred >> by members of the TC-39 committee, because it achieves unsurprising >> performance characteristics. >> >> We believe that these changes will be efficiently implementable in >> current JavaScript engines and web browsers. >> >> Your feedback on these changes would be greatly appreciated. Please >> send them to the list. >> >> Thanks, >> >> -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 >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- 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 -----------------------------------------------------------