On 04/07/2015 06:06 PM, Robert O'Callahan wrote:
> On Wed, Apr 8, 2015 at 8:00 AM, wrote:
>> Not sure do what degree we can replicate on Windows what we do on
>> FFOS to launch content processes.
>
> The Cygwin people have looked into fork() in Windows a bit. Some
> links:
> http://www.cygwin.
On Wed, Apr 8, 2015 at 8:00 AM, wrote:
> Not sure do what degree we can replicate on Windows what we do on FFOS to
> launch content processes.
The Cygwin people have looked into fork() in Windows a bit. Some links:
http://www.cygwin.com/ml/cygwin-developers/2011-04/msg00036.html
https://github.
Daniel,
Le 8 avr. 2015 à 06:19, Daniel Holbert a écrit :
> People already have inconsistent interpretations of what the bug
> "status" field ASSIGNED vs NEW means (and inconsistent
> levels-of-bothering-to-actually-tweak-the-flag).
(Sorry if it had already been discussed in the past, slap me wit
On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp wrote:
> > We don't have telemetry yet. I've done some measurements and haven't
> found
> > any cases where tab switching consistently takes longer in e10s. However,
> > it's certainly possible that it does on average. Either way, it's hard to
> > inves
On 04/07/2015 01:15 PM, Tobias B. Besemer wrote:
> OK, to reopen this discussion ...
>
> I suggested in Bug 1151371 to activate the status "IN_PROGRESS" in bmo and
> use this status for bugs that are "in progress" ("patch in work") and that
> everybody use the status "applied" in future only as
OK, to reopen this discussion ...
I suggested in Bug 1151371 to activate the status "IN_PROGRESS" in bmo and use
this status for bugs that are "in progress" ("patch in work") and that
everybody use the status "applied" in future only as "taken" or as "in the
to-dos-list" like the others do.
My
Counter-intuitively, having multiple content processes may use less memory than
taking screenshots per tab. Especially if we use the same COW forking FFOS uses
the overhead of a content processes should be very small, certainly less than a
high resolution screenshot kept around. Not sure do wha
On Tue, Apr 7, 2015, at 11:05 AM, Bill McCloskey wrote:
> On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg
> wrote:
>
> > With desktop e10s on there can be a noticeable delay after switching tabs
> > where there is a throbber displayed before the page content.
> >
>
> When the user switches tab
On Tue, Apr 7, 2015 at 10:06 AM, George Wright wrote:
> We've discussed adding telemetry probes to measure page painting time so
> we can properly gauge what the impact is of e10s vs non-e10s. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1135719 for the bug tracking
> page render time iss
> We don't have telemetry yet. I've done some measurements and haven't found
> any cases where tab switching consistently takes longer in e10s. However,
> it's certainly possible that it does on average. Either way, it's hard to
> investigate until we can reproduce the problem.
I see the spinner f
On 2015-04-07 8:48 AM, Benjamin Smedberg wrote:
Is the duration of this delay measured in telemetry anywhere, and do
we have criteria for how much delay is acceptable in this case? If
e10s were off, do we expect that this same delay would occur but would
just show up as a jank switching tabs? O
>
> > I think we probably want to use a longer delay than 300ms before we show
> > the spinner. We'd also like to look into why it takes so long to
> re-create
> > the layer tree when we switch to a tab. Sometimes it's caused by a janky
> > content process, but there may be some layout/gfx improvem
On Tue, Apr 7, 2015 at 5:05 PM, Bill McCloskey
wrote:
> I think we probably want to use a longer delay than 300ms before we show
> the spinner. We'd also like to look into why it takes so long to re-create
> the layer tree when we switch to a tab. Sometimes it's caused by a janky
> content proces
On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg
wrote:
> With desktop e10s on there can be a noticeable delay after switching tabs
> where there is a throbber displayed before the page content.
>
When the user switches tabs, we allow the content process 300ms to send
layer information to the p
I have just landed a patch which changes the "level 1" Windows content process
sandbox policy to one which runs the process at a low integrity level from the
start. This will hopefully make it into tomorrow's Nightly.
(pref: security.sandbox.content.level=1)
Running at low integrity for the whol
e10s team will probably answer these questions better than I can...
Is the duration of this delay measured in telemetry anywhere,
I don't think any existing Telemetry probes measure this effect. We have
the FX_TAB_* histograms but I doubt they reflect the duration of the
tab-switch throbber anim
With desktop e10s on there can be a noticeable delay after switching
tabs where there is a throbber displayed before the page content.
Is the duration of this delay measured in telemetry anywhere, and do we
have criteria for how much delay is acceptable in this case? If e10s
were off, do we ex
17 matches
Mail list logo
