New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 520659 link

Starred by 5 users

Issue metadata

Status: Archived
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 246034

issue 521307

Sign in to add a comment

Expose scroll performance in dev tools somehow

Project Member Reported by, Aug 13 2015

Issue description

I know there's been some thinking on this, but I don't see a specific bug.  We really need to figure out how to expose input latency in dev tools.  

Here's a crack at the minimal specific things I think a web developer should be able to see in the timeline:
 - Regions of the timeline where a scroll is occuring
 - Time between when the user actually started a scroll (hardware timestamp), and when it took effect visually
 - What was going on in between that time and why (eg. were we blocked on the main thread due to a touch or wheel handler?)
Latency of other things (touch scroll updates, taps, etc.) are also valuable but less important IMHO.  The developer generally can't do much to influence the latency of touch scroll updates (that never blocks on JS), and the latency of tap/mousedown etc. is much less of an issue today.

All the data is present for this in miletus@'s LatencyInfo data that's exposed to tracing.  Maybe there's something minimal we can do to get the very basics into devtools UI?
Status: Assigned

Comment 2 by, Aug 18 2015

Related: we're probably going to try to better expose some forms of input latency to JavaScript:  issue 521307 

Comment 3 by, Aug 18 2015

Blocking: chromium:521307

Comment 4 by, Aug 18 2015

Blockedon: chromium:246034
Note that this should probably be based on our internal LatencyInfo tracking system -  issue 246034 
Labels: Cr-Platform-DevTools

Comment 6 by, Oct 15 2015

Summary: Expose scroll performance in dev tools somehow (was: Expose input latency in dev tools somehow)
Let's focus this on scroll performance for now (since that's the top priority, and very different from general input latency).  Issue 543598 tracks the PerformanceTimeline API we're working on for this.
Project Member

Comment 7 by, Nov 23 2015

The following revision refers to this bug:

commit 56c76b9d223dd91d7176ec5b9613e3c66321d0de
Author: caseq <>
Date: Mon Nov 23 20:24:40 2015

LatencyInfo: enable async event reporting for both latencyInfo and benchmark categories

This fixes initializer for benchmark_enabled to actually check for both benchmark and
latencyInfo to match the categories actually used in trace events and renames it to

BUG= 520659 

Review URL:

Cr-Commit-Position: refs/heads/master@{#361172}


Any update on this?
Should I file a separate bug for the interaction with the touch ack timeout, or should we consider that part of this bug?

To repro, load, and start a scroll right as the spinning Chrome logo stops rotating.
If the displayed queuing time is greater than 1 second, we don't show a red underline.

Comment 10 by, May 17 2016

Tim, I must be doing something wrong, but here's what I'm getting.

Screenshot from 2016-05-16 17:21:37.png
90.8 KB View Download
Sorry, I forgot to mention the touch ack timeout only exists on mobile.
Status: Archived (was: Assigned)
Bulk DevTools triage, closing low priority issues with no action plan.

Sign in to add a comment