The slow frame could be as slow as 1.7s as noticed in these plots. It is first noticed in #60559 (comment) because the newly added host-independent (e2e) perf tests have such low overhead that it captures them with a high probability before the engine sends out the batch of FrameTiming with such slow frame.

By looking at the e2e_perf_summary.json, such slow frame is not the first frame so it's not captured by the timeToFirstFrameRasterizedMicros metric. (It's often the second frame captured.)

Our normal flutter_driver perf tests usually have too much overhead that it won't be able to see such frame in the timeline. But sometimes (maybe 10%-20% of the time) they see it which causes the worst frame time to be bi-modal.

On the other hand, flutter run --profile --start-paused won't be able to capture the slow frame trace so that frame presumably happens before the pause kicks in.

We should have a way to get a full trace for app startup to investigate this slow frame. The --trace-startup flag currently only prints out a short summary without a full timeline trace.