nafisabedin@google.com yfriedman@chromium.org

Android-only. Records the time spent handling Binder IPCs between a GestureScrollBegin and the corresponding GestureScrollEnd event. Recorded when a GestureScrollEnd is received. The underlying mechanism used to determine this relies on undocumented Android APIs, meaning that it may break in the future.

nafisabedin@google.com yfriedman@chromium.org

Android-only. Records the number of Binder IPCs made between a GestureScrollBegin and the corresponding GestureScrollEnd event. Recorded when a GestureScrollEnd is received. The underlying mechanism used to determine this relies on undocumented Android APIs, meaning that it may break in the future.

mustaq@chromium.org nzolghadr@chromium.org

Tracks the number of Android MotionEvents with ACTION_DOWN or ACTION_POINTER_DOWN or ACTION_BUTTON_PRESS for each ToolType (unknown, finger, mouse or stylus). Team: input-dev@chromium.org.

tbuckley@chromium.org

The number of down events received per destination, input and form factor combination. Input is down events generated by mouse/touch/stylus. Form factor is down events generated by clamshell/touchviewLandscape/touchviewPortrait. Destination: Every down event that is targeted to each destination will be counted including those that don't have an effect. For example: Tapping on a disabled button inside the browser frame will be treated as down events on browser window.

mustaq@chromium.org gastonr@microsoft.com gerchiko@microsoft.com input-dev@chromium.org

Records the completion of a drag and drop operation and the surface on which the drag started and the drop occurred. Only drop operations that produced an effect will be recorded. Meaning, only when the result of a drop is kMove, kLink or kCopy will this histogram be fired. A drag can start on the browser, or outside of it, and can end on either the same page, a different page on the same browser or an external surface within the OS. Drags that started and ended outside of the browser are not recorded, even if the drag went over the browser at any point. Currently only recorded in Aura platforms.

mustaq@chromium.org gastonr@microsoft.com gerchiko@microsoft.com input-dev@chromium.org

Records the completion of a drag and drop operation using the enumerated tool as the device for the drag. The tool used for drags is not discernible when the drag is initiated outside of the browser's window, so those drags will be recorded as using the unknown tool.

kuscher@google.com input-dev@chromium.org

The gesture-events recognized and dispatched by the browser gesture recognizer. This replaces Ash.GestureCreated, which did not record events on Android and Windows. Note: this metric was expired from 2020-03-01 to 2023-04-04.

peilinwang@google.com woa-performance-team@google.com

Records the number of compositor frames submitted by browser main between a GestureScrollBegin and the corresponding GestureScrollEnd event. Recorded when a GestureScrollEnd is received.

anandrv@chromium.org clank-performance-team@google.com

The type of gesture that was timed out. A gesture times out when a touch event (e.g., touchstart) is sent to the renderer process, but the renderer takes too long to handle it. When the timeout delay is reached, the browser cancels the touch sequence to ensure the UI remains responsive and logs the gesture event that was dropped.

flackr@chromium.org input-dev@chromium.org

NOTE: this metric was expired from M97 to 2023-03-14. Overshoot distance in pixels between a predicted scroll position and the corresponding interpolated real scroll position that occurred at the frame time. The difference between {ScoreType} and Frame{ScoreType} is the former uses prediction time and the later uses frame time. Team: input-dev@chromium.org.

flackr@chromium.org input-dev@chromium.org

amanvr@google.com jonross@chromium.org flackr@chromium.org input-dev@chromium.org

NOTE: this metric was expired from M97 to 2023-03-14 and from 2024-03-13 to 2024-06-28. Euclidean distance in pixels between two successive variations of {InteractionType} deltas which are the difference between a predicted position and its corresponding interpolated real position that occurred at prediction time. Team: input-dev@chromium.org.

amanvr@google.com jonross@chromium.org flackr@chromium.org input-dev@chromium.org

NOTE: this metric was expired from M97 to 2023-03-14 and from 2024-03-13 to 2024-06-28. Euclidean distance in pixels between two successive variations of {InteractionType} deltas which are the difference between a predicted position and the interpolated real position that occurred at frame time. Team: input-dev@chromium.org.

jonross@chromium.org woa-performance@google.com

A frame is deemed janky if an irregular jump in screen displacement occured in consecutive frames, this metric is the percentage of those janky frames per 64 produced frames and is only emitted if a scroll has 64 frames in a sequence. This metric is used to asses the scrolling prediction performance as the scroll predictor should smooth out those irregular jumps. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY. Example of a slow scroll: https://youtube.com/shorts/K1ZhyjYr0No Example of a fast scroll: https://youtube.com/shorts/dGj6XTD-PYA

jonross@chromium.org woa-performance@google.com

This metric is the ratio between a larger screen displacement divided by a following small screen displacement {ScrollSpeed}. If the larger screen displacement was deemed janky given the predictor performance, and is only emitted if there is {VsyncStatus}. This metric is used to asses the scrolling prediction performance as the scroll predictor should smooth out those irregular jumps. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY.

flackr@chromium.org joenotcharles@google.com input-dev@chromium.org

Time between input event received by OS and sent to Chrome, recorded for each event when it is received by Chrome. Replaced Event.Latency.OS which was calculated incorrectly on Windows. Warning: On Windows, the timestamps of most events come from a clock with a several msec resolution so will have an abnormal distribution even when TimeTicks::IsHighResolution returns true. The exception is touch events which usually come from the high-resolution clock when TimeTicks::IsHighResolution returns true. Note: As of May 29 2024 (M127), the calculation has been updated to be optimistic about the low-frequency clock on Windows (0ms if <= 1x 16ms tick), hence a -16ms shift is expected in the distribution.

flackr@chromium.org gerchiko@microsoft.com input-dev@chromium.org

Measures an average distance that represents how the page sticks to the finger when user scrolls. Only reports touch scrolling. See https://docs.google.com/document/d/154jddNiKtxELBvrjLz9v6A7sA1J3iwQQzySHgtY12Oo/ This is the lag observed in processing the Gesture Scroll Begin Event. In each touch interaction there is a GSB followed by multiple Gesture Scroll Updates, which are separately logged by Event.Latency.ScrollUpdate.Touch.AverageLagPresentation. Note: This histogram was expired from 2022-05-01 to 2023-06-20. Team: input-dev@chromium.org.

flackr@chromium.org gerchiko@microsoft.com input-dev@chromium.org

Measures an average distance that represents how the page sticks to the finger when user scrolls if prediction was disabled. Only reports touch scrolling. See https://docs.google.com/document/d/154jddNiKtxELBvrjLz9v6A7sA1J3iwQQzySHgtY12Oo/ This is the lag observed in processing the Gesture Scroll Begin Event. In each touch interaction there is a GSB followed by multiple Gesture Scroll Updates, which are separately logged by Event.Latency.ScrollUpdate.Touch.AverageLagPresentation. Note: This histogram was expired from 2022-11-23 to 2023-06-20. Team: input-dev@chromium.org.

flackr@chromium.org gerchiko@microsoft.com input-dev@chromium.org

Measures an average distance that represents how the page sticks to the finger when user scrolls. Only reports touch scrolling. See https://docs.google.com/document/d/154jddNiKtxELBvrjLz9v6A7sA1J3iwQQzySHgtY12Oo/ This is the lag observed in processing the Gesture Scroll Updates occurring in the lifetime of a scroll interaction. Note: This histogram was expired from 2022-12-25 to 2023-06-20. Team: input-dev@chromium.org.

flackr@chromium.org gerchiko@microsoft.com input-dev@chromium.org

Measures an average distance that represents how the page sticks to the finger when user scrolls if prediction was disabled. Only reports touch scrolling. See https://docs.google.com/document/d/154jddNiKtxELBvrjLz9v6A7sA1J3iwQQzySHgtY12Oo/ This is the lag observed in processing the Gesture Scroll Updates occurring in the lifetime of a scroll interaction. Note: This histogram was expired from 2022-11-23 to 2023-06-12. Team: input-dev@chromium.org.

flackr@chromium.org gerchiko@microsoft.com input-dev@chromium.org

Percentage of touch lag that prediction wasn't able to remove. This is the ratio (Lag_with_prediction)/(Lag_without_prediction). Lag is the average distance between the finger and page positons during touch scrolling. 0% means all the lag existing before prediction was removed. 100% means that prediction had no impact. Greater than 100% means that prediction introduced more lag. This metric doesn't distinguish between OverPrediction and UnderPrediction. A same absolute value of OverPrediction or UnderPrediction will result in the same RemainingLagPercentage value. Lag_with_prediction = Event.Latency.ScrollUpdate.Touch.AverageLagPresentation Lag_without_prediction = Event.Latency.ScrollUpdate.Touch.AverageLagPresentation.NoPrediction Note: This histogram was expired from 2022-11-23 to 2023-06-20. Team: input-dev@chromium.org.

flackr@chromium.org gerchiko@microsoft.com input-dev@chromium.org

Improvement of prediction in touch lag. It is defined as (Lag_without_prediction - Lag_with_prediction). Lag is the distance between the finger position and the rendered position. When positive, prediction improves touch performance (reduces lag). When negative, prediction worsens touch performance (increases lag). The duration of the interaction/interval is either 1s, or the time from when the user starts scrolling to lifting the finger, whichever is smaller. This metric uses directionless distances, therefore it doesn't distinguish between OverPrediction and UnderPrediction. A same absolute value of OverPrediction or UnderPrediction will result in the same PredictionImpact value. Lag_with_prediction = Event.Latency.ScrollUpdate.Touch.AverageLagPresentation Lag_without_prediction = Event.Latency.ScrollUpdate.Touch.AverageLagPresentation.NoPrediction Note: This histogram was expired from 2022-11-23 to 2023-06-20. Team: input-dev@chromium.org.

mustaq@chromium.org input-dev@chromium.org

The maximum Euclidean distance (in DIPs, device independent pixels) a single-pointer gesture travels from its starting position during the period the gesture has been active. The histogram is measured separately for every pointer type that can be used in gesture recognition: finger, and pen in drawing/eraser mode. The type names used here follow the corresponding labels in |MotionEvent.ToolType|.

kraskevich@google.com woa-performance-team@google.com

Tracks total duration of scrolls for {ScrollInputType} input type.

kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com chrome-analysis-team@google.com

The percentage of frames not presented during a scroll or a fling[1], meaning frame production took longer than expected and the frame was skipped. This metric is different from traditional graphics smoothness metrics as it considers performance degradation on all threads and processes including Browser and IO, unlike graphics' smoothness metrics which focus on the core graphics pipeline (Renderer/GPU). This metric is only recorded when 64 frames are presented, for example if a scroll only has 12 frames, the next scroll has 40 frames and the scroll after has 12 frames, the metric only will be emitted after the 3rd scroll. This means the last incomplete window might not get reported as the browser terminates. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. [1]Fling is a finger boosted scroll, meaning the screen is moving after the user has accelerated their finger on the screen and removed it.

kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

A frame is deemed janky during a scroll if there was no presented frame in the previous vsync, and the current frame contains input that was not presented during the missed frame. Missed input is determined by comparing the timestamp of the earliest input of the current frame, to that of the last input of the previously presented frame. If the delta of the timestamps is less than a vsync + vsync/2, then the input is considered to have been intended for the missed frame. This metric reports the percentage of delayed frames within a scroll. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY

petrcermak@chromium.org kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

NOTE: This 'scroll jank v4 metric' is a new refined version of Event.ScrollJank.DelayedFramesPercentage.FixedWindow. This new metric aims to address the old metric's shortcomings and eventually replace it. The percentage of frames in a window of 64 frames containing (regular and/or inertial[1]) scroll updates which Chrome didn't present on time, meaning frame production took longer than expected and Chrome consequently missed (didn't present any inputs in) a VSync. This metric considers a frame delayed if it violates any of the following three rules: 1. Running consistency: Chrome's input→frame delivery must not slow down to the point that Chrome misses a VSync in which Chrome would have been able to present an input had it maintained consistent input→frame delivery. 2. Fast scroll continuity: There must be no missed VSyncs between consecutive frames containing scroll updates with absolute total raw scroll delta greater than or equal to 3 pixels. 3. Fling continuity: There must be no missed VSyncs during the transition from a regular scroll to a fling UNLESS the regular scroll is slow with absolute total raw scroll delta less than 3 pixels per frame. There must also be no missed VSyncs between consecutive inertial frames EXCEPT towards the end of a fling if the absolute total raw scroll delta drops below 0.2 pixels per frame. This metric is different from traditional graphics smoothness metrics as it considers performance degradation on all threads and processes including Browser and IO, unlike graphics' smoothness metrics which focus on the core graphics pipeline (Renderer/GPU). This metric is only recorded when 64 frames are presented, for example if a scroll only has 12 frames, the next scroll has 40 frames and the scroll after has 12 frames, the metric only will be emitted after the 3rd scroll. This means the last incomplete window might not get reported as the browser terminates. This metric emits zero in the case when no frames were delayed in a window of 64 frames. For more details about this metric, please check https://docs.google.com/document/d/1AaBvTIf8i-c-WTKkjaL4vyhQMkSdynxo3XEiwpofdeA [1] An inertial scroll (aka a fling) is a finger boosted scroll, meaning the screen is moving after the user has accelerated their finger on the screen and removed it.

petrcermak@chromium.org kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

NOTE: This 'scroll jank v4 metric' is a new refined version of Event.ScrollJank.DelayedFramesPercentage.PerScroll. This new metric aims to address the old metric's shortcomings and eventually replace it. The percentage of frames in a (regular and/or inertial[1]) scroll which Chrome didn't present on time, meaning frame production took longer than expected and Chrome consequently missed (didn't present any inputs in) a VSync. This metric considers a frame delayed if it violates any of the following three rules: 1. Running consistency: Chrome's input→frame delivery must not slow down to the point that Chrome misses a VSync in which Chrome would have been able to present an input had it maintained consistent input→frame delivery. 2. Fast scroll continuity: There must be no missed VSyncs between consecutive frames containing scroll updates with absolute total raw scroll delta greater than or equal to 3 pixels. 3. Fling continuity: There must be no missed VSyncs during the transition from a regular scroll to a fling UNLESS the regular scroll is slow with absolute total raw scroll delta less than 3 pixels per frame. There must also be no missed VSyncs between consecutive inertial frames EXCEPT towards the end of a fling if the absolute total raw scroll delta drops below 0.2 pixels per frame. This metric is different from traditional graphics smoothness metrics as it considers performance degradation on all threads and processes including Browser and IO, unlike graphics' smoothness metrics which focus on the core graphics pipeline (Renderer/GPU). This metric emits zero in the case when no frames were delayed in a scroll. For more details about this metric, please check https://docs.google.com/document/d/1AaBvTIf8i-c-WTKkjaL4vyhQMkSdynxo3XEiwpofdeA [1] An inertial scroll (aka a fling) is a finger boosted scroll, meaning the screen is moving after the user has accelerated their finger on the screen and removed it.

oksamyt@google.com woa-performance-team@google.com

Whether an empty gesture scroll update caused a frame to be produced when it is the only input (as a result of resampling).

petrcermak@chromium.org kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

The issues encountered by the scroll-ID-based implementation of `cc::ScrollJankV4FrameStageCalculator` when processing scroll events in a single frame. Only emitted for frames which contain at least one GSU.

kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

A frame is deemed janky during a scroll if there was no presented frame in the previous vsync, and the current frame contains input that was not presented during the missed frame. Missed input is determined by comparing the timestamp of the earliest input of the current frame, to that of the last input of the previously presented frame. If the delta of the timestamps is less than a vsync + vsync/2, then the input is considered to have been intended for the missed frame. This metric counts number of vsyncs the frame was delayed by(which could be zero). The metric gets reported for every frame. Please see Event.ScrollJank.MissedVsyncs* for other related histograms aggregated over a fixed window and emitted once per window. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY

kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

A frame is deemed janky during a scroll if there was no presented frame in the previous vsync, and the current frame contains input that was not presented during the missed frame. Missed input is determined by comparing the timestamp of the earliest input of the current frame, to that of the last input of the previously presented frame. If the delta of the timestamps is less than a vsync + vsync/2, then the input is considered to have been intended for the missed frame. This metric reports the {Operator} in window of size 64. Metric emits zeros as well i.e. the case when no frames were delayed. Please see Event.ScrollJank.MissedVsyncs.PerFrame for unaggregated version of this histogram. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY

kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

A frame is deemed janky during a scroll if there was no presented frame in the previous vsync, and the current frame contains input that was not presented during the missed frame. Missed input is determined by comparing the timestamp of the earliest input of the current frame, to that of the last input of the previously presented frame. If the delta of the timestamps is less than a vsync + vsync/2, then the input is considered to have been intended for the missed frame. This metric reports the {Operator} in scroll. Metric emits zeros as well i.e. the case when no frames were delayed. Please see Event.ScrollJank.MissedVsyncs.PerFrame for unaggregated version of this histogram. For more details about this metric, please check http://doc/1Y0u0Tq5eUZff75nYUzQVw6JxmbZAW9m64pJidmnGWsY

petrcermak@chromium.org kartarsingh@google.com jonross@chromium.org woa-performance-team@google.com

NOTE: This 'scroll jank v4 metric' is a new refined version of Event.ScrollJank.MissedVsyncs{Operator}.FixedWindow. This new metric aims to address the old metric's shortcomings and eventually replace it. The {Operator} over the number of VSyncs in a window of 64 frames containing (regular and/or inertial[1]) scroll updates which Chrome missed (didn't present any inputs in) because it didn't present a frame on time. This metric considers a frame delayed if it violates any of the following three rules: 1. Running consistency: Chrome's input→frame delivery must not slow down to the point that Chrome misses a VSync in which Chrome would have been able to present an input had it maintained consistent input→frame delivery. 2. Fast scroll continuity: There must be no missed VSyncs between consecutive frames containing scroll updates with absolute total raw scroll delta greater than or equal to 3 pixels. 3. Fling continuity: There must be no missed VSyncs during the transition from a regular scroll to a fling UNLESS the regular scroll is slow with absolute total raw scroll delta less than 3 pixels per frame. There must also be no missed VSyncs between consecutive inertial frames EXCEPT towards the end of a fling if the absolute total raw scroll delta drops below 0.2 pixels per frame. This metric is different from traditional graphics smoothness metrics as it considers performance degradation on all threads and processes including Browser and IO, unlike graphics' smoothness metrics which focus on the core graphics pipeline (Renderer/GPU). This metric is only recorded when 64 frames are presented, for example if a scroll only has 12 frames, the next scroll has 40 frames and the scroll after has 12 frames, the metric only will be emitted after the 3rd scroll. This means the last incomplete window might not get reported as the browser terminates. This metric emits zero in the case when no VSyncs were missed in a window of 64 frames. For more details about this metric, please check https://docs.google.com/document/d/1AaBvTIf8i-c-WTKkjaL4vyhQMkSdynxo3XEiwpofdeA [1] An inertial scroll (aka a fling) is a finger boosted scroll, meaning the screen is moving after the user has accelerated their finger on the screen and removed it.

jonross@chromium.org chrome-gpu-metric-alerts@chromium.org chrome-analysis-team@google.com

When a user performs a scroll using touchscreen, a sequence of touch-move events are generated leading to a sequence of gesture-scroll-update events. This metric measures total latency of those gesture-scroll-update events excluding the first one in the sequence and those that are inertial (i.e. generated as a result of a user fling). Total latency means the time from when the touch-move causing a gesture-scroll-update is generated until when the changes caused by the event are successfully presented on the screen. This histogram will eventually be replaced by its TotalLatency2 equivalent which uses an improved bucketing. This histogram only records metrics on machines with high-resolution clocks.