Explore whether providing a pbuffer surface before the SurfaceView is available helps first frame latency

[dnfield]

Currently, the SurfaceView does not get a Surface until the Choreographer inflates the view in its first doFrame. On lower end devices, this can take a significant amount of time, and may be delaying signals to the running Dart code that could be used to prepare the drawing of an initial frame.

It may be worth providing a pbuffer surface until the actual on screen surface is available, so that the framework can start trying to do work earlier. One thing I still have to explore is how much this helps applications that try to rapidly draw something without doing much other initialization work, since the traces I'm currently looking at do a substantial amount of initialization work before trying to draw a frame. It may be that those are what really take the time rather than waiting for a surface to be available.

/cc @blasten @goderbauer @xster fyi

[blasten]

This dependency is blocking the rasterizer for sure:
https://github.com/flutter/engine/blob/ffdaa4bb54c148bfe36216bfe6eebe326f423aa3/shell/common/rasterizer.cc#L377

Does it block Dart too?

[dnfield]

Our real problem here was tht we were blocking the platform thread on the UI thread (fixed in flutter/engine#29145). I was incorrectly assuming that creating a surfaceview was taking a long time.

[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.