<!--
Copyright 2020 The Chromium Authors
Use of this source code is governed by a BSD-style license that can be
found in the LICENSE file.
-->

<!--
This file is used to generate a comprehensive list of others histograms
along with a detailed description for each histogram.

For best practices on writing histogram descriptions, see
https://chromium.googlesource.com/chromium/src.git/+/HEAD/tools/metrics/histograms/README.md

Please follow the instructions in the OWNERS file in this directory to find a
reviewer. If no OWNERS file exists, please consider signing up at
go/reviewing-metrics (Googlers only), as all subdirectories are expected to
have an OWNERS file. As a last resort you can send the CL to
chromium-metrics-reviews@google.com.
-->

<histogram-configuration>

<histograms>

<histogram name="Scheduling.BeginImplFrameLatency2" units="microseconds"
    expires_after="M85">
  <owner>stanisc@chromium.org</owner>
  <summary>
    The time from v-sync to when the main side actually starts the
    BeginImplFrame.

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the
    solution.
  </summary>
</histogram>

<histogram name="Scheduling.MessagePumpTimeKeeper.{NamedThread}"
    enum="MessagePumpPhases" expires_after="2024-05-31">
  <owner>gab@chromium.org</owner>
  <owner>fdoray@chromium.org</owner>
  <owner>spvw@chromium.org</owner>
  <summary>
    Records the number of milliseconds spent in each phase of pumping tasks on
    {NamedThread}. Each enum value can be analyzed for its total time or as a
    percentage relative to other phases.
  </summary>
  <token key="NamedThread">
    <variant name="BrowserIO"/>
    <variant name="BrowserUI"/>
  </token>
</histogram>

<histogram name="Scheduling.Renderer.DeadlineMode"
    enum="RendererSchedulerDeadlineMode" expires_after="2024-02-04">
  <owner>weiliangc@chromium.org</owner>
  <owner>chrome-gpu-metrics@chromium.org</owner>
  <summary>
    The type of deadline mode the Renderer's cc::Scheduler is in when the
    scheduler enters the BeginImplFrame deadline. This emits immediately as the
    scheduler enters the deadline.
  </summary>
</histogram>

<histogram name="Scheduling.Renderer.DrawInterval2" units="microseconds"
    expires_after="never">
<!-- expires-never: guiding metric (internal: go/chrome-browser-guiding-metrics) -->

  <owner>vmiura@chromium.org</owner>
  <owner>speed-metrics-dev@chromium.org</owner>
  <owner>chrome-analysis-team@google.com</owner>
  <summary>
    The time delta between the draw times of back-to-back BeginImplFrames,
    regardless of whether or not they result in a swap.

    The interval is only recorded when every BeginImplFrame wants to draw.

    Do not modify this metric in any way without contacting
    speed-metrics-dev@chromium.org AND chrome-analysis-team@google.com.

    Warning: This metric may include reports from clients with low-resolution
    clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports
    will cause this metric to have an abnormal distribution. When considering
    revising this histogram, see UMA_HISTOGRAM_CUSTOM_HIGH_RESOLUTION_TIMES for
    the solution.
  </summary>
</histogram>

<histogram base="true" name="ThreadPool.NumTasksBeforeDetach" units="tasks"
    expires_after="M85">
  <owner>fdoray@chromium.org</owner>
  <owner>gab@chromium.org</owner>
  <owner>robliao@chromium.org</owner>
  <summary>
    Number of tasks executed by a SchedulerWorker before it detached. Recorded
    when a SchedulerWorker detaches.
  </summary>
</histogram>

<histogram base="true" name="ThreadPool.UnnecessaryWakeup" enum="BooleanHit"
    expires_after="2024-02-01">
  <owner>spvw@chromium.org</owner>
  <owner>gab@chromium.org</owner>
  <summary>
    Records a hit when a thread pool worker thread woke up unnecessarily (when
    the first GetWork called by a WorkerThread post-wakeup doesn't return a
    task). This count can be compared between experiments aiming to reduce
    wakeups. Or, it could be used to derive wakeups/{foo} by using UMA formulas
    against other time-or-event-based metrics.
  </summary>
</histogram>

</histograms>

</histogram-configuration>
