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

Issue metadata

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

Blocked on:
issue 246034

Blocking:
issue 521307



Sign in to add a comment

Expose scroll performance in dev tools somehow

Project Member Reported by rbyers@chromium.org, 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?
 
Owner: caseq@chromium.org
Status: Assigned

Comment 2 by rbyers@chromium.org, 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 rbyers@chromium.org, Aug 18 2015

Blocking: chromium:521307

Comment 4 by rbyers@chromium.org, 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 rbyers@chromium.org, 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 bugdroid1@chromium.org, Nov 23 2015

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/56c76b9d223dd91d7176ec5b9613e3c66321d0de

commit 56c76b9d223dd91d7176ec5b9613e3c66321d0de
Author: caseq <caseq@chromium.org>
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
latency_info_enabled.

BUG= 520659 

Review URL: https://codereview.chromium.org/1462923003

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

[modify] http://crrev.com/56c76b9d223dd91d7176ec5b9613e3c66321d0de/ui/events/latency_info.cc

Cc: tdres...@chromium.org
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 http://output.jsbin.com/wehaxu/quiet, 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 caseq@chromium.org, 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