Counter samples continue until the end of track

[znoffel]

When using counter events ("ph":"C") in Chrome Trace Event JSON Format, the last counter value automatically extends horizontally until the end of the entire trace timeline, even when the measurement has actually stopped. This happens when opening a JSON trace file in Perfetto UI, but not the legacy Chrome viewer. For example:

Our desired behavior is to indicate that measurement has ended, rather than extending the last value indefinitely. Ideally:

• The counter line stops at the last sample timestamp
• Or shows a visual indication that no more data is available
• Or drops to null/undefined to indicate "no data"

Is there a recommended way to terminate a counter track to prevent this extension? We considered the idea of adding a final counter event with value 0 (but this is inaccurate + the line still continues)
@LalitMaganti

[stevegolton]

There is no way to this right now as far as I can see - the counter renderer is fundamentally different. Whatsmore I'm not aware of any way to indicate a 'final' sample in JSON or even the TrackEvent proto.

We could put this behind a flag/setting to the counter track renderer in the UI, but I'm not sure it's a high priority for us.

@LalitMaganti or @primiano will probably be able to provide more information into why this is different between the two trace viewers and whether it's something we would consider adding.

[LalitMaganti]

I was thinking about the problem a bit as well and thought that maybe it might be worth marking the "last counter sample" for all trace types whether JSON or not. I see it as analagous to how we have special handling for "did not complete" slices.

To that end I sent #3367. Here's a summary of the changes:

1. we now have a gradient from the last sample to the right edge of the screen
2. we use a "dashed" line rather than a solid line from the last sample to the right edge of the screen
3. in the details panel, we mark it as -1 duration i.e. "did not complete" instead of zero duration
4. when you hover on the sample, we preserve the dashed line instead of the solid line

Curious to get both your thoughts:

• @znoffel: whether this is an adequate fix for your problem (i.e. is it clear enough that this is the last sample)
• @stevegolton: whether this is an acceptable UI change in your eyes

[stevegolton]

Looks good from my point of view.

[LalitMaganti]

BTW here is a link to the build of the UI on my PR: https://storage.googleapis.com/perfetto-ci-artifacts/gh-18713756683-ui/ui/index.html

Here's a screenshot of how it looks:

[LalitMaganti]

@znoffel friendly ping on this!

[znoffel]

Hey all, thanks for the suggestions. Although I don't quite get what is the purpose of the gradient and dashed line? Even if the color tapers off until the end, the line still shows an inaccurate non-zero value, which doesn't help our case much. Why not support null terminating the track so the line doesn't continue until the end like in the legacy chrome viewer? Since we have multiple counter tracks that track different events in series, the tracks are separate but fall under a single overall timeline, making it confusing when lines from different counter tracks overlap but in reality their respective events do not overlap. It is an interesting feature though, and it definitely one way around the problem, but for our specific case it may be best to just to zero out the line for visual consistency for now.

[LalitMaganti]

Although I don't quite get what is the purpose of the gradient and dashed line?

The gradient and dashed line indicate that this is the last sample and there is no data beyond this point. This is consistent with how slices themselves are marked as "incomplete" and there's a gradient there for last slice.

Why not support null terminating the track so the line doesn't continue until the end like in the legacy chrome viewer?

Unfortunately, because it's not necessarily the right thing to do in all situations

Let me give you an example: let's say I'm measuring the memory of the process and I'm getting "push" events (i.e. updates when a processes memory changes). Basically every time I get an event, that means the memory is at that value until the next event.

It's inaccurate to just "terminate" the counter at the last sample: we actually know the memory of the process has not change until the end of the trace. So terminating would be misleading for these usecases. And I say argue this is much more common usage of counters in Perfetto.

So really I would say there is two modes of the counter:

1. The counter value is actually the last sample for real and should not be shown beyond that point
2. The counter value is just the last sample which happened to be captured but was not actually the last sample.

If you were emitting the proto format, I could easily add something to let you disambiguate between these two cases. But with the JSON format, it's essentially a format which we don't really control and we ideally want to make custom changes to it.

Open to other suggestions which are amenable to supporting both of these usecases with a priority given to case 2)