sdk example_custom_data_source does not load

[godmar]

I'm following the example and obtained a file example_custom_data_source.pftrace

I went to https://ui.perfetto.dev and loaded the file.
I'm seeing this:

I was hoping to at least find the one event in the trace, the one that says "hello world".

Is this example still up to date (it's from 2 years ago). Are there examples that show me how to add custom event (with my own time stamps) to a trace?

[ddiproietto]

Yes, the example is up to date :-), but it just shows how to emit arbitrary proto data when you're building a custom data source.

When you're implementing a custom data source, you can emit any custom proto format, but you also have to teach trace_processor/UI to parse and show your custom events.

From https://perfetto.dev/docs/instrumentation/tracing-sdk#custom-data-sources-vs-track-events

Unlike track events, when working with custom data sources, you will also need corresponding changes in trace processor to enable importing your data format.

The alternative, as mentioned in the doc above is to use the track_event data source, with the TRACE_EVENT_* macros. You can specify custom timestamps as arguments of the macro. Other examples [here] (https://cs.android.com/android/platform/superproject/main/+/main:external/perfetto/src/tracing/test/api_integrationtest.cc;l=2241-2242;drc=d8fd1b45a91e019b1e98a3971155c7b0c579faf2).

The TRACE_EVENT macro with a custom timestamp should work, but if all you're doing is trying to create (offline, maybe because you're converting from another format) a file that can be displayed by the UI, you probably should follow this guide. Depending on what you're trying to achieve, this might be a better option.

[godmar]

Follow up: I was able to get it to work successfully using the TRACE_EVENT macros after some difficulties with C++ template resolution (the timestamp must be explicitly uint64_t).

May I ask a follow up question? I'd like the different events to be shown in different colors. How do I do that?
I tried using different names, and even different categories, but I get this:

I'd like Lock1 and Lock2 to be shown in different colors. Is there any way to influence that?

[LalitMaganti]

This has been asked and answered many times before: #675, #620, #208

The comment on #620 and #675 is still the latest state of affairs.

[godmar]

Thank you for the reply. I should point out that I don't really want to set the colors myself like in the posts you link to - I'm totally fine with Perfetto setting/assigning them for me.

But of all possible color assignments, Perfetto seems to be picking the absolute worst one: using the same color for when both the category and the event name differs. Is there a way to "trick" Perfetto into assigning different colors based on its default assignment algorithm?

[LalitMaganti]

The color assignment works based on the hash of the event name only. I guess you might be getting unlucky with two differently named events ending up with similar colors by chance.

@stevegolton for thoughts on improving color assignment.

[stevegolton]

We've floated the idea of having user driven color palettes before, but it's a low priority for us.

We actually have an "alternative" color palette hidden behind this flag. It uses the same hashing function but has a different modulo, so you could try enabling this flag and see if it makes a difference.

Alternatively, assuming you're just getting unlucky with the hash function, try adding a space or change the capitalization or something which should trick the colors into being different. If they're still the same color, perhaps something more insidious is going on.

[godmar]

It seems to depend on the length of the event name.
Lock 1 and Lock 2:

Lock 1 and Lock 2 (extra space)

1-Lock and 2-Lock:

1-Lock and 2-Lock (extra space):

Sense this does not make, but I can work around it now.

[stevegolton]

This seems very odd, can you share the trace?

[godmar]

Here you go

trace.zip

[stevegolton]

Thanks!

Ah, so it looks like we actually replace numerical values in slice names before hashing. I'm trying to find out whether we still need to do this.

In the meantime, a workaround would be using non-numerical characters to differentiate the locks. E.g. Lock A, Lock B.