There are cases where the Rasterizer thread can be attempting to render a new frame, but it gets stuck waiting for the next vsync instead. This is not a case of producing a frame and then the frame is held until the next vsync - the thread is still producing a frame and gets stuck on a random GL call before it completes the frame and schedules it to be flushed to the screen.

This can be seen when running the Transform Animation page of the macrobenchmark app. If you run the app manually (visit dev/benchmarks/macrobenchmarks and execute flutter run --profile and bring up the performance overlay), you can scroll down and run the "ImageFiltered Transform Animation". When it starts up it should be in the "IF rotate" mode which animates a rotation using ImageFiltered and generally gets around 9ms on my Moto G 4. If you switch to another mode, like "Opacity" and back to "IF rotate" then it might return to a 9ms performance rate, or it may return to a 16ms rasterization performance. It's random, but happens frequently. This is due to an odd timing of the way we produce our frames and whether that triggers the problem here.

On longer running benchmarks, like gallery transitions, the app can move into and out of this state several times over its run. Indeed one WIP fix for this problem improved average frame rates on that benchmark from around 6.8ms down to around 2.4ms on iOS. (We've since moved to Metal on iOS so the problem may not happen there with as much regularity but the condition still affects us on Android).

Note that while we are stuck in this wait condition we aren't using energy so this doesn't affect battery consumption. Also, the frames generally come out every 16ms, it's just that the frame you see is 16ms behind in time. So, the effect isn't very visible to the user except perhaps as lag.