On 07/04/2015 23:41, Robert O'Callahan wrote:
On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp ga...@gavinsharp.com 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
Yes they are built on the same SPS profiler backend.
However, the gecko profiler addon will do things the builtin devtools
can't, like open a shell and call `atos` to symbolicate C++ function
addresses.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1132529 for some context.
For the time
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
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
On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg benja...@smedbergs.us
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
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?
On Tue, Apr 7, 2015 at 5:05 PM, Bill McCloskey wmcclos...@mozilla.com
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
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 improvements we
On Tue, Apr 7, 2015 at 10:06 AM, George Wright geo...@mozilla.com 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
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 far
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
On Tue, Apr 7, 2015, at 11:05 AM, Bill McCloskey wrote:
On Tue, Apr 7, 2015 at 5:48 AM, Benjamin Smedberg benja...@smedbergs.us
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
On Wed, Apr 8, 2015 at 6:27 AM, Gavin Sharp ga...@gavinsharp.com 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
13 matches
Mail list logo
