kevers@chromium.org animations-dev@chromium.org Tally failures resulting from missing a map entry from element id to property node. thiabaud@google.com jonross@chromium.org Records the reason(s) for which we triggered a BeginMainFrame{FrameType}. Recorded when the BeginMainFrame is run{Suffix}. The value recorded is a bitset of the enum |BeginMainFrameReason|, with all the reasons the current BeginMainFrame was triggered. lizeb@chromium.org jonross@chromium.org Records the outcome of BeginMainFrame, at a subsampled rate. This is intended to understand the fraction of main frame updates that are aborted. lizeb@chromium.org jonross@chromium.org Records the duration of BeginMainFrame, at a subsampled rate. This is intended to understand the cost of a BeginMainFrame on the critical path. Only reported for platforms supporting high resolution clocks. lizeb@chromium.org jonross@chromium.org Records the duration of BeginMainFrame, at a subsampled rate. This is intended to understand the cost of a BeginMainFrame on the critical path. This version is recorded if the result was FinishedNoUpdates. Only reported for platforms supporting high resolution clocks. acondor@chromium.org clank-performance-team@google.com Records the duration of LayerTreeImpl::BeginFrame on cc/slim, when the frame is produced. Subsampled to 1/100. Only reported on systems which have high resolution timers. 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. jonross@chromium.org kylechar@chromium.org chrome-gpu-metric-alerts@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. 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} Note: this metric was expired from 2023-01-31 to 2023-12-20. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org Records update type to the drawn rect for every draw to each non root renderpass. 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 jonross@chromium.org chrome-gpu-metric-alerts@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 and 2024-03-16 to 2025-06-24. vasilyt@chromium.org jonross@chromium.org chrome-gpu-metric-alerts@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 jonross@chromium.org chrome-gpu-metric-alerts@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 jonross@chromium.org chrome-gpu-metric-alerts@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. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org Whether a render pass drawn rect matches the expected output rect. Record for each non-root render pass every time it is drawn. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org Record every frame the sum of all rendered pixels from all render passes. The buckets are {FocusType} zoraiznaeem@chromium.org chrome-gpu-metric-alerts@chromium.org The average overdraw of the aggregated compositor frame. It is logged once per frame. Overdraw is expected to range is [1.0, 12.0]. An overdraw of 2.0 means that on average each pixel of the display is drawn twice. Note: The overdraw value is logged as `overdraw * 100,000`. 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. vmiura@chromium.org jonross@chromium.org chrome-gpu-metric-alerts@chromium.org This is logged once per frame, when the frame is drawn. The total number of quads in all render passes in the CompositorFrame that is produced by surface aggregation. Histogram was previously expired from 2019-06 to 2024-03. lehoangquyen@chromium.org chrome-gpu-metric-alerts@chromium.org This is logged once per frame, if the output surface provides timing information and overlays are used. It measures the time from the display compositor starting a draw on the Viz Compositor thread to when the GPU thread starts scheduling overlays. Only reported for platforms supporting high resolution clocks. jonross@chromium.org chrome-gpu-metric-alerts@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. magchen@chromium.org chrome-gpu-metric-alerts@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 when the Viz thread scheduled work to the GPU thread. Only reported for platforms supporting high resolution clocks. jonross@chromium.org chrome-gpu-metric-alerts@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. magchen@chromium.org chrome-gpu-metric-alerts@chromium.org This is logged once per frame, if the output surface provides timing information and overlays are used. It measures the time between the GPU thread starting a draw and the GPU thread starting scheduling overlays. Only reported for platforms supporting high resolution clocks. harthuang@google.com fangzhoug@chromium.org jonross@chromium.org chromeos-gfx-compositor@chromium.org This is logged every time a valid HardwareCapabilites is received DRM thread when display configuration may have changed. It records the number of overlay planes we have available on this device including the primary plane. Note: this metric was expired and removed on 2024-06-17 and re-enabled on 2025-01-09. zoraiznaeem@chromium.org chromeos-gfx-compositor@chromium.org Logged once per frame during display composition. Records the number of overlay candidates {Counted}. Hardware overlays allow surfaces (such as videos, web contents, or UI elements) to be sent directly to dedicated display controller hardware planes for scanout, bypassing GPU compositing. During frame processing, the display compositor evaluates potential visual elements (candidates) to determine if they can be promoted to hardware overlays using either single-overlay or multi-overlay strategies, testing them against hardware display controller capabilities. Note: These metrics are used in ChromeOS for performance tracking and in Tast tests. magchen@chromium.org chrome-gpu-metric-alerts@chromium.org This is logged once per frame, if the output surface provides timing information. It measures the time between the GPU main thread initiating overlay scheduling and the start of all related draw call issuances to the driver. Only reported for clients with high-resolution clocks. magchen@chromium.org chrome-gpu-metric-alerts@chromium.org This is logged once per frame, if the output surface provides timing information. It measures the time between the GPU main thread initiating draw call issuances to the driver and their final completion. Only reported for clients with high-resolution clocks. vasilyt@chromium.org chrome-gpu-metric-alerts@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. Note: this metric was expired from 2022-12-18 to 2023-11-17 and 2024-10-20 to 2025-01-07. vasilyt@chromium.org chrome-gpu-metric-alerts@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. Note: this metric was expired from 2023-08-27 to 2023-11-17. vasilyt@chromium.org chrome-gpu-metric-alerts@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. Note: this metric was expired from 2022-12-18 to 2023-11-17. ccameron@chromium.org chrome-gpu-metric-alerts@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. vmpstr@chromium.org rendering-core-dev@chromium.org Reported when the safety-valve timer fires after pause rendering until visibility change times out. This indicates that the expected visibility change never occurred and rendering was unpaused by the safety valve. lizeb@chromium.org chrome-gpu-memory@google.com The maximum memory usage of the ResourcePool during its lifetime. Recorded when the ResourcePool is destroyed. lizeb@chromium.org chrome-gpu-memory@google.com The maximum memory usage of the ResourcePool during its lifetime, reported only when it is not 0. Recorded when the ResourcePool is destroyed. lizeb@chromium.org chrome-gpu-memory@google.com The maximum number of resources in the ResourcePool during its lifetime. Recorded when the ResourcePool is destroyed. lizeb@chromium.org jonross@chromium.org Report the scheduler deadline mode when it changes, which may be multiple times (but at least once per frame). This histogram is subsampled. lizeb@chromium.org jonross@chromium.org Report whether a compositor frame is run in a context where high framerate is requested. This is intended to assess the fraction of cases where this is hit, and also to diagnose over-triggering, since this is expected to be a relatively niche use case. Recorded when a compositor frame is started, at a subsampled rate. hitawala@chromium.org chrome-gpu-metric-alerts@chromium.org Reports how the edges of a DrawQuad's source rect are sampled over SkiaRenderer. This is done on a per DrawQuad basis and recorded through SrcRectConstraintUMA which corresponds to SkCanvas::SrcRectConstraint. Recorded at a subsampled rate (1/100) for Tile, Texture or AggregatedRenderPass DrawQuads per frame. acondor@chromium.org clank-performance-team@google.com Records the outcome of a LayerTreeImpl::BeginFrame call in cc/slim. This is used to compare the number of times a frame is produced versus the number of times the call exits early because no draw was needed. Recorded every 100th call. kylechar@chromium.org chrome-gpu-metric-alerts@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. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org Record the number of excess pixels for the output rect that would not be visible due to the parent root clip. This is logged once per frame. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org Record the damage type for an aggregate render pass based on clipping by the root. This is logged once per frame. lizeb@chromium.org chrome-gpu-memory@google.com When memory is assigned to tiles, whether there was enough memory for all required tiles. This is collected when assigning memory for {ProcessType} process only. 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. This is collected when assigning memory for {ProcessType} process only. lizeb@chromium.org chrome-gpu-memory@google.com When memory is assigned to tiles, whether it succeeded or not, the current total memory usage in MB. This is collected when assigning memory for {ProcessType} process only. lizeb@chromium.org chrome-gpu-metric-alerts@chromium.org Total duration (in us) for all raster tasks to execute. Recorded when raster tasks are scheduled, at a downsampled rate. Only reported for platforms supporting high resolution clocks. vmiura@chromium.org jonross@chromium.org chrome-gpu-metric-alerts@chromium.org The total number of quads in all render passes in a CompositorFrame. This is logged as the CompositorFrame is submitted to its surface. Histogram was previously expired from 2019-06 to 2024-03. jonross@chromium.org chrome-gpu-metric-alerts@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 chrome-gpu-metric-alerts@chromium.org Tracks the duration of various stages in the pipeline as a single frame goes through the various stages in the compositor. This metric uses base::Histogram::FactoryMicrosecondsTimeGet so only users with high resolution clocks will report this metric. zoraiznaeem@chromium.org cros-sw-perf@google.com chrome-gpu-metric-alerts@chromium.org Tracks the total invalidated area (i.e repainted area) per frame. It is normalized by a frame's output size. Frames with zero invalidated area are not reported in the histogram. The paint metric is only tracked for nat UI compositor, meaning that invalidated area of renderers are not taken into account. Note: the metric is logged as `invalidated_area * 100,000`. wangxianzhu@chromium.org chrome-gpu-metric-alerts@chromium.org Tracks the percent of checkerboarded frames that contain any not fully rastered visible tiles, 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. wangxianzhu@chromium.org chrome-gpu-metric-alerts@chromium.org Tracks the percent of checkerboarded frames that contain any not fully recorded visible tiles, 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 chrome-gpu-metric-alerts@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 chrome-gpu-metric-alerts@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 chrome-gpu-metric-alerts@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 chrome-gpu-metric-alerts@chromium.org Tracks the percent of janks 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. 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 chrome-gpu-metric-alerts@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 mjzhang@chromium.org chrome-gpu-metric-alerts@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 chrome-gpu-metric-alerts@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. While this is reported in WebView, it is not accurate on this platform, please ignore. 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 chrome-gpu-metric-alerts@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. While this is reported in WebView, it is not accurate on this platform, please ignore. This is a new implementation of the older Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric. kawasin@google.com baseos-perf@google.com 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 metric is only recorded for 1 minute after the device is resumed. This is supported by ChromeOS only. jonross@chromium.org chrome-gpu-metric-alerts@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. While this is reported in WebView, it is not accurate on this platform, please ignore. This is a new implementation of the older Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric. jonross@chromium.org gaiko@chromium.org chrome-gpu-metric-alerts@chromium.org 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. The V4 metic differs from it's V3 counterpart in that it accounts for frames dropped during compositor thread invalidation. 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 gaiko@chromium.org chrome-gpu-metric-alerts@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. The V4 metic differs from it's V3 counterpart in that it accounts for frames dropped during compositor thread invalidation. 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. While this is reported in WebView, it is not accurate on this platform, please ignore. This is a new implementation of the older Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric. jonross@chromium.org gaiko@chromium.org chrome-gpu-metric-alerts@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. The V4 metic differs from it's V3 counterpart in that it accounts for frames dropped during compositor thread invalidation. 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. While this is reported in WebView, it is not accurate on this platform, please ignore. This is a new implementation of the older Graphics.Smoothness.PercentDroppedFrames.AllInteractions metric. It also replaces the Graphics.Smoothness.PercentDroppedFrames3.{Thread}{Sequence} metric.