[Impeller] when creating new pipeline variant block on current thread, re-persist dirty pipeline cache.

[jonahwilliams]

Current diagram of how PSO variants are created (after first bootstrap)

Raster thread.                             Worker Thread
1.  Check Pipeline Cache
2. Pipeline Cache Empty
3. Create Promise
4. Spawn Worker                     ->      Compile Pipeline
5. Block On Future.                       ..                                                    
6.
7. Resolve                          <-      Complete Future

This is a serialized workload due to blocking on future completion. But performing it on two threads means that we're also adding in the somewhat random cost of thread scheduling and or getting deprioritized.

Instead when creating variants, block on the current thread. Now if we knew all the variants we need to create for a frame ahead of time, we could spawn one or more works to creat them more quickly. This would require more work though.

While I'm at it. Update the pipeline cache to persist every 50 frames, if it has added a new shader.

part of flutter/flutter#129660

[jonahwilliams]

LMK if this makes any sense. I don't think it will be faster on average, but there can definitely be cases where the phone is busy and it takes a while for the task to get scheduled.

[chinmaygarde]

somewhat random cost of thread scheduling and or getting deprioritized

My sense was that the cost of 1) small enough to not be statistically significant, and 2) didn't happen all that often because the variant was in the map already.

But I suppose I am somewhat convinced this could be an issue. I am suggest an alternative method call instead of the GetPipeline. GetPipelineSync or GetPipelineBlocking or GetPipelineNow. Instead of a default argument, this will be more self documenting IMO. LGTM otherwise.

[jonahwilliams]

the scheduling is generally fine on iOS but appears to be a crapshoot on Android.

[chinmaygarde]

Yeah, makes sense. And I guess we will toss the task onto a concurrent loop whose priorities may be different.

[jonahwilliams]

priorities /affinities don't really matter, you can't guarantee that code will be run immediately with the task runners on any platform. Android is busier than iOS but the same thing can happen there if we're doing a lot of image decoding.

GetPipeline. GetPipelineSync or GetPipelineBlocking or GetPipelineNow. Instead of a default argument, this will be more self documenting IMO. LGTM otherwise.

There is a pretty long chain of methods from create variant, through get pipeline, into the pipeline caches. One of the reasons I used the argument was that I could leave most of this as is without duplicating the methods to have sync/async versions down to the pipelin cache.