Re: Parallel sandboxed iframes
Hi, So far, nobody said that the idea was either stupid or impossible/impractical, so I went ahead and filed https://bugzilla.mozilla.org/show_bug.cgi?id=961689 David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: CPP_UNIT_TESTS being removed from make check
As far as I know this has not be set up, but it is definitely a good idea. I filed bug 961707. Cheers, Dan - Original Message - From: Chris Pearce cpea...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Sunday, January 19, 2014 11:11:47 PM Subject: Re: CPP_UNIT_TESTS being removed from make check Is there trychooser syntax for just running the cpp tests on a try push? And can http://trychooser.pub.build.mozilla.org/ be updated to include it please? :) Cheers, Chris P. On 1/9/2014 7:00 AM, Ted Mielczarek wrote: Hello, Just a heads up that very soon we'll be removing CPP_UNIT_TESTS from the make check target[1]. The tests have been split out into a separate test job on TBPL[2] (labelled Cpp) for almost a month now without issue, and we've also added a mach command--mach cppunittests[3]--to facilitate running them locally, so we'd like to stop double-running them on the build machines. Running the tests as a separate job has a lot of nice qualities: the jobs can be retriggered in case of failure, the execution time doesn't tie up a build slave (and thus delay the posting of the build log by buildbot to where TBPL can get it), we can run the tests on Android and B2G, we get better platform coverage on our test slaves than on our build slaves. If you encounter any issues please feel free to file a bug. Regards, -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=949536 2. https://bugzilla.mozilla.org/show_bug.cgi?id=937637 3. https://bugzilla.mozilla.org/show_bug.cgi?id=949538 ___ 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: Exact rooting is now enabled on desktop
On 1/17/14 1:24 PM, Terrence Cole wrote: SpiderMonkey will no longer scan the stack for live roots; you must now wrap all GC thing pointers that live on the stack across a GC in the JS::Rooted template for SpiderMonkey to see them. See the comments in js/public/RootingAPI.h and the guide on the developer wiki[1] for further details. All currently existing instances in the browser build have been updated; the hazard analysis build on TBPL, SM(Hf), will catch any future pushes that break this invariant. Great work! My only question: do JIT backends need to be adjusted for this? I assume not, but I want to make sure. Cameron Kaiser ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Exact rooting is now enabled on desktop
On Fri, Jan 17, 2014 at 3:22 PM, Jim Blandy j...@mozilla.com wrote: I've never heard of a major project escaping from conservative GC once it had entered that state of sin; nor have I heard of anyone implementing a moving collector after starting with a non-moving collector. There's no better way to answer the question has X been done? than proclaiming loudly on the internet that X has never been done! I did this by quoting Jim in a blog post [1] and was promptly informed that both Racket and Mono have done this. But who cares? This is a fantastic achievement, and I eagerly anticipate the changes it will enable. Nick [1] https://blog.mozilla.org/nnethercote/2014/01/20/a-big-step-towards-generational-and-compacting-gc/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Subpixel AA text rendering on OSX
Hi, Currently in gecko we have code to determine if text being drawn into a transparent surface has opaque content underneath it. In the case where it doesn't we ask moz2d/cairo [1] to disable subpixel AA text rendering for this surface since it can have poor results depending on what the eventual background color is. However, this setting was only ever respected for the GDI font rendering backend with cairo, and the other backends ignored it (unless they do something internally?). Moz2D matched this until recently, until bug 941095 made the CoreGraphics backend start respecting the value as well. The two extreme examples of where this might matter are as follows: - A transparent surface with a very nearly opaque background color (the OSX content menus uses rgba(255,255,255,0.95) iirc). In this case it's probably ok to use subpixel AA since we're so close to opaque. The OSX context menu's used to get subpixel AA text in this case since the value was ignored, but no longer do (on nightly) since we respect the value. - A fully transparent surface containing only text. It should be fairly easy to get this to happen by 3d transforming a text element. I suspect we don't want subpixel AA here, since we have no idea what the final background color might be (and it could change every frame if the transform is animated). CG was previously still giving us subpixel AA in this case, but won't be any more. I doubt we want to ship the text quality regression for OSX context menus, so we need to find a solution to this. Preferably something that is consistent across backends :) Possible ideas: - Revert the change to the Moz2D CG backend. This takes us back to matching our previous behaviour, but not ideal to have Moz2D API functions that are ignored on some backends. - Keep the change, and instead #ifdef XP_OSX the callers inside gecko. This keeps Moz2D cleaner, at the expense of gecko. - Come up with some definition of 'close enough to opaque to get away with subpixel AA' and have gecko compute this instead of looking for completely opaque background. I have no idea what that definition would be exactly. - Others? Does anyone have any suggestions for this, or knowledge about why only GDI bothered with this previously? Thanks! - Matt [1] http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxASurface.h#136 or http://mxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h#957 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Ideas for making it easier and less error prone for Firefox OS partners to expose certified only APIs
On 1/18/2014, 12:19 PM, Anne van Kesteren wrote: On Fri, Jan 17, 2014 at 9:44 PM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Can anybody think of other similar techniques which we can adopt to improve our story here? Suggestions on WebIDL annotations, code changes, documentation, etc. are much appreciated! If they implement and expose such an API, that should be documented somewhere too as it affects the attack surface of Firefox OS. Agreed. However, whether they will do this work is a different question. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
Hi, I have some questions, and would be nice if someone could answer. I will really appreciate. * Mozilla will not provide more Xulrunner builds (runtime)? * If not, developers will be able to compile Xulrunner builds from Mozilla code? * Will Mozilla continues the Xulrunner development? * What happens with Xulrunner based apps? *This is the more important to me* Maybe those questions are explained before, but could be great if someone could answer some of them. Regards, Gio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
