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 being
On 07/04/2015 23:41, Robert O'Callahan wrote:
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 averag
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
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
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
12 matches
Mail list logo
