Benchmark regression in complex_layout_scroll_perf_ios__timeline_summary

[flar]

There was a worst frame rasterizer time regression in the complex layout benchmark on iOS (Impeller).

https://flutter-flutter-perf.skia.org/e/?keys=Xb32df78351d0d4eca428a1f6cf024fde&selected=commit%3D40502%26name%3D%252Carch%253Dintel%252Cbranch%253Dmaster%252Cconfig%253Ddefault%252Cdevice_type%253DiPhone_11%252Cdevice_version%253Dnone%252Chost_type%253Dmac%252Csub_result%253Dworst_frame_rasterizer_time_millis%252Ctest%253Dcomplex_layout_scroll_perf_ios__timeline_summary%252C&xbaroffset=40502

[jonahwilliams]

The reason this regressed is that I removed the additional shader bootstrap. While we weren't actually using those shaders, as a side effect we no longer block until shaders are fully available in context creation, meaning that on the first frame we have to wait.

[flar]

The reason this regressed is that I removed the additional shader bootstrap. While we weren't actually using those shaders, as a side effect we no longer block until shaders are fully available in context creation, meaning that on the first frame we have to wait.

If I'm reading this correctly, the reason it is impacting these benchmarks is that (?):

We used to not even start rasterizing frames until the shaders were loaded and the first frame had no waits between its begin/end because it didn't even try to start its work until everything was ready?

And now since it is asynchronous we might start that first frame earlier, but we can't finish it until the shaders are ready - time that used to be ignored as part of "app startup" but now appears in the first frame time?

This was the only benchmark impacted, though, so I'm curious why some of the more simple benchmarks didn't have a regression like that...

[jonahwilliams]

Actually I'm wrong, this is caused by the changes I made to image decoding. Maybe we've got a mutex somewhere that we're contesting? Or there is something in the metal driver that is contested now: