Support visualization of incremental builds

[randomascii]

In many cases it is more important to optimize incremental builds rather than full rebuilds, and ninjatracing doesn't support visualizing incremental builds in a useful way, since it appears that the timestamps in the .ninja_log file are relative to when ninja started running, so multiple ninja invocations lead to an untangleable mess.

ninjatracing could handle this reasonably well by recognizing when the completion times in the .ninja_log file run backwards. This always indicates a new build so it would be easy to generate a .json file for the last (incremental) build. I could argue that this should even be the default behavior, with an override to specify build n-1, n-2, etc.

The heuristic is not perfect because it is possible for completion times from two adjacent builds to be non-overlapping, but this should be rare.

I have a test implementation. I can make a PR if this is of interest.

[nico]

Sure, patches accepted.

[randomascii]

The implementation I'm using right now is simple and works nicely but doesn't have an option to display all build results overlaid. This also makes multi-file support meaningless.

I'm not sure when multiple input files are used.

I'm thinking of adding a command-line option to select between three options:

1. Displaying all build data overlaid as is currently done.
2. Displaying just the last build.
3. Perhaps displaying subsequent builds with a few seconds of blank space between them - although this might require more effort than I feel like.

My tendency would be to make displaying just the last build be the default since I have never found the full overlay of all build results useful. Thoughts?

[randomascii]

I'm finding it useful to display results from the last 'n' incremental builds, separated by a small gap. I'll try to work up another PR to add that as an option.

[Trass3r]

This would indeed be more useful than the current --showall behavior.

[Trass3r]

This is a start.

[Zitrax]

I have a similar issue in a bigger system which use multiple parallel ninja instances (which might depend on each other). All the individual ninja processes will appear to have started at time 0 which is not correct.

But I guess there is no way to find the absolute start time for each .ninja_log file so I could offset each of them properly?

[mateuszzz88]

I like @Trass3r approach and will use it. I wanted to make it even better by moving previous builds into past (negative "ts") and latest build starts at 0. But tracing viewer adjusts epoch so that whatever I do oldest build starts at zero.