Open kenzieschmoll opened 2 years ago
One idea is to keep a running average of all the 'VSYNC' event times we have seen, and to tell users that we detected a longer 'VSYNC' than normal. It is still unclear what we can tell them for why this happened and what they can do to fix it, though.
Can you attach a systrace or observatory trace for that? That should tell us more about whats happening and how we can fill in the blanks.
Here's an Observatory trace dart-timeline-2022-9-15.json.txt
That seems to be a wait for the GPU to finish work. We usually capture and instrument a GPU frame for such cases. We could add a trace around the wait to indicate to the user that the CPU is workload is fine but we are waiting for the GPU to catch up.
That would be helpful. Especially if that message is clear by the event name. So the performance solution here would be to optimize what is happening on the raster thread?
So the performance solution here would be to optimize what is happening on the raster thread?
Unfortunately, it's not quite that simple. It could be that the application has specified a particularly expensive operation (like a non-pipeline blend). There is nothing we can do on the raster thread in that case and the application must be reworked. With Impeller, we are putting more stuff in the GPU traces but we can only capture them currently using Xcode. Would it be useful to walk over our tracing workflow to see how and what we can expose via DevTools?
Would it be useful to walk over our tracing workflow to see how and what we can expose via DevTools?
Yes, it definitely would. Feel free to throw something on my calendar.
@jonahwilliams this sounds similar to the issue you were describing to me yesterday wrt latency
Ahh perfect. The idea i had was to track vsync delay and add the to build time. That would surface cases where build finished later due to being delayed by jank between frames, but not cases where there were no frames being pumped.
Here's a sample where an expensive calculation happens in setState()
, which is computed between frames:
In this example, the running app (Wonderous in profile mode) visibly janks, but there are no janky frames in the DevTools performance page. Upon looking deeper into the timeline trace, it is clear that there is a large gap of latency between two frames:
How is a user supposed to debug the jank at this point? How can we help them understand what could be causing the latency between frames?
CC @chinmaygarde @dnfield @iskakaushik @jonahwilliams for ideas.