How to enforce start/end times for flows that involve slices?

[oliver]

I am creating files for Perfetto in pftrace format, containing processes and slices and flows. This basically works; but the flow arrows often start or end at the wrong timestamp. E.g. in this example I'd like the arrow to start at the begin of DispatchProcessing rather than at the end:

So far I'm adding Instant events at the desired start/end points; but this has the drawback that clicking on a slice no longer shows flow arrows (I have to click on the Instant events instead, which is hard to discover).

Is there a way to enforce start/end points of flow arrows?

[stanleys12]

There is no flag or field in the trace that lets you choose the arrow's start or end time. The UI picks both from the slice timestamps, so what you can control is which slices the flow is attached to.

The rule is in the flow renderer (

perfetto/ui/src/core_plugins/dev.perfetto.FlowEvents/flow_events_renderer.ts

Lines 85 to 91 in 501a339

	const drawFlow = (flow: Flow, hue: number) => {
	const flowStartTs =
	flow.flowToDescendant || flow.begin.sliceStartTs >= flow.end.sliceStartTs
	? flow.begin.sliceStartTs
	: flow.begin.sliceEndTs;
	const flowEndTs = flow.end.sliceStartTs;

):

const flowStartTs =
  flow.flowToDescendant || flow.begin.sliceStartTs >= flow.end.sliceStartTs
    ? flow.begin.sliceStartTs
    : flow.begin.sliceEndTs;
const flowEndTs = flow.end.sliceStartTs;

The arrow always ends at the start of the target slice. It starts at the end of the source slice, with two exceptions where it starts at the source slice's begin:

• The target slice starts at or before the source slice's start.
• The target slice is a descendant of the source slice. The UI computes this with slice_is_ancestor in

  perfetto/ui/src/core_plugins/dev.perfetto.FlowEvents/flow_manager.ts

  Line 351 in 501a339

  slice_is_ancestor(t1.slice_id, t2.slice_id) as flowToDescendant

  .

That is why your arrow leaves from the end of DispatchProcessing. Your instant events are a reasonable workaround. An instant is a zero-duration slice, so its begin and end are the same time. The arrow then leaves exactly where you put it.

If you want to keep the flow on the real slice, there are two options:

• Emit the flow on a short child slice or an instant at the start of DispatchProcessing. This is what you do now.
• Split the long slice into two sibling slices, so that the end of the first piece is the point where the arrow should leave.

Clicking the parent slice will still not show the arrow, because the flow is attached to the child. As far as I can tell from the code, the renderer has no option to make a flow follow a parent slice. If you want one, that would need a feature request.

The flow itself is stored in the flow table as slice_out and slice_in. You can check what is attached with:

select slice_out, slice_in from flow

(I looked this up in the code with help from an AI assistant; the links are to the lines I checked.)

[LalitMaganti]

The edge the arrows are drawn from are purely a rendering decision and has no semantic meaning. I don't think we want to add that either as if loses flexibility for us to be able to change how rendering works.

[oliver]

I have fine-tuned the created events now to look pretty much as I want to, by following these rules:

• use each flow id only for two events (i.e. only between the intended start and end events)
• at slice begin and end events, add an additional instant event
  • the timestamp of the instant event must be a bit (e.g. 1 ns) later than the corresponding slice event
  • for slice begin: create one flow from slice-begin to that instant event, and another flow (with new flow id) from that instant event to the desired next event
  • for slice end: don't add the slice-end event to the flow; only create a flow from the instant event to the desired other event.

The result is that flow arrows go in chronological direction (which makes it easier to understand which event caused what), and that clicking on a slice shows the entire flow, and that each even has at most one following flow (i.e. the flow never splits into multiple arrows). For the simple events that I'm visualizing this behavior is quite useful.