Support per-frame analysis for janky frames

[kenzieschmoll]

When a janky frame occurs, the user wants to know what took a long time to build/layout/paint. With any of the “Enhance Tracing” toggles enabled, DevTools should be able to provide per-frame analysis on the widgets built and render objects laid out and painted.

One idea is to show a bottom up view for each of the build, layout, paint events to identify widgets with expensive self time. Self time in this case would be event.time - sum(children.time).

[kenzieschmoll]

Event when "Enhance Tracing" is not enabled, we should nudge the users to use the feature when we encounter a long Build, Layout, Paint phase for a janky frame - see #3483.

[kenzieschmoll]

@InMatrix @cobblest @ayanogawa here is an implementation of the "tab-controller-like" view for navigating between the timeline events chart and frame analysis views (as proposed in the design doc). The general workflow is as such:

• in the flutter frames chart, frames with jank are marked with an icon suggesting more analysis is available (right now, marked only for UI jank until we have more actionable data from the raster thread)
• When this frame is selected, a button with the same icon and tooltip "Analyze selected frame" will appear in the Timeline Events section header.
• Clicking this button will open a tab for this frame's analysis

Some other items to note:

• Tabs will remain open until manually closed.
• Selecting a new frame will open the timeline frame chart to that frame's time range (current behavior)

Please let me know what you think, thanks!

[InMatrix]

Thanks for the update, @kenzieschmoll.

I like the general direction this is taking. There are a few questions I'd like to discuss:

1. Having both the "shader jank" icon and the "analyze" icon for some frames look busy. I wonder if we could combine the two icons. Related, how useful is it to identify frames with shader compilation jank, since the workaround doesn't seem to be very useful?
2. How long does it take to analyze an individual frame?
3. If individual frame can be analyzed and visualized quickly, I wonder if it would make sense to show the individual frame view instead of the full Timeline Events chart by default. The full timeline events chart is difficult to navigate and sometimes slow. Is there a use case where navigating in that view is beneficial?

[kenzieschmoll]

Having both the "shader jank" icon and the "analyze" icon for some frames look busy. I wonder if we could combine the two icons.

I think we should be able to do this, and then in the frame analysis view, we can call out shader jank details there.

Related, how useful is it to identify frames with shader compilation jank, since the workaround doesn't seem to be very useful?

Good question. I think we should continue to support the shader jank features until this is no longer a problem. IIRC, this will likely become obsolete by Q1 or Q2 next year with work @chinmaygarde is doing to build a rendering stack that won't require shaders. @dnfield @goderbauer would you agree that it is still useful to keep the shader jank features around for now?

How long does it take to analyze an individual frame?

The time to do this should be negligent. It will be a matter of looking at the timeline events for that frame and providing some visualizations based on that data.

If individual frame can be analyzed and visualized quickly, I wonder if it would make sense to show the individual frame view instead of the full Timeline Events chart by default. The full timeline events chart is difficult to navigate and sometimes slow. Is there a use case where navigating in that view is beneficial?

The use case for the timeline events chart is general trace viewing. This is still a primary part of performance profiling, and where users will likely start to investigate their app's performance. Users can look at traces for a flutter frame (sent by the framework / engine and potentially the additional events sent with the Enhance Tracing features enabled), and they can also see traces they've sent from their own app via dart:developer, other events on the Dart thread, events from the platform thread, GCs, etc. It is also useful to see trace events for a frame within the whole picture of timeline activity. This can show things like latency between frames as well as how a frame's events align with async activity or activity on other threads.

So IMO, the timeline events chart is probably still the entry view for users to start with.

[goderbauer]

would you agree that it is still useful to keep the shader jank features around for now?

Providing the information that the frame was slow because of shader compilation is still useful to give them some feedback about why a frame janked. Unfortunately, until some time next year there isn't really anything developers can do about it. What is the current messaging we give to developers when such a janky frame is encountered?

[cobblest]

in the flutter frames chart, frames with jank are marked with an icon suggesting more analysis is available (right now, marked only for UI jank until we have more actionable data from the raster thread)

What's the difference between the icon and color labels? If we have the color labels, it seems unnecessary to add another icon for the jank frames?

[kenzieschmoll]

in the flutter frames chart, frames with jank are marked with an icon suggesting more analysis is available (right now, marked only for UI jank until we have more actionable data from the raster thread)

What's the difference between the icon and color labels? If we have the color labels, it seems unnecessary to add another icon for the jank frames?

In the current state, a the icon would differentiate janky frames for which we have analysis data from janky frames where we don't have analysis data (these would be janky frames due to raster thread activity). What we are hoping to signal to users is "we have additional information about this frame that you may find useful".

[kenzieschmoll]

@goderbauer

What is the current messaging we give to developers when such a janky frame is encountered?

We show a warning icon on the frame, a banner with info about the number of janky frames and how much time was due to shader compilation, and we show info in the tooltip regarding the shader compilation time per frame. We also link to the documentation in both the tooltip and the banner.