Sample recent OSX bundle
Hi, I've been packaging an XR app for OSX since the begining of times (XR1.8) and while there has always been glitches and adjustments, I've always been able to upgrade (I use C++ XPCOM components and I build outside the mozilla tree). I am trying to update from 14 to 29 and while the compilation is now eventually OK (not trivial, clang, C++11, etc) I am stuck with the bundling. It seems that the previous folder hierarchy doesn't work anymore (couldn't load XPCOM). Before I spend too much time investigating this, I'd like to know if there is a sample OSX app somewhere I can study. Of course it has to use a recent XR (29 ideally but I think 22+ would be ok) and of course it can't be FF as it is not an XR app per say. Would you guys know any ? Any up to date XR doc would be welcome obviously :) Thanks, renaud ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
On Mon, May 5, 2014 at 11:07 PM, Dan Glastonbury dglastonb...@mozilla.com 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 expect this to scale over several decades? 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. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
On Tue, May 6, 2014 at 2:00 PM, Gabriele Svelto gsve...@mozilla.com 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 that besides the context creation the API is a superset of WebGL 1.0 [1] so it shouldn't require an entirely separate API but just extending the existing one. Or am I missing something? [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 it justifies having a mode switch. If the API is backwards compatible, there should be no need for a mode switch. We've learned twice now that mode switches are a source of pain (quirks mode, use strict). It looks like we're about to learn it a third time, unless I'm missing even more. -- http://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
2014-05-06 11:04 GMT-04:00 Anne van Kesteren ann...@annevk.nl: On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann tzimmerm...@mozilla.com 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. Yes, but Khronos can say that at some point v1 is no longer supported. Or particular GPU vendors can say that. But this API is for the web, where we can't and where we've learned repeatedly that mode switches are terrible in the long run. For the record, the only time the Khronos broke compatibility with a new GL API version, was with the release of OpenGL ES 2.0 (on which WebGL 1 is based), which dropped support for OpenGL ES 1.0 API. That's the only ever instance: newer ES versions (like ES 3.0, on which WebGL 2 is based) are strict supersets, and regular non-ES OpenGL versions are always supersets --- all the way from 1992 OpenGL 1.0 to the latest OpenGL 4.4. This is just to provide a data point that OpenGL has a long track record of strictly preserving with long-term API compatibility. The other point I'm reading above is about mode switches. I think you're making a valid point here. I also think that the particulars of WebGL2 still make it a decent trade-off. Indeed, the alternative to doing WebGL2 is to expose the same functionality as a collection of WebGL 1 extensions (1) (In fact, some of that functionality is already exposed (2)). We could take that route. However, that would require figuring out the interactions for all possible subsets of that set of extensions. There would be nontrivial details to sort out in writing the specs, and in writing conformance tests. To get a feel of the complexity of interactions between different OpenGL extensions (3). Just exposing this entire set of extensions at once as WebGL2 reduces a lot of the complexity of interactions. Some more particulars of WebGL2 may be useful to spell out here to clarify why this is a reasonable thing for us to implement. WebGL2 follows ES 3.0 which loosely follows OpenGL 3.2 from 2009, and most of it is OpenGL 3.0 from 2008. So this API has been well adopted and tested in the real world for five years now. ES 3.0 functionality is universally supported on current desktop hardware, and is the standard for newer mobile hardware too, even in the low end (for example, all Adreno 300 mobile GPUs support it). We have received consistent feedback from game developers that WebGL 2 would make it much easier for them to port their newer rendering paths to the Web. The spec process is already well on its way with other browser vendors on board (Google, Apple) as one can see from public_webgl mailing list archives. Benoit (1) http://www.khronos.org/registry/webgl/extensions/ (2) E.g. http://www.khronos.org/registry/webgl/extensions/WEBGL_draw_buffers/ and http://www.khronos.org/registry/webgl/extensions/ANGLE_instanced_arrays/ (3) Search for the phrase affects the definition of this extension in the language of OpenGL extension specs such as http://www.khronos.org/registry/gles/extensions/EXT/EXT_draw_buffers.txt to mention just one extension that's become a WebGL extension and part of WebGL 2. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
2014-05-06 12:11 GMT-04:00 Boris Zbarsky bzbar...@mit.edu: 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 the WebGL2 context id and get something back that guarantees that all the new methods are implemented. But one could do something similar via implementations simply guaranteeing that if you ask for the WebGL context ID and get back an object and it has any of the new methods on it, then they're all present and work. Are there other reasons there's a separate context id for WebGL2? To what extent does what I wrote in my previous email, regarding interactions between different extensions, answer your question? With the example approach you suggested above, one would have to specify extensions separately and for each of them, their possible interactions with other extensions. Moreover, most of the effort spent doing that would be of little use in practice as current desktop hardware / newer mobile hardware supports all of that functionality. And realistically, the primary target audience there is games, and games already have their code paths written for ES2 and/or for ES3 i.e. they already expect the mode switch. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 separately and for each of them, their possible interactions with other extensions. Why? This is the part I don't get. The approach I suggest is that a UA is allowed to expose the new methods on the return value of getContext(webgl), but only if it exposes all of them. In other words, it's functionally equivalent to the WebGL2 spec, except the way you get a context continues to be getContext(webgl) (which is the part that Anne was concerned about, afaict). -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
2014-05-06 12:53 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com: 2014-05-06 12:32 GMT-04:00 Boris Zbarsky bzbar...@mit.edu: 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 separately and for each of them, their possible interactions with other extensions. Why? This is the part I don't get. The approach I suggest is that a UA is allowed to expose the new methods on the return value of getContext(webgl), but only if it exposes all of them. In other words, it's functionally equivalent to the WebGL2 spec, except the way you get a context continues to be getContext(webgl) (which is the part that Anne was concerned about, afaict). 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. A good example (that is a WebGL 1 extension and that is part of WebGL 2) is float textures. http://www.khronos.org/registry/webgl/extensions/OES_texture_float/ WebGL has a method, texImage2D, that allows uploading texture data; and it has various enum values, like BYTE and INT and FLOAT, that allow specifying the type of data. 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. So this adds real functionality (enables using textures with floating-point RGB components) without changing anything at the DOM interface level. There are more examples. Even when OES_texture_float is supported, FLOAT textures don't support linear filtering by default. That is, in turn, enabled by the OES_texture_float_linear extension, http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ Both these WebGL extensions are part of core WebGL 2, so they are relevant examples. Well, I guess the but only if it exposes all of them part of your proposal would make this work, because other parts of WebGL2 do add new methods and constants. But, suppose that an application relies on WebGL2 features that don't change IDL (there are many more, besides the two I mentioned). In your proposal, they would have to either check for unrelated things on the WebGL interface, which seems clunky, or try to go ahead and try to use the feature and use WebGL.getError to check for errors if that's unsupported, which would be slow and error-prone. Benoit Benoit -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: intent to ship: drawFocusIfNeeded
On Tue, 6 May 2014, Robert O'Callahan wrote: On Tue, May 6, 2014 at 5:57 PM, Ian Hickson i...@hixie.ch wrote: Just so we're clear, I really don't care what the name is, nor do I have any objection to people having private conversations or whatnot. My point is just that there has not been a conversation in the WHATWG list about this which has resulted in the name being changed. So you're saying that discussions on any forum other than the WHATWG list are ignored for the purposes of you making changes to WHATWG specs? They're not ignored, but I am unlikely to hear about them, and if I don't hear about them, or if they aren't convincing, then they're not likely to result in changes to the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
2014-05-06 13:07 GMT-04:00 Boris Zbarsky bzbar...@mit.edu: 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 talking about specifically the set of things we want to expose in WebGL2, which do include new methods. In particular, the contract would be that if any of the new methods are supported, then FLOAT texture upload is also supported. The fact that these may be extensions under the hood doesn't seem really relevant, as long as the contract is that the support is all-or-nothing. Our last emails crossed, obviously :) My point is it would be a clunky API if, in order to test for feature X that does not affect the DOM interface, one had to test for another unrelated feature Y. Anyway I've shared what I think I know on this topic; I'll let other people (who contrary to me are working on WebGL at the moment) give their own answers. Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WebGL 2.0
2014-05-06 13:15 GMT-04:00 Ralph Giles gi...@mozilla.com: 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 the error as a feature or version check it should still get the correct answer. I didn't say it would break anything. I just commented on why enabling this feature wasn't just a switch at the DOM interface level. There are more examples. Even when OES_texture_float is supported, FLOAT textures don't support linear filtering by default. That is, in turn, enabled by the OES_texture_float_linear extension, http://www.khronos.org/registry/webgl/extensions/OES_texture_float_linear/ This looks similar. Are there extensions which cause rendering differences merely by enabling them? No. WebGL2 does not break any WebGL 1 API. WebGL extensions do not break any API. E.g. everything in webgl2 is exposed on a 'webgl' context, and calling getExtension to enable extensions which are also webgl2 core features is a no-op? I guess the returned interface description would need new spec language in webgl2 if there are ever extensions with the same name written against different versions of the spec. No, there just won't be different extensions for WebGL2 vs WebGL1 with the same name. Is this what you mean about considering (and writing tests for) all the interactions? No, I meant something different. Different extensions add different spec language, and sometimes it's nontrivial to work out the details of how these additions to the spec interplay. For example, if you start with an API that allows doing only additions, and only supports integers; if you then specify an extension for floating-point numbers, and another extension for multiplication, then you need to work out the interaction between the two: are you allowing multiplication of floating-point numbers? Do you specify it in the multiplication spec or in the floating-point spec? 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.khronos.org/registry/webgl/specs/1.0/#5.14.14 It would be like getExtension was silently called on context creation. That is indeed the only difference between a WebGL2 rendering context and a WebGL1 rendering context. (In a theoretical world where all of WebGl2 would be specced as WebGL1 extensions). Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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.khronos.org/registry/webgl/specs/1.0/#5.14.14 This model generally isn't how extensibility/versioning has been done on the Web platform. On the other hand, it's a model that's less problematic than most of the alternatives that have been proposed, in that it does deal reasonably with multiple implementations and iterative addition of features. The main problem I see is the implementation cost that Anne mentioned: as all these extensions accumulate, that requires implementations to track (forever) which extensions have been requested and whether the API being used has been properly requested. As more and more extensions accumulate, this code could become complicated, possibly even with complexity worse than O(N) in the number of extensions or versions. I also wonder if there's a tension here relating to the target audience. Is WebGL intended primarily for porting applications written for other platforms (and with those other platforms practices and conventions in mind) or primarily for authors building things on the Web platform (and accustomed to its conventions)? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling strict warnings as errors in xpcshell
- Original Message - From: Chris Peterson cpeter...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Tuesday, May 6, 2014 3:11:40 PM Subject: Re: Disabling strict warnings as errors in xpcshell btw, I believe the JS team now uses the term extra warnings to differentiate SpiderMonkey's non-standard strict warnings (javascript.options.strict pref) from ES5's strict mode. Does anyone actually want these strict/extra warnings? Can we just remove this misfeature from SpiderMonkey? I find this feature extremely useful. When chrome code contains a typo, without extraWarnings we often just produce no error at all. The most common case is that Firefox opens to a blank window (i.e., no content is drawn) and no output. To solve these bugs, I've had to bisect my own code to find the typo. When it turns out to be something as simple as a typo, it's extremely frustrating. The extraWarnings option makes it very easy to quickly identify these sorts of bugs. In addition, I think the |if (obj.quacks)| example may be overly simplified. The JS engine is smart enough to recognize this pattern and not warn about it. As far as I know, there's no need to change it to |if (obj.quacks || false)|. The time you typically need to pull tricks like that is when passing optional properties to function, as in |func(foo, bar, obj.quacks)| when quacks may not be defined. This seems like bad practice to me though. It's not at all clear to the reader that you might not expect the property to be defined. These strict/extra warnings are also enabled in Firefox's debug builds (javascript.options.strict.debug pref), which can cause Firefox features to misbehave differently in debug and release builds. As far as I know, the warnings never change behavior. They just cause us to print warnings. Besides the `obj.quacks || false` problem, it can also report false positive warnings about some functions' unreachable code paths not returning a value. I agree that the unreachable code warning is pretty useless. I'd be fine removing it. The undefined property one is the only useful one that I know of. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
