On Fri, Oct 02, 2015 at 12:18:12PM -0700, Justin Dolske wrote:
> Nice! Out of curiosity, how does "faster" work? Does it just ignore build
> targets/directories that involve native code?
Greg answered this :)
> FWIW, I benchmarked various no-changes builds with yesterday's m-c, on my
> low-end Su
On Mon, Oct 05, 2015 at 03:08:15PM -0400, Benoit Girard wrote:
> This is great progress!
>
> I had hope that something like this would also include the 'build binaries'
> DAG. It might make it slightly slower but it should still be very fast and
> lessen the cognitive load. I was under the impress
-- Forwarded message --
From:
Date: Mon, Oct 5, 2015 at 12:55 PM
Subject: [Planned] TCW 10-10-2015 6a - 2p PDT
To: all-moco-m...@mozilla.com
Issue Status: Upcoming
Short Summary: We will have our next tree closing window on 10/10/2015
starting at 6a
to perform the following work
On Mon, Oct 5, 2015 at 12:20 PM, Kartikaya Gupta wrote:
> The Blink guys have been exploring other options as well -
> things like CompositorWorker [1], where you can have some JS running
> in the compositor at 60fps doing animations.
>
A generic API like CompositorWorker would be ideal, as it g
I think that as it stands, yes, APZ is going to be a "permanent" part
of the platform. You're right that having higher-latency scroll events
creates some problems and makes it harder to drive animations off it.
We do have plans to provide more APIs for controlling things in the
compositor which sho
This is great progress!
I had hope that something like this would also include the 'build binaries'
DAG. It might make it slightly slower but it should still be very fast and
lessen the cognitive load. I was under the impression that 'build binaries'
at some point was a single DAG but it doesn't s
This is great progress!
I had hope that something like this would also include the 'build binaries'
DAG. It might make it slightly slower but it should still be very fast and
lessen the cognitive load. I was under the impression that 'build binaries'
at some point was a single DAG but it doesn't s
Basically a set of build actions related to frontend development and known
by moz.build files are assembled in a single make file that contains a
single DAG and doesn't need to recurse into directories. See
python/mozbuild/mozbuild/backend/fastermake.py and /faster/Makefile
for the low-level detail
Unfortunately, it looks like the kind of counter I would need is not yet
supported[1].
Even if some bank in the world is using dialog=1, what does it give
them? It doesn't change the behaviour of the window like showModalDialog
(which runs in a nested event loop), it just changes the buttons
avail
Nice! Out of curiosity, how does "faster" work? Does it just ignore build
targets/directories that involve native code?
FWIW, I benchmarked various no-changes builds with yesterday's m-c, on my
low-end Surface Pro 3 (i3, 4GB)...
mach build: 7:38
mach build browser: 0:43
mach build toolkit: 1:42
m
That list sounds right to me. I think our bizdev and/or legal people should be
looped in here though. Mike, not sure if you're the right person, but I bet you
know who is
On Fri, Oct 02, 2015 at 04:20:06PM +0200, Frédéric WANG wrote:
> Thank you,
>
> I downloaded the Firefox builds on mozil
On 2015-10-04 10:39 PM, Jonas Sicking wrote:
On Fri, Oct 2, 2015 at 1:03 PM, Ehsan Akhgari wrote:
On 2015-10-02 2:42 PM, Jonas Sicking wrote:
It might still mean that we can save time on tryserver if we only
build these by default if the user has opted in to running the
relevant tests.
I agr
Hi everyone,
Here's the list of new issues found and filed by the Desktop Manual QA
team last week (Week 40: September 28 - October 02).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://etherpad.mozilla.org/Desktop
13 matches
Mail list logo
