summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorvadimt <vadimt@chromium.org>2014-11-05 08:27:30 -0800
committerCommit bot <commit-bot@chromium.org>2014-11-05 16:27:55 +0000
commit3bba8cd024e0ebf5316d3f998a3765c10b1f9f99 (patch)
tree26f0834d5075b1e20c9ed12320437d2e7fd752f0
parent494662f81661acaf75ab747791d476f71abe34fb (diff)
downloadchromium_src-3bba8cd024e0ebf5316d3f998a3765c10b1f9f99.zip
chromium_src-3bba8cd024e0ebf5316d3f998a3765c10b1f9f99.tar.gz
chromium_src-3bba8cd024e0ebf5316d3f998a3765c10b1f9f99.tar.bz2
Instrumenting internals of BrowserGpuChannelHostFactory::EstablishRequest::FinishOnMain to locate jankiness.
BrowserGpuChannelHostFactory::EstablishRequest::FinishOnMain is responsible for 17.9 janks per hour in UI thread. I need to instrument the code inside it to find out which part causes jank. Dear reviewer! If you know where the jank is, or have ideas where I need to add more instrumentations, please let me know! This is a mechanical change that adds instrumentation required to locate the source of jankiness (i.e. a long-running fragment of code executed as a part of the task that causes jank) in the code. See the bug for details on what kind of jank we are after. A number of similar CLs were landed, and none of them caused issues. They've helped to find and fix janky code. The code of the instrumentation is highly optimized and is not expected to affect performance. The code simply creates a diagnostic task which is identical to ones created by PostTask or IPC message handlers. The task gets created only in developer build and in Canary channel. BUG=430106 Review URL: https://codereview.chromium.org/691143003 Cr-Commit-Position: refs/heads/master@{#302810}
-rw-r--r--content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc13
1 files changed, 13 insertions, 0 deletions
diff --git a/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc b/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc
index bc76245c..a5ba180 100644
--- a/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc
+++ b/content/common/gpu/client/webgraphicscontext3d_command_buffer_impl.cc
@@ -22,6 +22,7 @@
#include "base/message_loop/message_loop.h"
#include "base/metrics/field_trial.h"
#include "base/metrics/histogram.h"
+#include "base/tracked_objects.h"
#include "content/common/gpu/client/gpu_channel_host.h"
#include "content/public/common/content_constants.h"
#include "content/public/common/content_switches.h"
@@ -127,8 +128,18 @@ bool WebGraphicsContext3DCommandBufferImpl::MaybeInitializeGL() {
TRACE_EVENT0("gpu", "WebGfxCtx3DCmdBfrImpl::MaybeInitializeGL");
+ // Below, we perform an expensive one-time initialization that is required to
+ // get first pixels to the screen. This can't be called "jank" since there is
+ // nothing on the screen. Using TaskStopwatch to exclude the operation from
+ // jank calculations.
+ tracked_objects::TaskStopwatch stopwatch;
+ stopwatch.Start();
+
if (!CreateContext(surface_id_ != 0)) {
Destroy();
+
+ stopwatch.Stop();
+
initialize_failed_ = true;
return false;
}
@@ -146,6 +157,8 @@ bool WebGraphicsContext3DCommandBufferImpl::MaybeInitializeGL() {
real_gl_->SetErrorMessageCallback(getErrorMessageCallback());
+ stopwatch.Stop();
+
visible_ = true;
initialized_ = true;
return true;