From [email protected] on August 02, 2011 14:00:12

After a run of trace_events, there may be hundreds of events and finding the ones you are interested in can be difficult. This issue will only increase as the feature gains popularity.

By displaying a tree of categories and events and allowing it to be used as a filter, only the events that a user is interested in need be displayed.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=3

From [email protected] on June 05, 2012 13:13:11

The createSummaryElementForSelection uses a variety of appendXXX methods. These methods construct elements and return them which is awesome but it makes it hard to test the analysis code.

We should create a class

SummaryBuilder {
}
SummaryBuilder.prototype = {
// all the append methods
}

And modify createSummaryElementForSelection to take a SummaryBuilder instance as one of its arguments.

This way, when we want to test code, e.g. the averaging code, we can pass in a mock version of this interface instead.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=23

From [email protected] on June 09, 2012 02:48:39

We should not allow linty code to get committed.

Copy chrome:src/chrome/browser/resources/PRESUBMIT.py into this repo.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=35

From [email protected] on July 26, 2011 10:36:36

Select some events, then click a button that hides all other events that don't match the set of selected names. This helps when you find the event, but not the exact one you're looking for.

This could be done in a more generic way, with a text field to search for events and filter in/out etc.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=26

From [email protected] on June 09, 2012 02:39:57

There's good changes made to linux_perf_importer as part of systrace that we should get upstreamed.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=31

From [email protected] on June 13, 2012 15:15:16

It's a bit difficult to test the output code in timeline_analysis.js. Refactor it to be more testable.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=38

From [email protected] on June 13, 2012 11:43:24

The trace format changed in 3.4; need to update the linux importer to handle it.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=37

From [email protected] on June 16, 2012 02:46:04

We shouldn't add the *Totals row when we've got just one result. It doesn't provide useful information.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=41

From [email protected] on May 31, 2012 11:09:04

I opened up tracing and it was hard to find the help button.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=17

From [email protected] on June 05, 2012 00:16:51

The SliceTracks's setter should go through each of its slices and verify that the starts and end times are monotonically increasing. The fastRectRenderer fails if that assumption is not held.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=22

From [email protected] on May 24, 2012 16:44:15

Once we have parsed async slices, we currently always add them to the thread's async slice group.

When we see slices that start and end on a thread, we should still do this.

For slices that start on one thread and end on another, we should instead draw arrows between threads.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=15

From [email protected] on May 31, 2012 13:06:19

timeline analysis should be expandable

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=18

From [email protected] on June 09, 2012 02:46:05

Right now, when you hide a track, it comes right back when you load another file. We should try to persist these hiding actions, when possible.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=33

From [email protected] on June 09, 2012 02:35:18

linux_perf_importer has grown a bit organically. Lets get it cleaned up to be a bit more maintainable.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=29

From [email protected] on May 31, 2012 15:05:20

ruler should stay in view when threads are scrolled

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=21

From [email protected] on June 09, 2012 02:46:05

Right now, when you hide a track, it comes right back when you load another file. We should try to persist these hiding actions, when possible.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=34

From [email protected] on June 22, 2012 16:22:40

We should add a B-E style parser

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=50

From [email protected] on September 29, 2011 14:27:11

Show the trace event category for events in about:tracing

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=6

From [email protected] on August 02, 2011 14:15:38

As well as the graphical view, it would be useful to have a summary of each event in the capture including at least the following:

• Number of instances.
• Total duration (and hence average duration).
• Min and max duration and instances.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=5

From [email protected] on May 06, 2011 14:14:23

Certain events need to stand out in the UI more than others. It would be helpful to be able to specify that to the trace macro somehow.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=2

From [email protected] on June 22, 2012 12:20:48

This is especially a problem on OSs that have poor-granularity timers (such as 1ms as shown in the attached trace).

In the attached trace, zoom into the end of the GLContext::SwapBuffers event at 5852.000 ms (in the CrGpuMain thread).

As you zoom in, notice that some 0-duration events alternate between vertical lines and triangles (that's one bug).

If you select a vertical box around the end of the GLContext::SwapBuffers, you'll see in the selection summary lots of interesting events that got lost because they are 0-duration (28 total events - 8 visible events == ~20 0-duration events).

We could start by making them render more consistently as instant events (always triangles).

Attachment: cloud_party_chrome21_stalls_2.zip

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=48

From [email protected] on May 16, 2012 15:55:52

E.g. finding 5110.937 should pan the timeline view to 5110.937 and put a line there or something.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=10

From [email protected] on June 09, 2012 02:36:24

We currently have to hand-specify each and every .js file that we need when using tracing. This is cumbersome and discourages adding new files to the project. We can do better.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=30

From [email protected] on February 03, 2012 18:07:39

What steps will reproduce the problem? 1. Open about:tracing
2. Start / stop trace
3. Click any event
4. Double click name of event. What is the expected output? What do you see instead? Expected: Name is selected, nothing else happens. Instead, the name is selected and the UI executes a zoom in.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=28

From [email protected] on May 31, 2012 15:02:35

1. Open about:tracing.
2. Focus the search box in the upper right.
3. Press the "r" key (or any keyboard shortcut). Notice that the shortcut action is performed (in this case record). Instead I expect to just enter an "r" in the search box.

The search box looks like it could use some love in general. At one point I couldn't focus it at all (not sure of repro steps). It can also be tricky to see the number of results in the background or to navigate the results when they exist.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=20

From [email protected] on May 31, 2012 11:07:10

Open up help in about:tracing
It's unclear how to exit

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=16

From [email protected] on April 25, 2012 14:50:31

How about an option to show the event args in the selection summary? It's often tedious to narrow the selection to only one event in order to see its args.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=9

From [email protected] on June 21, 2012 14:24:41

Slices:
*Totals 0.507 ms 4 occurences

Selection start 0.042 ms
Selection extent 0.4 ms

Only totals show up and you cannot see the details of each different event selected.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=47

From [email protected] on June 13, 2012 15:17:06

Add more unit tests to timeline_analysis.js for various selections. For example, multiple counter events, counter events and normal events, etc.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=39

From [email protected] on June 14, 2012 00:41:38

TimelineView is currently the "base class" of all our UI, holding a Timeline and TimelineAnalysis. But, then we have this Timeline, which is actually the widget that shows the tracks. We should probably clean this up, such that Timeline is the base UI component. TBD what to do with the current code called Timeline. Maybe rename that to TimelineTracksView.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=40

From [email protected] on June 16, 2012 22:52:25

unittest.assertArrayEquals currently does a shallow test

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=44

From [email protected] on June 16, 2012 22:20:21

The statement
throw 'someError'
does not capture a stack trace.

Whereas:
throw new Error('someError')
Does.

We should change to using error objects.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=42

From [email protected] on May 31, 2012 13:46:27

At the risk of opening pandora's box, I'd like some way of using dvorak with about:tracing. One way would be to just map those keys in addition to the normal wasd. Here's the dvorak keys that map to wasd:

, up
a left
o down
e right

Note that 'a' is the same. 'e' is already used. It seems to go left more than 'a' does. Not sure why or if this is required. If it's rarely used, maybe we can just dump it.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=19

From [email protected] on May 20, 2012 13:38:11

1. Record a trace
2. Shrink the window so that the timeline is taller than the window and scrollbars appear
3. Press the 'x' on one of the tracks

Expected result: the track closes and the 'X' for the track below the one that was deleted is under the mouse cursor

What actually happens: the track closes but the scroll view pops up to the top. The mouse cursor is over a random track.

Use case: often, you want to hide many tracks at once, by just clicking the 'x' over and over again. Because scroll jumps, this is not possible.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=11

From [email protected] on April 25, 2012 14:28:16

Currently the processes and threads are ordered by pid/tid in about:tracing, but this can change each time chrome starts. Ideally, we would always list threads in creation/ownership order, such as:

browser
renderer
renderer
...
gpu

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=8

From [email protected] on June 19, 2012 00:38:50

Some trace formats contain metadata. Stuff like "what OS was this from," etc. About:tracing has this.

We shoudl:

1. modify trace_event_importer to store this metadata on a TimelineModel.metadata array.
2. modify timeline_view to have a button that shows this metadata, based on the design of the parse error button/dialog

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=45

From [email protected] on May 22, 2012 01:37:51

linux_perf_importer does not handle sched_wakeups. This causes us to report threads as sleeping longer than they should be.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=12

From [email protected] on June 11, 2012 09:09:20

"W, A, S, D keys are specific for qwerty keyboards. It is quite hard to manipulate with different keyboard layouts from other countries. It would be nice if you could support the arrows keys." - Jerome Etienne http://www.html5rocks.com/en/tutorials/games/abouttracing/

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=36

From [email protected] on June 24, 2012 16:55:03

The changes in http://codereview.appspot.com/6326047 are good but they are untested.

Please add tests. Especially for the regex working in the case where the recording is >5s

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=51

From [email protected] on August 02, 2011 14:08:35

A long trace might benefit from being split into logical frames. This requires a special event or function to be designated the 'end of frame'. The UI can then allow paging between frames which will make the trace much easier to navigate.

This doesn't make sense for all processes and some events may span frame boundaries, but that shouldn't be an issue as the underlying data should be stored the same and just presented as multiple frames.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=4

From [email protected] on April 25, 2012 14:28:16

Currently the processes and threads are ordered by pid/tid in about:tracing, but this can change each time chrome starts. Ideally, we would always list threads in creation/ownership order, such as:

browser
renderer
renderer
...
gpu

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=7

From [email protected] on May 22, 2012 01:37:51

linux_perf_importer does not handle sched_wakeups. This causes us to report threads as sleeping longer than they should be.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=13

From [email protected] on July 26, 2011 10:18:01

Quite often, a selection contains only a few items, and it's difficult to zoom in far enough to narrow down the selection to one item. Yet, we still want to see the argument values of one of the selected trace items.

In the selection summary, one option is to allow the user to click a down arrow next to a selected item to see all instances of it and their argument values in drop down (or just expanded) list.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=25

From [email protected] on August 02, 2011 13:47:27

Clicking and dragging in the page should scroll around.
Mouse wheel should zoom when a modifier is present (shift?).
Double-click should zoom to a block.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=1

From [email protected] on June 16, 2012 22:21:46

When trace-viewer was in the chrome repo, we picked up presubmit checks for both javascript and css lint. We should try to bring those back online.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=43

From [email protected] on May 24, 2012 16:40:17

When there are import errors, we should show a little red (!) icon somewhere in the tracing button bar that when clicked will show the import errors.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=14

From [email protected] on June 09, 2012 02:43:08

TimelineViewport assumes the display refreshes at 60hz.

On most platforms, the trace contains information about the real refresh rate. We should find that information and adjust the grid frequency accordingly.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=32

From [email protected] on June 19, 2012 14:04:50

It would be great to support analysis of selections with >1 counter.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=46

From [email protected] on June 06, 2012 10:32:42

1. record a trace.
2. click a slice.

'Selected item' text area is viewable but not selectable, so you can't copy/paste. At some point selecting was allowed, IIRC.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=24

From [email protected] on June 22, 2012 13:59:34

When multiple events are selected, it should be possible to narrow down the selection by interacting only with the selection summary, because the individual events are sometimes difficult/impossible to select in the
tracing view.

Selection Summary View:

• Turn each event item in selection summary into a link. This link opens the "Common Events List View"

Common Events List View:

• This is a table with all the events of that clicked type (a subset of the original selection) and their argument values.
• Before the table, show the statistics for the selected events.
• Argument values should be displayed to the right of each event, on one line.

Original issue: http://code.google.com/p/trace-viewer/issues/detail?id=49