1145264 - Define as many high-level categories as possible for Timeline rendering

Status: RESOLVED WONTFIX

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Description

[Jordan Santell [:jsantell] [@jsantell]]

TimelineMarkers should have a category property used to determine which "line" of the timeline the marker is rendered at, as well as a color. If we took our current markers, and made groups according to how they're laid out: (ignore my terrible group names)

Graphics -> [PaintCategory]
Scripting -> []
Console -> [Timestamp]

We need to specify a difference between line, and if there should be multiple colors on a line. For example, "DOMEvent" and "Function Call" (these are labels) are both on the same line, and the same color. They can be categorized as "Scripting", as we do not have/need further subcategories yet.

For the top line in the timeline, we'll call "Graphics" for now, have 3 unique markers, with 2 possible colors.
* Layout (purple)
* Recalculate Style (purple)
* Paint (green)

If we categorize the purple markers as just general graphics markers, we can categorize them as just "Graphics", to indicate they're on the first line, and just use that line's default color (purple?). An interesting subcategorization here are the Paint markers, which live on the same line as other Graphics markers, but should be a different color, so Paint markers have category "PaintCategory". Again, ignore my terrible names.

This allows platform developers to just pick ONE category, and it's up to the devtools front end to map that to see if it's a broad category, or a more specific one. As an example with media markers...

Media -> [Audio, Video, WebRTC]

Creating a TimelineMarker, realistically, most of these markers would just be categorized as "Media", with unique labels like "Web Audio Processing" or "Video Element Buffering", but as they're tagged "Media", they're all the same color, which for the most part is ok. If we wanted to add additional subcategories to expose additional colors, developers could categorize the markers as "Audio", which would render the marker in the "Media" timeline as well, just a different color. This approach would work for network requests too, and anything we wanted to render here.

All these categories are just for example. Does this sound like a good way to categorize markers and allow platform devs to only have to pick ONE category, as well as allowing the client to render multiple colors?

What are some categories that we'd like to show and organize?

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

FWIW, Chrome has 4 categories: Loading, Scripting, Rendering and Painting. Loading is on its own (smaller) line with its own color. Scripting, rendering and painting are all on the next line together, each with its own color. Then there is a third line, also with Painting, but only with markers labeled as "Rasterize Paint". Not sure why it gets its own line.

Safari has 3 lines - network, scripting and rendering, each with their own color. There is only one color per line.

IE11 [0] has the main categories (scripting, rendering, styling), plus loading like chrome, as well as image decoding and GC (which we're instrumenting in Bug 1136945). From the view, they use frames view, and I don't have an IE11 machine to test about the lines they use.


[0] https://msdn.microsoft.com/en-us/library/ie/dn255009%28v=vs.85%29.aspx

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

Sticking with the basics, and learning from other implementations:

Rendering -> [Paint]
Scripting -> []
Console -> [Timestamp]

This lets us label high level categories, while defining which 'line' and color each category has. As "Layout" and "Recalculate Style" would be labeled "Rendering", they'd be on the first line, with the color that Rendering uses (purple). Paint markers would have their own category "Paint", and be green, and would also be on the first line.

Going from here, what other categories would we have? What categories can live on the same line?

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

Also, some markers may arrive to the client in two parts -- currently, markers arrive to the client with both a start and end time. For console.time/timeEnd, that means we only know about this once the timeline stops, so the user can't see the flowing line streaming in live in the timeline. This is being worked on for console.time/timeEnd (can't find the bug), but this could appear in other markers as well (HTTP requests?), and should think about categories that contain these "long" double markers, especially if there are markers we have now.

Comment 4

[Tom Tromey :tromey]

(In reply to Jordan Santell [:jsantell] [@jsantell] from comment #3)
> Also, some markers may arrive to the client in two parts -- currently,
> markers arrive to the client with both a start and end time. For
> console.time/timeEnd, that means we only know about this once the timeline
> stops, so the user can't see the flowing line streaming in live in the
> timeline. This is being worked on for console.time/timeEnd (can't find the
> bug),

Bug 1104202.

Comment 5

[Tom Tromey :tromey]

I think categorization should probably be done in javascript, not in platform,
primarily because this seems to be a user-interface decision and so should be
under the control of the UI code.  Also it seems like categories can be derived
from the "name" information.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Tom Tromey :tromey from comment #5)
> I think categorization should probably be done in javascript, not in
> platform,
> primarily because this seems to be a user-interface decision and so should be
> under the control of the UI code.  Also it seems like categories can be
> derived
> from the "name" information.

What we are trying to get here is a way for new markers to be added without us having to modify front end code every time. This is part of making it easy to add new markers to the platform, for platform hackers. Because they don't want to touch our JS (and won't, and therefore we get less visibility into the platform).

We were thinking that if we have (enum category, const char *label) for markers, we can automatically render markers from most categories (and optionally show/hide categories) while still being open ended and easy for a platform hacker to just do stuff like:

    AutoTimelineMarker m(docShell, MARKER_CATEGORY_LAYOUT, "synchronous layout");

And then forget about it.

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

That said, perhaps there is another way?

Comment 8

[Jordan Santell [:jsantell] [@jsantell]]

We've been moving away from this, and like Tom said, should handle this on the client side rather than platform level -- closing for now.