Re: Intent to implement: WebGL 2.0

On Fri, May 9, 2014 at 1:48 AM, Jonas Sicking wrote: > Based on what has been discussed in this thread so far, specifically that: > * We expect each new version of WebGL to be fully backwards compatible. Do we? I certainly hope that is the case, but it did not seem like a given or stated requirem

Re: Intent to implement: WebGL 2.0

On Thu, May 8, 2014 at 1:40 PM, Ehsan Akhgari wrote: > On 2014-05-08, 8:55 AM, Anne van Kesteren wrote: >> >> On Thu, May 8, 2014 at 12:56 PM, Benoit Jacob >> wrote: >>> >>> WebGL is low-level and generalistic enough that it is not specifically a >>> "3d" graphics API. I prefer to call it a low-l

Re: Intent to implement: WebGL 2.0

On 2014-05-08, 8:55 AM, Anne van Kesteren wrote: On Thu, May 8, 2014 at 12:56 PM, Benoit Jacob wrote: WebGL is low-level and generalistic enough that it is not specifically a "3d" graphics API. I prefer to call it a low-level or generalistic graphics API. Fair, forgot about that argument. "we

Re: Intent to implement: WebGL 2.0

On 2014-05-08, 5:51 AM, Anne van Kesteren wrote: On Wed, May 7, 2014 at 6:19 PM, Benoit Jacob wrote: The "Implementations are free to return a context that implements a higher version" part violates the above requirement 1. in your email, "The WebGL working group wants web pages to opt in to th

Re: Intent to implement: WebGL 2.0

On Thursday, May 8, 2014 5:25:49 AM UTC-4, Henri Sivonen wrote: > Making the Web little-endian may indeed have been the right thing. > Still, at least from the outside, it looks like the WebGL group didn't > make an intentional wise decision to make the Web little-endian but > instead made a naive

Re: Intent to implement: WebGL 2.0

On 08/05/14 12:56, Benoit Jacob wrote: > (*plug*) this might be useful reading: > https://hacks.mozilla.org/2013/04/the-concepts-of-webgl/ Comedy. I just read that article, and thought "this article is awesomely useful." I then looked at the comments, and it turned out that the first comment is fr

Re: Intent to implement: WebGL 2.0

On Thu, May 8, 2014 at 12:56 PM, Benoit Jacob wrote: > WebGL is low-level and generalistic enough that it is not specifically a > "3d" graphics API. I prefer to call it a low-level or generalistic graphics > API. Fair, forgot about that argument. "webgles" or some such might be better then. Or en

Re: Intent to implement: WebGL 2.0

2014-05-08 5:53 GMT-04:00 Anne van Kesteren : > It seems like you want to be able to do that going forward so you > don't have to maintain a large matrix forever, but at some point say > you drop the idea that people will want 1 and simply return N if they > ask for 1. Yes, that's what we agreed

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 8:09 PM, Ehsan Akhgari wrote: > We had a meeting about this today, and there is one big issue with my > proposal above. Because of the fact that extra dictionary members in the > contextOptions arguments are ignored, this means that UA engines which have > already shipped t

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 6:19 PM, Benoit Jacob wrote: > The "Implementations are free to return a context that implements a higher > version" part violates the above requirement 1. in your email, "The WebGL > working group wants web pages to opt in to the WebGL2 specific parts of the > functionality

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 6:45 PM, Vladimir Vukicevic wrote: > On Wednesday, May 7, 2014 9:30:27 AM UTC-4, Henri Sivonen wrote: > >> >> In general, I'm worried about groups that are rather isolated and that >> have non-Web background members making decisions that go against the >> Web wisdom gained f

Re: Intent to implement: WebGL 2.0

webglex (to avoid the number) and make the version: N check mandatory for that? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: WebGL 2.0

On Wed 07 May 2014 12:42:07 PM PDT, Benoit Jacob wrote: > 2014-05-07 15:09 GMT-04:00 Ehsan Akhgari : > >> We had a meeting about this today, and there is one big issue with my >> proposal above. Because of the fact that extra dictionary members in the >> contextOptions arguments are ignored, this

Re: Intent to implement: WebGL 2.0

2014-05-07 15:09 GMT-04:00 Ehsan Akhgari : > We had a meeting about this today, and there is one big issue with my > proposal above. Because of the fact that extra dictionary members in the > contextOptions arguments are ignored, this means that UA engines which have > already shipped their imple

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 12:34 PM, Ehsan Akhgari wrote: On 2014-05-07, 11:40 AM, Vladimir Vukicevic wrote: On Wednesday, May 7, 2014 9:20:18 AM UTC-4, Ehsan Akhgari wrote: On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: WebGL is already following the OpenGL path. Trying to make it more "webby" by try

Re: Intent to implement: WebGL 2.0

2014-05-07 14:14 GMT-04:00 Boris Zbarsky : > On 5/7/14, 2:00 PM, Benoit Jacob wrote: > >> The idea is that if getContext("webgl", {version : N}) returns non-null, >> then the resulting context is guaranteed to be WebGL version N, so that >> no other versioning mechanism is needed. >> > > Sure, but

Re: Intent to implement: WebGL 2.0

On 5/7/14, 2:00 PM, Benoit Jacob wrote: The idea is that if getContext("webgl", {version : N}) returns non-null, then the resulting context is guaranteed to be WebGL version N, so that no other versioning mechanism is needed. Sure, but say some code calls getContext("webgl", { version: 1 }) and

Re: Intent to implement: WebGL 2.0

2014-05-07 13:41 GMT-04:00 Boris Zbarsky : > On 5/7/14, 12:34 PM, Ehsan Akhgari wrote: > >> Implementations are free to return a context that implements a higher >> version, should that be appropriate in the future, but never lower. >> > > As pointed out, this fails the explicit opt-in bit. > > Th

Re: Intent to implement: WebGL 2.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/05/14 10:19 AM, Benoit Jacob wrote: > The "Implementations are free to return a context that implements a > higher version" part violates the above requirement 1. in your > email, "The WebGL working group wants web pages to opt in to the > WebGL

Re: Intent to implement: WebGL 2.0

On 5/7/14, 9:20 AM, Ehsan Akhgari wrote: interface WebGL2RenderingContext : WebGLRenderingContext { // new methods go here }; partial interface HTMLCanvasElement { (CanvasRenderingContext2D or WebGLRenderingContext or WebGL2RenderingContext) getContext(DOMString id, optional any op

Re: Intent to implement: WebGL 2.0

On 5/7/14, 12:34 PM, Ehsan Akhgari wrote: Implementations are free to return a context that implements a higher version, should that be appropriate in the future, but never lower. As pointed out, this fails the explicit opt-in bit. There is also another problem here. If we go with this setup

Re: Intent to implement: WebGL 2.0

This looks great, modulo one detail: 2014-05-07 12:34 GMT-04:00 Ehsan Akhgari : > > I discussed the requirements of this API in person with vlad and bjacob. > Here are two key things to keep in mind: > > 1. The WebGL working group wants web pages to opt in to the WebGL2 > specific parts of the

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 5:34 PM, Ehsan Akhgari wrote: > What do people think about this solution? I think this looks great. This avoids the problems I mentioned (especially long term) while keeping the concept of explicit opt-in Khronos considers important. -- http://annevankesteren.nl/ ___

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 11:40 AM, Vladimir Vukicevic wrote: On Wednesday, May 7, 2014 9:20:18 AM UTC-4, Ehsan Akhgari wrote: On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: WebGL is already following the OpenGL path. Trying to make it more "webby" by trying to mush the APIs together isn't doing the

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 4:40 PM, Vladimir Vukicevic wrote: > WebGL made an explicit decision to do things this way -- the one thing that I > would go back and change is getExtension() returning an extension object, > instead of acting as an enableExtension(). I don't remember *why* we did > thi

Re: Intent to implement: WebGL 2.0

On 2014-05-07 14:23:30 +, Ehsan Akhgari said: There is some documentation on MDN and elsewhere . While getting more documentation should always be a goal, I don't think we need to discuss th

Re: Intent to implement: WebGL 2.0

On Wednesday, May 7, 2014 9:30:27 AM UTC-4, Henri Sivonen wrote: > > In general, I'm worried about groups that are rather isolated and that > have non-Web background members making decisions that go against the > Web wisdom gained from painful experience. The WebGL group wasn't/isn't isolated fr

Re: Intent to implement: WebGL 2.0

On Wednesday, May 7, 2014 9:20:18 AM UTC-4, Ehsan Akhgari wrote: > On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: > > >> WebGL is already following the OpenGL path. Trying to make it more > >> "webby" by trying to mush the APIs together isn't doing the web a favor > >> since the API is alread

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 9:37 AM, Robert Kaiser wrote: Dan Glastonbury schrieb: /Summary/: Bring more power of GPU to browsers by exposing OpenGL ES 3 features in WebGL 2.0 We currently have (almost) no documentation on MDN for WebGL 1, do we intend to put concerted work into docs along with bringing up

Re: Intent to implement: WebGL 2.0

Dan Glastonbury schrieb: /Summary/: Bring more power of GPU to browsers by exposing OpenGL ES 3 features in WebGL 2.0 We currently have (almost) no documentation on MDN for WebGL 1, do we intend to put concerted work into docs along with bringing up WebGL 2? KaiRo __

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 1:15 PM, Anne van Kesteren wrote: > On Wed, May 7, 2014 at 3:46 AM, Vladimir Vukicevic > wrote: >> Defining every feature of WebGL 2 as an extension would result in a huge >> amount of busy work > > It could just be a single "extension" as bz suggested earlier in the thre

Re: Intent to implement: WebGL 2.0

On 2014-05-07, 6:15 AM, Anne van Kesteren wrote: WebGL is already following the OpenGL path. Trying to make it more "webby" by trying to mush the APIs together isn't doing the web a favor since the API is already more OpenGL-like, isn't doing developers a favor since they now have to have this

Re: Intent to implement: WebGL 2.0

On Wed, May 7, 2014 at 3:46 AM, Vladimir Vukicevic wrote: > FWIW, the reason you have to explicitly enable extensions is that we didn't > want content that "accidentally works". In contrast with regular OpenGL, > where every extension is always enabled and the query just tells you what is > av

Re: Intent to implement: WebGL 2.0

On Tuesday, May 6, 2014 7:30:42 PM UTC-4, Ehsan Akhgari wrote: > On 2014-05-06, 6:41 PM, Jonas Sicking wrote: > > >> That's why if we just expose different features on the object returned by > >> getContext("webgl") depending on client hardware details, we will create a > >> compatibility mess, un

Re: Intent to implement: WebGL 2.0

The crux of the issue here seems to be whether we want WebGL to be more like OpenGL or more like the web. Each approach carries an impedence mismatch with a large class of content. So it kind of boils down to whether we're more trying to lure OpenGL developers to the web or lure web developers to 3

Re: Intent to implement: WebGL 2.0

On 2014-05-06, 6:41 PM, Jonas Sicking wrote: That's why if we just expose different features on the object returned by getContext("webgl") depending on client hardware details, we will create a compatibility mess, unlike other Web APIs. The main probably that you have is that you haven't design

Re: Intent to implement: WebGL 2.0

2014-05-06 18:41 GMT-04:00 Jonas Sicking : > I disagree with several points of this email. > > On Tue, May 6, 2014 at 2:18 PM, Benoit Jacob > wrote: > > So, thinking more about this, here's what I think is the deeper concern > > here. > > > > If we make a feature available, we have to expect that

Re: Intent to implement: WebGL 2.0

I disagree with several points of this email. On Tue, May 6, 2014 at 2:18 PM, Benoit Jacob wrote: > So, thinking more about this, here's what I think is the deeper concern > here. > > If we make a feature available, we have to expect that people will write > code assuming support for it. We can't

Re: Intent to implement: WebGL 2.0

So, thinking more about this, here's what I think is the deeper concern here. If we make a feature available, we have to expect that people will write code assuming support for it. We can't honestly believe that all Web developers write careful feature checks for all the features they depend on.

Re: Intent to implement: WebGL 2.0

On Tuesday 2014-05-06 10:15 -0700, Ralph Giles wrote: > It looks like doing so would violate to webgl1 spec. "An attempt to use > any features of an extension without first calling getExtension to > enable it must generate an appropriate GL error and must not make use of > the feature." https://www

Re: Intent to implement: WebGL 2.0

On 2014-05-06, 1:21 PM, Benoit Jacob wrote: 2014-05-06 13:07 GMT-04:00 Boris Zbarsky : On 5/6/14, 12:53 PM, Benoit Jacob wrote: Ah, I see the confusion now. So the first reason why what you're suggesting wouldn't work for WebGL is that WebGL extension my add functionality without changing any

Re: Intent to implement: WebGL 2.0

2014-05-06 13:15 GMT-04:00 Ralph Giles : > On 2014-05-06 9:53 AM, Benoit Jacob wrote: > > > By default, WebGL does not allow FLOAT to be passed for > > the type parameter of the texImage2D method. The OES_texture_float > > extension make that allowed. > > I have trouble seeing how this could break

Re: Intent to implement: WebGL 2.0

2014-05-06 13:07 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:53 PM, Benoit Jacob wrote: > >> Ah, I see the confusion now. So the first reason why what you're >> suggesting >> wouldn't work for WebGL is that WebGL extension my add functionality >> without changing any IDL at all. >> > > Sure, but we'

Re: Intent to implement: WebGL 2.0

On 2014-05-06 9:53 AM, Benoit Jacob wrote: > By default, WebGL does not allow FLOAT to be passed for > the type parameter of the texImage2D method. The OES_texture_float > extension make that allowed. I have trouble seeing how this could break current implementations. If a page somehow looks for

Re: Intent to implement: WebGL 2.0

On 5/6/14, 12:53 PM, Benoit Jacob wrote: Ah, I see the confusion now. So the first reason why what you're suggesting wouldn't work for WebGL is that WebGL extension my add functionality without changing any IDL at all. Sure, but we're not talking about arbitrary WebGL extensions. We're talkin

Re: Intent to implement: WebGL 2.0

2014-05-06 12:53 GMT-04:00 Benoit Jacob : > > > > 2014-05-06 12:32 GMT-04:00 Boris Zbarsky : > > On 5/6/14, 12:25 PM, Benoit Jacob wrote: >> >>> To what extent does what I wrote in my previous email, regarding >>> interactions between different extensions, answer your question? >>> >> >> I'm not s

Re: Intent to implement: WebGL 2.0

2014-05-06 12:32 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:25 PM, Benoit Jacob wrote: > >> To what extent does what I wrote in my previous email, regarding >> interactions between different extensions, answer your question? >> > > I'm not sure it answers it at all. > > > With the example approach

Re: Intent to implement: WebGL 2.0

On 5/6/14, 12:25 PM, Benoit Jacob wrote: To what extent does what I wrote in my previous email, regarding interactions between different extensions, answer your question? I'm not sure it answers it at all. With the example approach you suggested above, one would have to specify extensions sep

Re: Intent to implement: WebGL 2.0

2014-05-06 12:11 GMT-04:00 Boris Zbarsky : > On 5/6/14, 12:03 PM, Benoit Jacob wrote: > >> Indeed, the alternative to doing WebGL2 >> is to expose the same functionality as a collection of WebGL 1 extensions >> > > I think Anne's question, if I understood it right, is why this requires a > new con

Re: Intent to implement: WebGL 2.0

On 5/6/14, 12:03 PM, Benoit Jacob wrote: Indeed, the alternative to doing WebGL2 is to expose the same functionality as a collection of WebGL 1 extensions I think Anne's question, if I understood it right, is why this requires a new context ID. I assume the argument is that if you ask for th

Re: Intent to implement: WebGL 2.0

2014-05-06 11:04 GMT-04:00 Anne van Kesteren : > On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann > wrote: > > I think Khronos made a bad experience with backwards compatible APIs > > during OpenGL's history. They maintained a compatible API for OpenGL for > > ~15 years until it was huge and cru

Re: Intent to implement: WebGL 2.0

On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann wrote: > I think Khronos made a bad experience with backwards compatible APIs > during OpenGL's history. They maintained a compatible API for OpenGL for > ~15 years until it was huge and crufty. Mode switches are their solution > to the problem. Y

Re: Intent to implement: WebGL 2.0

Hi >> >> [1] «WebGL 2 is backwards compatible with WebGL 1: existing content will >> run in WebGL 2 without modification. To access the new behavior provided >> in this specification, the content explicitly requests a new context» > > It seems I missed something. > > However, I cannot find where

Re: Intent to implement: WebGL 2.0

On Tue, May 6, 2014 at 2:00 PM, Gabriele Svelto wrote: > On 06/05/2014 14:43, Anne van Kesteren wrote: >> I suppose longer term we can map the older version to the newer >> versions somehow, but that's still an awfully big API surface area to >> maintain. > > The wording of the spec seems to imply

Re: Intent to implement: WebGL 2.0

On 06/05/2014 14:43, Anne van Kesteren wrote: > I suppose longer term we can map the older version to the newer > versions somehow, but that's still an awfully big API surface area to > maintain. The wording of the spec seems to imply that besides the context creation the API is a superset of WebG

Re: Intent to implement: WebGL 2.0

On Mon, May 5, 2014 at 11:07 PM, Dan Glastonbury wrote: > /Link to standard/: https://www.khronos.org/registry/webgl/specs/latest/2.0/ This looks really sad. For each new version of OpenGL, are we going to have a new version of the API we end up having to support forever? How exactly does Khronos

Intent to implement: WebGL 2.0

/Summary/: Bring more power of GPU to browsers by exposing OpenGL ES 3 features in WebGL 2.0 /Bug/: 889977 /Link to standard/: https://www.khronos.org/registry/webgl/specs/latest/2.0/ /Platform coverage/: Android, Desktop, Firefox OS /Estimated or target release/: TBD /Preference behind which thi