gecko-dev/layout/base/AutoProfilerStyleMarker.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

95 строки
3.7 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef mozilla_AutoProfilerStyleMarker_h
#define mozilla_AutoProfilerStyleMarker_h
#include "mozilla/Attributes.h"
#include "mozilla/ProfilerMarkers.h"
#include "mozilla/ServoTraversalStatistics.h"
#include "mozilla/TimeStamp.h"
namespace mozilla {
class MOZ_RAII AutoProfilerStyleMarker {
public:
explicit AutoProfilerStyleMarker(UniquePtr<ProfileChunkedBuffer> aCause,
Bug 1583271 - Part 1: Change profiler page information IDs to BrowsingContextID and InnerWindowID r=gerald,nika We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They weren't quite good because: 1. While loading an iframe, they were being registered twice with the same ids(for about:blank and the real URL) sometimes. 2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child processes if the parent is in a different process. That may not be the case for now, but it will be after fission. So we had to find other IDs to: 1. Determine the Tab of the frames. 2. Determine the URLs of the frames. For the first use case, we were using nsDocShell::mHistoryId for that purpose but that was wrong. The closest thing that we can get to a tab ID is BrowsingContext ID because they don't change after a navigation. But iframes have different BrowsingContext's, so we still need to create a tree to construct a tab content. That can be either in the front-end or capture time. For the second use case, we were using a key pair of mHistoryId and mOSHE. We now chose to keep inner window IDs for that purpose. Inner window IDs are unique for each navigation loads because inner window correspond to each JS window global objects. That's why we can use that without any problem. But one problem is that we cannot handle `history.pushState` and `history.replaceState` changes with that change since window global objects won't change during those. But that was the best thing we can do after fission. So this will be a small sacrifice for us to keep that functionality working after fission. In that patch we also remove the registration/unregistration calls. We are going to add those calls in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D47065 --HG-- extra : moz-landing-system : lando
2019-10-10 00:25:11 +03:00
const Maybe<uint64_t>& aInnerWindowID)
: mActive(profiler_can_accept_markers()),
mStartTime(TimeStamp::Now()),
mCause(std::move(aCause)),
Bug 1583271 - Part 1: Change profiler page information IDs to BrowsingContextID and InnerWindowID r=gerald,nika We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They weren't quite good because: 1. While loading an iframe, they were being registered twice with the same ids(for about:blank and the real URL) sometimes. 2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child processes if the parent is in a different process. That may not be the case for now, but it will be after fission. So we had to find other IDs to: 1. Determine the Tab of the frames. 2. Determine the URLs of the frames. For the first use case, we were using nsDocShell::mHistoryId for that purpose but that was wrong. The closest thing that we can get to a tab ID is BrowsingContext ID because they don't change after a navigation. But iframes have different BrowsingContext's, so we still need to create a tree to construct a tab content. That can be either in the front-end or capture time. For the second use case, we were using a key pair of mHistoryId and mOSHE. We now chose to keep inner window IDs for that purpose. Inner window IDs are unique for each navigation loads because inner window correspond to each JS window global objects. That's why we can use that without any problem. But one problem is that we cannot handle `history.pushState` and `history.replaceState` changes with that change since window global objects won't change during those. But that was the best thing we can do after fission. So this will be a small sacrifice for us to keep that functionality working after fission. In that patch we also remove the registration/unregistration calls. We are going to add those calls in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D47065 --HG-- extra : moz-landing-system : lando
2019-10-10 00:25:11 +03:00
mInnerWindowID(aInnerWindowID) {
if (!mActive) {
return;
}
MOZ_ASSERT(!ServoTraversalStatistics::sActive,
"Nested AutoProfilerStyleMarker");
ServoTraversalStatistics::sSingleton = ServoTraversalStatistics();
ServoTraversalStatistics::sActive = true;
}
~AutoProfilerStyleMarker() {
if (!mActive) {
return;
}
struct StyleMarker {
static constexpr mozilla::Span<const char> MarkerTypeName() {
return mozilla::MakeStringSpan("Styles");
}
static void StreamJSONMarkerData(
baseprofiler::SpliceableJSONWriter& aWriter,
uint32_t aElementsTraversed, uint32_t aElementsStyled,
uint32_t aElementsMatched, uint32_t aStylesShared,
uint32_t aStylesReused) {
aWriter.IntProperty("elementsTraversed", aElementsTraversed);
aWriter.IntProperty("elementsStyled", aElementsStyled);
aWriter.IntProperty("elementsMatched", aElementsMatched);
aWriter.IntProperty("stylesShared", aStylesShared);
aWriter.IntProperty("stylesReused", aStylesReused);
}
static MarkerSchema MarkerTypeDisplay() {
using MS = MarkerSchema;
MS schema{MS::Location::markerChart, MS::Location::markerTable,
MS::Location::timelineOverview};
schema.AddKeyLabelFormat("elementsTraversed", "Elements traversed",
MS::Format::integer);
schema.AddKeyLabelFormat("elementsStyled", "Elements styled",
MS::Format::integer);
schema.AddKeyLabelFormat("elementsMatched", "Elements matched",
MS::Format::integer);
schema.AddKeyLabelFormat("stylesShared", "Styles shared",
MS::Format::integer);
schema.AddKeyLabelFormat("stylesReused", "Styles reused",
MS::Format::integer);
return schema;
}
};
ServoTraversalStatistics::sActive = false;
profiler_add_marker("Styles", geckoprofiler::category::LAYOUT,
{MarkerTiming::IntervalUntilNowFrom(mStartTime),
MarkerStack::TakeBacktrace(std::move(mCause)),
MarkerInnerWindowId(mInnerWindowID)},
StyleMarker{},
ServoTraversalStatistics::sSingleton.mElementsTraversed,
ServoTraversalStatistics::sSingleton.mElementsStyled,
ServoTraversalStatistics::sSingleton.mElementsMatched,
ServoTraversalStatistics::sSingleton.mStylesShared,
ServoTraversalStatistics::sSingleton.mStylesReused);
}
private:
bool mActive;
TimeStamp mStartTime;
UniquePtr<ProfileChunkedBuffer> mCause;
Bug 1583271 - Part 1: Change profiler page information IDs to BrowsingContextID and InnerWindowID r=gerald,nika We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They weren't quite good because: 1. While loading an iframe, they were being registered twice with the same ids(for about:blank and the real URL) sometimes. 2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child processes if the parent is in a different process. That may not be the case for now, but it will be after fission. So we had to find other IDs to: 1. Determine the Tab of the frames. 2. Determine the URLs of the frames. For the first use case, we were using nsDocShell::mHistoryId for that purpose but that was wrong. The closest thing that we can get to a tab ID is BrowsingContext ID because they don't change after a navigation. But iframes have different BrowsingContext's, so we still need to create a tree to construct a tab content. That can be either in the front-end or capture time. For the second use case, we were using a key pair of mHistoryId and mOSHE. We now chose to keep inner window IDs for that purpose. Inner window IDs are unique for each navigation loads because inner window correspond to each JS window global objects. That's why we can use that without any problem. But one problem is that we cannot handle `history.pushState` and `history.replaceState` changes with that change since window global objects won't change during those. But that was the best thing we can do after fission. So this will be a small sacrifice for us to keep that functionality working after fission. In that patch we also remove the registration/unregistration calls. We are going to add those calls in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D47065 --HG-- extra : moz-landing-system : lando
2019-10-10 00:25:11 +03:00
Maybe<uint64_t> mInnerWindowID;
};
} // namespace mozilla
#endif // mozilla_AutoProfilerStyleMarker_h