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

Issue 247786 link

Starred by 6 users

Issue metadata

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

Sign in to add a comment

DevTools: Timeline summary tooltip

Project Member Reported by, Jun 7 2013

Issue description

The Timeline gives a great view at the event level but it's often hard to find the bottleneck.

This leads to developers needing to hunt through hundreds of records to identify patterns, long bars, and visually pick out their bottlenecks from mentally aggregate. With this new tooltip, we can quickly zero in on what is the given primary bottleneck for the selected range of time. 

The timeline summary view gives a treeview summary of all active operations recorded within a given time range, totaled up within their respective groups. See attached mock.

 - Tooltip is updated live as user makes selection within the timeline minimap. 
 - Tooltip position is pinned to where the selection began.
 - If user later hovers over their selection, tooltip appears again.
 - While it looks like an interactive treeview, it's within a tooltip and is not meant to be interactive.
 - All active event types are shown in summary view.

51.5 KB View Download
Mock in situ attached.
396 KB View Download
One of the hardest things to show is what subsystem or group of operations is bottlenecking the experience. just made the rounds today, claiming that JS performance is what's slowing down the mobile web. (While I agree JS perf would tank a photo editing mobile web app, it's not where most webapps are dragging).

Having this summary view really puts into context where your problems are, before you dig into the sequence of events, bit by bit. And it provides great illumination into what operations hamper PLT as well as runtime perf.

Andrey, do you have any feedback on the proposal as it stands?

One open question I have is.. should the bars be interactive? Hypothetically when you click on one of them, it could filter the timeline results for all "Layout" results to only show those.  
 Issue 224808  has been merged into this issue.

Comment 6 by, Dec 9 2013

Status: Fixed
Status: Assigned
I think we want to reopen this guy.

Feedback indicates the given pie chart isn't very useful, but we still want some summary of the activity. I think the problem is two-fold: we're lacking granularity, and the pie chart is not communicating effectively [1]

This came up at EdgeConf. A lot of confusion around what parts of the rendering pipeline are costly. Relatedly a similar feature is was proposed for tracing, so lets just do it right here.

The difference between cost in "Update Layer Tree" and "Style Recalc" has implications. Same with "Compositing Layers" and "Paint". 

I think it's worth trying to do a more detailed breakdown like the original mock [2]

I think moving away from pie chart will also make our representation of idle time better. Currently its presence detracts from the value of the pie chart's visualization. In most recordings it consumes much of the pie. But I think moving to this sort of treeview bar chart, we could toss it to the bottom and hopefully it stays out of the way.


Comment 9 by, Sep 23 2014

Did we discard a brushing idiom for consideration here?

In tracing we factor this as "what-you-brush" drives a selection.

Then, there is a widget that does analysis of the selection. That widget could looks like the thing in the pie chart, or the table view we do in tracing, or whatever.

I think this is a model worth considering...

Comment 10 by, Sep 24 2014

Personally, I'd love to see this. I've never really understood why the pie chart got added in it's current form, I find it to take a lot of precious screen real estate (especially height is a scarce thing these days) without it really being informative or helpful. In fact, I tend to ignore it.

The mock up in here seems a lot more useful, because it is easier to mentally process (for me anyway) and gives more details.

(honestly, I feel like the Timeline version shown in the mockup in comment #1 was much better in almost every way than the current version, it felt more stable and easier to use. But maybe that is just nostalgy, as well as the webpage I work on being simpler back then)
We need new mocks that would be aligned with the timeline v2 (tracing mode and new UI). Getting the details for the range (tracing style) is definitely worth considering.
Not sure if this is a good fit for this particular bug, but I was expecting to see a tooltip when hovering over elements in the Timeline's flame char view: the elements tend to be small, labels are truncated. One has to either zoom in and out, or select each element in turn to find something of interest (e.g. quickly narrow down on a common culprit among different non RAIL-frames).

Sometimes elements are very close to each other so a Tooltip view to provide an overview of nearby elements, like above, or elements within a selection (i.e. Nat's suggestion) might work better.

Comment 14 by, Dec 18 2015

Need new mocks or perhaps we're fine with the current implementation.
Status: Archived (was: Assigned)
Bulk DevTools triage, closing low priority issues with no action plan.

Sign in to add a comment