pdr@chromium.org animations-dev@chromium.org Time spent updating layers, in microseconds. Recorded when layers are updated (in a browser process). 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. pdr@chromium.org paint-dev@chromium.org Time spent updating layer draw properties, in microseconds. Recorded when a LayerTreeImpl's draw properties are updated (in a browser process). 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. khaslett@chromium.org petermcneeley@chromium.org graphics-dev@chromium.org The time since a BufferQueue's buffers were destroyed until they were recreated. If this time is commonly very small, that is a problem. Recorded when the buffer recreates buffers that were previously destroyed. For a single BufferQueue this should be once per frame at worst. cblume@chromium.org khushalsagar@chromium.org Every time a frame is presented, record the generalized color gamut of that frame. mmocny@chromium.org paint-dev@chromium.org Reports whether an image decode was for an image that might be used as the Largest Contentful Image, and then whether a missing tile at raster time includes such an image. The goal is to get an approximate idea of how many LCP candidate images miss their frame deadline, and hence how often we may report LCP too soon. Recorded on every {DecodeMethod} szager@chromium.org paint-dev@chromium.org sky@chromium.org Recorded on every commit. Indicates whether the renderer's main thread was blocked waiting for the impl thread to commit. True indicates the main thread did block. khaslett@chromium.org kylechar@chromium.org Time spent processing quads to see which can be replaced with overlays. This is logged once per frame, when a frame should be drawn. Only reported for platforms supporting high resolution clocks. vasilyt@chromium.org petermcneeley@chromium.org graphics-dev@chromium.org The area of the display damage that was added to current frame damage after all adjustments, including FrameBufferDamage from buffer queue and render pass filters. This metric is reported once per frame only on platforms/devices that support partial swap and does not include "empty swap" (no frame damage) case Note: this metric was expired from 2022-10-16 to 2023-06-09. vasilyt@chromium.org petermcneeley@chromium.org graphics-dev@chromium.org The area of the display that was damaged since previous draw to this frame buffer. This metric is reported once per frame only on platforms/devices that support partial swap and does not include "empty swap" (no frame damage) case. Note: this metric was expired from 2022-10-23 to 2023-06-09. vasilyt@chromium.org petermcneeley@chromium.org graphics-dev@chromium.org The area of the display that was damaged in current frame. This metric is reported only on platforms/devices that support partial swap and does not include "empty swap" (no frame damage) case. vasilyt@chromium.org petermcneeley@chromium.org graphics-dev@chromium.org The total area of the display that will be redrawn this frame. This metric is reported only on platforms/devices that support partial swap and does not include "empty swap" (no frame damage) case Note: this metric was expired from 2023-04-30 to 2023-06-09. magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org Whether all non-root render passes in a frame are skipped. Logged once per frame during DrawFrame for the frames with non-root render passes. magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org Logged for every non-root render pass in DrawRenderPass during DrawFrame. True if there is no damages to the render pass and the rendering is skipped. magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org Pixel size for a skipped nonroot render pass output surface. Recorded in Viz DirectRenderer draw frame. boliu@chromium.org vasilyt@chromium.org This is logged once for every ADPF performance hint report, which is generally once every frame on Android device that supports ADPF and ADPF is enabled. It's the interval reported to ADPF, which is currently implemented as the wall clock time from vsync frame time to swap_start. Only reported for platforms supporting high resolution clocks. yiyix@chromium.org chromeos-gfx@chromium.org Time spent to remove invisible quads from the quad_list in CompositorFrame. 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. jonross@chromium.org graphics-dev@chromium.org This is logged once per frame, if the output surface provides timing information. It measures the time from the display compositor starting a draw on the Viz Compositor thread to issuing all related draw calls to the driver on the Gpu Main thread. Only reported for platforms supporting high resolution clocks. khaslett@chromium.org kylechar@chromium.org Logged zero or more times per frame, whether the first call to HardwareDisplayController.TestPageFlip succeeded. khaslett@chromium.org kylechar@chromium.org Logged zero or more times per frame, the number of times TestPageFlip is called on the HardwareDisplayController. khaslett@chromium.org kylechar@chromium.org Logged zero or more times per frame, the duration of calling TestPageFlip on the HardwareDisplayController. Only reported for platforms supporting high resolution clocks. khaslett@chromium.org kylechar@chromium.org Logged zero or more times per frame, the duration of DrmThread::CheckOverlayCapabilitiesSync(). This is the total time spent on the DRM thread to check a set of overlay candidates. Only reported for platforms supporting high resolution clocks. jonross@chromium.org graphics-dev@chromium.org This is logged once per frame. It is the number of renderer passes after flattening all possible render passes. If the value is more than one, then an intermediate rendering target must be used during the rendering of the frame for each render pass greater than one. seanpaul@chromium.org chromeos-gfx-compositor@chromium.org Logged once per frame, represents whether we could successfully schedule a page flip, or what error we encountered along the way. Note: this metric was expired from 2023-03-02 to 2023-04-13. khaslett@chromium.org kylechar@chromium.org Logged zero or one times per frame, the number of stale candidate ids we are evicting from the OverlayCombinationCache this frame. If this number is high the CandidateIds or the candidates proposed are likely less stable than they should be. khaslett@chromium.org kylechar@chromium.org This is logged every time a valid HardwareCapabilities is received from DRM when display configuration may have changed. It records the number of overlay planes we have available on this device including the primary plane. khaslett@chromium.org kylechar@chromium.org Logged zero or one times per frame, whether or not the candidate combination being tested this frame was successfully promoted to overlays on the previous frame. khaslett@chromium.org kylechar@chromium.org This is logged once per frame, the number of times CheckOverlaySupport is called this frame. khaslett@chromium.org kylechar@chromium.org Logged zero or more times per frame, the time spent checking if a set of candidates can be promoted to overlay. Only reported for platforms supporting high resolution clocks. zoraiznaeem@chromium.org graphics-dev@chromium.org Records once per frame, whether we will attempt to promote any required overlay or not in that frame. zoraiznaeem@chromium.org graphics-dev@chromium.org Records zero or once per frame, whether we attempted scaling any required overlay. khaslett@chromium.org kylechar@chromium.org chromeos-gfx-compositor@chromium.org Logged once per frame, the number of overlays {Counted}. Note: this metric was expired from 2022-11-30 to 2023-04-13. khaslett@chromium.org kylechar@chromium.org Logged once per frame, the number of quads considered for promotion to overlay. khaslett@chromium.org kylechar@chromium.org Logged zero or one times per frame, whether we're using the AttemptingMultipleOverlays codepath this frame or why we arent. zoraiznaeem@chromium.org graphics-dev@chromium.org Records the scale factor that is used to downscale successfully promoted required candidates. It is only logged once per frame if a required overlay is promoted. Note: The scale factor value is logged as `scale_factor * 100`. sashamcintosh@chromium.org chromeos-gfx@chromium.org Records the count of pending swaps in the display scheduler. Length of the swap chain can be used as a rough approximation for input latency. Recorded before the swap executes. Refer to Display::DrawAndSwap for details. vasilyt@chromium.org backer@chromium.org This is logged once per frame, if the output surface provides timing information. It measures delta between the time when display compositor draw task's dependencies have been solved and the time when the Gpu Thread started processing it. Only reported for platforms supporting high resolution clocks. vasilyt@chromium.org backer@chromium.org This is logged once per frame if the output surface provides timing information. It measures delta between the time when display compositor scheduled first draw task for the current frame on Viz Compositor thread and the time when the task's dependencies have been resolved and the task is ready for the Gpu Thread to start processing it. Recorded when swap completes. Only reported for platforms supporting high resolution clocks. vasilyt@chromium.org backer@chromium.org This is logged once per frame if the output surface provides timing information. It measures delta between the time when display compositor scheduled first draw task for the current frame on Viz Compositor thread and the time when Gpu Thread started processing it. Recorded when swap completes. Only reported for platforms supporting high resolution clocks. szager@chromium.org paint-dev@chromium.org sky@chromium.org The time that the renderer's main thread blocked waiting for the impl thread to commit. This is only reported if the main thread blocked. Drops reports on clients with low-resolution clocks, biasing to a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. szager@chromium.org pdr@chromium.org paint-dev@chromium.org The time that ApplyCompositorChanges is blocked waiting for the impl thread to commit. This is a subset of the total time spent in Compositing.MainThreadBlockedDuringCommitTime. Drops reports on clients with low-resolution clocks, biasing to a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. awogbemila@chromium.org input-dev@chromium.org Records when we attempt to update an animation with a missing property node. See crbug.com/1307498. We safely handle this case but until we find and fix the root cause, this histogram allows us to keep track of the frequency at this occurs. magchen@chromium.org ccameron@chromium.org The percentage of changed IOSurface number in all IOSurface per frame. Recorded during the CALayer Tree commit to CoreAnimation on Mac. magchen@chromium.org ccameron@chromium.org The number of IOSurfaces changed per frame. Recorded during the CALayer Tree commit to CoreAnimation on Mac. magchen@chromium.org ccameron@chromium.org Total IOSurfaces area size updated per frame. Recorded during the CALayer Tree commit to CoreAnimation on Mac. ccameron@chromium.org graphics-dev@chromium.org The outcome of attempting to replace all renderer tiles with CALayers. Either success, or the first reason why a DrawQuad couldn't be replaced by a CALayer. pdr@chromium.org paint-dev@chromium.org Time spent updating layers, in microseconds. Recorded when layers are updated (in a renderer process). 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. wangxianzhu@chromium.org paint-dev@chromium.org Records the approximate kilo-pixels covered by text drawing operations by LCD-text disallowed reasons. Hence the histogram value for each reason is the approximate number of non-LCD kilo-pixels resulting from that reason. Recorded when the renderer is idle, at minimum interval of the longer of 1 minute and 500 begin frames for each local frame tree. wangxianzhu@chromium.org paint-dev@chromium.org Records the number of layers containing text by LCD-text disallowed reasons. Recorded along with Compositing.Renderer.LCDTextDisallowedReasonKPixels. pdr@chromium.org paint-dev@chromium.org The number of layers in the active tree for each compositor frame. This is logged once per frame, before the frame is drawn (in a renderer process). pdr@chromium.org paint-dev@chromium.org The number of PictureLayers in the active tree for each compositor frame. This is logged once per frame, before the frame is drawn (in a renderer process). pdr@chromium.org paint-dev@chromium.org The number of render surfaces in the render surface layer list. Recorded each time the render surface layer list is constructed (in a renderer process). khushalsagar@chromium.org vmpstr@chromium.org graphics-dev@chromium.org Logged for every nested RenderPass to indicate whether it could have been drawn directly because it has a single RPDQ and no other effect which would require producing a render pass. penghuang@chromium.org graphics-dev@chromium.org Records if the TileDrawQuad is rendered with RawDraw. magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org Logged for every RenderPassDrawQuad in the overlay list during ScheduleOverlays. An Overlay RenderPassDrawQuad is skipped if there is no damages to the render pass and the RenderPassDrawQuad settings are the same. magchen@chromium.org ccameron@chromium.org graphics-dev@chromium.org Pixel size for a skipped overlay render pass draw quad. Recorded in SkiaRenderer ScheduleOverlays. kylechar@chromium.org graphics-dev@chromium.org Time spent aggregating compositor frames from different surfaces in microseconds. This is logged once per frame. 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. kylechar@chromium.org jonross@chromium.org The number of surfaces where the active CompositorFrame was copied into the AggregateFrame during surface aggregation. This is logged once per frame. kylechar@chromium.org jonross@chromium.org Time spent copying quads during surface aggregation. This is a subset of the time recorded for Compositing.SurfaceAggregator.AggregateUs and is logged once per frame. Warning: This metric does not include reports from clients with low-resolution clocks. kylechar@chromium.org jonross@chromium.org Time spent declaring resources as used during surface aggregation. This is a subset of the time recorded for Compositing.SurfaceAggregator.AggregateUs and is logged once per frame. Warning: This metric does not include reports from clients with low-resolution clocks. magchen@chromium.org graphics-dev@chromium.org Record whether a frame has a specific type of render pass. This is logged once per frame. kylechar@chromium.org jonross@chromium.org The number of surfaces that were looked at during the prewalk phase of surface aggregation. This is logged once per frame. kylechar@chromium.org jonross@chromium.org Time spent doing prewalk during surface aggregation. This is a subset of the time recorded for Compositing.SurfaceAggregator.AggregateUs and is logged once per frame. Warning: This metric does not include reports from clients with low-resolution clocks. jonross@chromium.org graphics-dev@chromium.org The time between when a Surface has been Marked for Destruction, to when it is actually Destroyed. This time denotes how long the Surface remains referenced by other Surfaces, preventing deletion. This does not include the following time until the associated resources are released, and their memory is freed. This is logged once per destroyed Surface. lizeb@chromium.org chrome-gpu-memory@google.com When memory is assigned to tiles, whether there was enough memory for all required tiles. lizeb@chromium.org chrome-gpu-memory@google.com When memory is assigned to tiles and there is not enough memory, the memory limit that the tile assignment was breaching.. jonross@chromium.org graphics-dev@chromium.org Tracks the duration of various stages in the pipeline as a single frame goes through the various stages in the compositor in the cases that there is no damage from main thread. This metric uses base::Histogram::FactoryMicrosecondsTimeGet so only users with high resolution clocks will report this metric. Note: This metric was expired from 2023-03-01 to 2023-05-05. jonross@chromium.org graphics-dev@chromium.org Reports the overhead of IPC's and thread hops during the production of a single frame. Measures {LatencyType} This is reported by the Renderer, at a subsampled rate of effectively once per 1000 frames. Non-Renderer clients do not report this. This metric drops reports on low-resolution clocks, which will bias the Windows population. jonross@chromium.org graphics-dev@chromium.org Whether frame is dropped or presented meeting or missing the deadline or is a compositor only frame. jonross@chromium.org graphics-dev@chromium.org Tracks the duration of various stages in the pipeline as a single frame goes through the various stages in the compositor {ReportType}. This metric uses base::Histogram::FactoryMicrosecondsTimeGet so only users with high resolution clocks will report this metric. jonross@chromium.org yzshen@chromium.org graphics-dev@chromium.org Measures the time duration between Exo sending a DidNotProduceFrame response and the next frame arrival, if the next frame arrives before a new BeginFrame request. Reported for clients with high-resolution clocks. This metric is used to measure whether the deadline Exo uses to wait for frames is reasonable. Please note that a value is reported for each DidNotProduceFrame. If (1) DidNotProduceFrame is issued when there are already queued BeginFrame requests; or (2) a new BeginFrame request arrives before the next frame; or (3) BeginFrame requests are paused, then the value reported is 0. jonross@chromium.org yzshen@chromium.org graphics-dev@chromium.org Tracks the percent of BeginFrame requests that Exo receives and responds with DidNotProduceFrame. A new value is reported for every 100 BeginFrame requests that a shell surface receives. Note that this metric is reported only when there are sufficient number of BeginFrame requests (>= 100). jonross@chromium.org yzshen@chromium.org graphics-dev@chromium.org Tracks the percent of compositor frames that are submitted from Exo clients and directly discarded without being sent to the GPU process. A new value is reported for every 100 frames that a shell surface submits. Note that this metric is reported only when there are sufficient number of frames (>= 100). jonross@chromium.org graphics-dev@chromium.org The percent dropped frame is calculated for each sliding window of 1 second length and added to a histogram, and then the 95 percentile of that histogram is reported as 95pctPercentDroppedFrames_1sWindow. The sliding windows cover the duration of page-load (From start of page-load until user navigates away, or closes the tab/chrome, or when app goes to background). Note that this means that this metric will bias toward tabs that are closed more quickly, and might underreport tabs that remain open for a long duration. PercentDroppedFrames is measured by tracking the number of frames which were not displayed on screen out of the total number of frames expected to be produced and displayed. In other words, the lower this number is, the smoother experience. jonross@chromium.org graphics-dev@chromium.org Tracks the percent of checkerboarded frames for a sequence by aggregating all its animations and interactions, where a sequence is a series of frames produced which contain at least one of the animations/interactions. Such animations and interactions encompass: Compositor-thread animations; Main-thread animations; JS animations; scrolling; and pinch-gestures. Checkerboarding is measured by tracking the number of times checkerboard frames are displayed (as opposed to the number of checkerboard frames produced), since the same checkerboard frame can be displayed more than once. Note that this metric is reported only when there are a sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until an additional sequence completes where there are (>= 100) frames available in total. jonross@chromium.org graphics-dev@chromium.org Tracks the percent of checkerboarded frames for a sequence by aggregating all {Sequence}, where a sequence is a series of frames produced which contain at least one of the aforementioned effects. Checkerboarding is measured by tracking the number of times checkerboard frames are displayed (as opposed to the number of checkerboard frames produced), since the same checkerboard frame can be displayed more than once. Note that this metric is reported only when there are a sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until an additional sequence completes where there are (>= 100) frames available in total. jonross@chromium.org mjzhang@chromium.org graphics-dev@chromium.org Tracks the percent of janks for a particular sequence of frames (e.g. during scroll, animation, etc.). This is reported in various sub-metrics with suffixes describing the type of the sequence (e.g. TouchScroll etc.). Jank is measured by tracking the number of abrupt increases in frame presentation interval, divided by the total number of frames expected to be produced and displayed. The lower this number is, the less the smoothness varies over time. Note that this metric is reported only when there are sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until there are enough frames to produce the metric. jonross@chromium.org mjzhang@chromium.org graphics-dev@chromium.org Tracks the percent of janks for a particular frame sequence. {Type} Jank is measured by tracking the number of abrupt increases in frame presentation interval, divided by the total number of frames expected to be produced and displayed. The lower this number is, the less the smoothness varies over time. Note that this metric is reported only when there are sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until there are enough frames to produce the metric. jonross@chromium.org mjzhang@chromium.org graphics-dev@chromium.org Tracks the percent of janks for a sequence by aggregating all its {Type} Jank is measured by tracking the number of abrupt increases in frame presentation interval, divided by the total number of frames expected to be produced and displayed. The lower this number is, the less the smoothness varies over time. Note that this metric is reported only when there are sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until there are enough frames to produce the metric. jonross@chromium.org mjzhang@chromium.org graphics-dev@chromium.org Tracks the percent of janks for a sequence by aggregating all {Sequence}, where a sequence is a series of frames produced which contain at least one of the aforementioned effects. Jank is measured by tracking the number of abrupt increases in frame presentation interval, divided by the total number of frames expected to be produced and displayed. The lower this number is, the less the smoothness varies over time. Note that this metric is reported only when there are sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until there are enough frames to produce the metric. jonross@chromium.org graphics-dev@chromium.org Tracks the percent of dropped frames for in a 1 second sliding window. PercentDroppedFrames is measured by tracking the number of frames which were not displayed on screen out of the total number of frames expected to be produced and displayed. In other words, the lower this number is, the smoother experience. jonross@chromium.org mjzhang@chromium.org graphics-dev@chromium.org Tracks the maximum staleness value for all presentations for a particular sequence of frames (e.g. during scroll, animation, etc.). This is reported in various sub-metrics with suffixes describing the type of the sequence (e.g. TouchScroll etc.). Typically, a frame presentation is expected to last at least one vsync cycle, plus any number of additional vsync cycles if no updates are expected duration that time. If the presentation interval is prolonged due to reasons other than listed above, then that prolonged portion will be considered staleness for that frame. Note that this metric is reported only when there are sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until there are enough frames to produce the metric. jonross@chromium.org graphics-dev@chromium.org chrome-analysis-team@google.com Tracks the percent of dropped frames for a sequence by aggregating all its animations and interactions, where a sequence is a series of frames produced which contain at least one of the animations/interactions. Such animations and interactions encompass: Compositor-thread animations; Main-thread animations; JS animations; scrolling; and pinch-gestures. PercentDroppedFrames is measured by tracking the number of frames which were not displayed on screen out of the total number of frames expected to be produced and displayed. In other words, the lower this number is, the smoother the experience. Note that this metric is reported only when there are a sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until an additional sequence completes where there are (>= 100) frames available in total. This is a new implementation of the older Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric. See http://shortn/_ItBDdHoyCf (internal only) for more details. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. jonross@chromium.org graphics-dev@chromium.org Tracks the percent of dropped frames for a sequence by aggregating all {Sequence}, where a sequence is a series of frames produced which contain at least one of the aforementioned effects. PercentDroppedFrames is measured by tracking the number of frames which were not displayed on screen out of the total number of frames expected to be produced and displayed. In other words, the lower this number is, the smoother the experience. Note that this metric is reported only when there are a sufficient number of frames (>= 100). If there are sequences with fewer frames, then these are aggregated until an additional sequence completes where there are (>= 100) frames available in total. This is a new implementation of the older Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric. jonross@chromium.org mjzhang@chromium.org graphics-dev@chromium.org Tracks the staleness value for each frame presentation for a particular sequence of frames (e.g. during scroll, animation, etc.). This is reported in various sub-metrics with suffixes describing the type of the sequence (e.g. TouchScroll etc.). Typically, a frame presentation is expected to last at least one vsync cycle, plus any number of additional vsync cycles if no updates are expected duration that time. If the presentation interval is prolonged due to reasons other than listed above, then that prolonged portion will be considered staleness. Note that the reporting of this metric occurs as soon as a frame is presented, and is not affected by the length of the frame sequence.