Add flutter frame identifier to timeline events on UI and Raster threads

[kenzieschmoll]

In DevTools, we need a way to connect Flutter.Frame events (sent here) to their corresponding timeline events on the UI and Raster threads. This is a requirement in order to make the DevTools timeline show live frame data.

We cannot connect a Flutter.Frame event to its corresponding timeline events by timestamp because the two data sources use different clocks. From @iskakaushik:

Based on some initial observations, there doesn't seem to be an easy way to convert between Dart Timeline and Flutter Clocks. For example, on iOS, Dart timeline seems to use "mach_absolute_time" which doesn't increment when the system is asleep, whereas in Flutter we use "std::chrono::steady_clock()" which is independent of the system uptime.

If we could add metadata to the root UI thread and root Raster thread event that would allow us to associate those two timeline events with a Flutter.Frame event, that would work. Perhaps adding an arg "frameNumber" that matches the "number" field from Flutter.Frame events.

[jonahwilliams]

@kenzieschmoll is there any reason not to go with the frame-janks-are-errors design of have the framework plumb through the frame identifier? If not, I can wire that up fairly quickly....

[kenzieschmoll]

the frame-janks-are-errors design of have the framework plumb through the frame identifier

would this result in both the UI root event and the Raster root event having the identifier in their trace events?

[jonahwilliams]

Yes, the information should be available in the engine when we write the traces. I didn't wire that up in the prototype but can't imagine it would be that hard (famous last words)

[kenzieschmoll]

Then that sounds like exactly what we need.

[iskakaushik]

Capturing the offline discussion with @jonahwilliams:

I like the idea of having a frame identifier that is associated with trace events. Given that engine triggers the frame build and raster process, it would be best if engine does the creation and managing lifecycle of the said frame identifier.

Next steps are for Jonah and I to iterate on flutter/engine#25662.

[jonahwilliams]

Another use for this would be flutter/devtools#2943

[kenzieschmoll]

Another use for this would be flutter/devtools#2943

To meet this use case, the starting frame number would need to be consistent (0-based or 1-based) so we can identify the first frame for an app run.

[iskakaushik]

flutter/engine#25892 and flutter/engine#26021 partially address the issue. Per my conversations with @jonahwilliams and @kenzieschmoll , the next AIs are:

1. @iskakaushik to add the frame_number as a trace event argument in animator and rasterizer events.
2. @jonahwilliams to propagate the frame_number field via the service protocol FrameTimings APIs.
3. @kenzieschmoll will then change dev-tools to account for these changes.

Thanks and let me know if I'm missing something here.

[kenzieschmoll]

Interestingly, the frame numbers don't seem to be incrementing by 1. In this example they are increasing by 3 - is that expected? @iskakaushik @jonahwilliams

[jonahwilliams]

That is surprising to me at least :)

[iskakaushik]

I saw it alternating each time, 1, 3, 5...

This PR should fix it: flutter/engine#26513. At least locally after this change I'm seeing every number appear.

[zanderso]

What is left to do for this?

[kenzieschmoll]

I think this is complete.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.