Use an Stacked Area Chart instead of Bar Chart for Performance page

[gaaclarke]

Currently the Performance page shows parallel bar charts for Performance.

It would be much more useful if these were instead a Stacked Area Chart. That way it's easier to see how much time is being spent on each frame in total instead of having to calculate the sums in your head. It also scales better as we add more fields like shader compilation or garbage collection time.

See the wikipedia page for an example of a Stacked Area Chart: https://en.wikipedia.org/wiki/Area_chart

cc @iskakaushik

[kenzieschmoll]

Are you suggesting we have UI thread time and Raster thread time stacked on top of one another? So if 10ms was spend on each thread, this would look like the frame took 20ms and not 10ms?

If this is the case, this is something we used to do in the past but ended up moving away from. While accurate in terms of total time consumed to build and raster this frame, this is not necessarily the best way for identifying jank. For example, a frame could take 15ms on the UI thread and 15 ms on the Raster thread, and the frame did not miss the 60 FPS target. But a frame could take 25ms on the UI thread and 5ms on the Raster thread, and the frame did miss the 60 FPS budget. If we stack the bars on top of one another, both frames look like they took 30ms even though one frame should be investigated further and one should not.

Some prior art on this: #451, https://docs.google.com/document/d/1YGLELXWdC6YIN03QzEzcIRJc56gCnabPBW8BHCAFR58/edit

CC @jacob314

[gaaclarke]

For example, a frame could take 15ms on the UI thread and 15 ms on the Raster thread, and the frame did not miss the 60 FPS target.

Thanks @kenzieschmoll, I don't understand why that is. Even though the ui thread and the raster thread are operating in parallel, for a given frame the operations are serial. First the frame is calculated on the ui thread, then it's rendered on the raster thread. Those times added together should be under 16.67ms for 60fps, no?

If we stack the bars on top of one another, both frames look like they took 30ms even though one frame should be investigated further and one should not.

Yep, they should be on top of each other, but each segment should be different colors, so it should be showing the same information, but easier to visualize the summation and divide it up into more segments.

[kenzieschmoll]

CC @dnfield @goderbauer as you've been investigating jank.

[goderbauer]

My understanding is that there is some amount of parallelization going on. While the previous frame is getting rasterized, the next frame can already be build, so for smooth operations it is not always necessary that build + raster time are under 16.6ms. Presenting them stacked on top of each other may send the wrong message in regards to that.

Personally, when debugging I've looked at build and raster times separately trying to identify frames that are either slow to build or to raster. I haven't really missed the aggregate so far.

[gaaclarke]

Right so if the timeline looks like this:

ui     | build frame 1 | build frame 2 | build frame 3 |
raster |               | draw frame 1  | draw frame 2  |

It sounds like we are presenting: (build frame 1), (build frame 2 + draw frame 1), (build frame 3 + draw frame 2)

That's how (build frame 2 + draw draw frame 1) < 16.67ms but we still jank, because (build frame 1 + draw frame 1) > 16.67ms?

It seems like we should be presenting: (build frame 1 + draw frame 1), (build frame 2 + draw frame 2), (build frame 3 + draw frame 3).

[kenzieschmoll]

It sounds like we are presenting: (build frame 1), (build frame 2 + draw frame 1), (build frame 3 + draw frame 2)

When you say presenting, do you mean in the frames chart (the one with the side by side bars) or the timeline (the flame chart of trace events)? In the frames chart, we are matching up the build and raster time for a single frame, regardless of the latency that may be between those two time ranges. In the timeline, we also link the build and raster portion for a frame, drawing blue brackets around each section to indicate which sets of trace events belong to the selected frame.

[gaaclarke]

When you say presenting, do you mean in the frames chart (the one with the side by side bars) or the timeline (the flame chart of trace events)? In the frames chart, we are matching up the build and raster time for a single frame, regardless of the latency that may be between those two time ranges.

Okay, that's what I would have expected. Yea, I was trying to understand why (ui + raster) < 16.0ms could still mean jank. When you say "regardless of the latency between those 2 time ranges" is that where the jank is coming from? That's the X factor? (ui + raster) < 16.67ms but (ui + x + raster) > 16.67ms? If that is the case I'd present the data as a stacked area chart with 3 sections ("ui", "raster", "other"), where other is the time between the ui range end and the raster range start.

If the summation of times associated with a frame being under 16.67ms doesn't represent 60fps, we should shift the math to mean that because that's what people would expect imo. My recommendation to use a stacked area chart only makes sense if we are doing the math that way.

[srawlins]

Because Flutter's UI and Raster threads operate in parallel across frames, stacking their execution times on top of one another can give a misleading representation of total frame duration and frame budget (making smooth frames appear janky when work was pipelined across threads). DevTools previously explored stacked charts and moved to separate UI and Raster bars for this reason. We will keep the current frame chart representation.

If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!