Make --cache-sksl less susceptible to shader jank while caching shaders

[jacob314]

Currently users can struggle with following https://flutter.dev/docs/perf/rendering/shader because shader jank can cause frames to be skipped causing not enough shaders to be cached. When users fail to cache all shaders, they assume that shader caching just doesn't fully resolve shader jank. You may still see exactly the same number of frames janking just different frames after the animation survived the first janked frame.

Options:

1. Automatically run with a large time dilation value when --cache-sksl is passed. Potentially a value of 30 might be required to cope with shader jank that lasts for 500ms but this could be very annoying for users caching shaders.

2. More difficult: run with a custom clock so that simulates running the application pretending no frames janked. Potentially this would still be combined with some smaller amount of time dilation (e.g 5) to increase the chances of cache hits.

[jonahwilliams]

We could create a service protocol extension to set the time dilation value and run that at startup if --cache-sksl is passed. That won't completely capture all startup frames unless you also start paused and resume though.

[jacob314]

using a Dart define to set the initial value could be easier than starting paused and resuming although starting paused and resuming sounds reasonable.

[jonahwilliams]

I would recommend against using compile time defines if possible since it will lead to extra rebuilds when users switch in and out of this mode

[jonahwilliams]

actually, start paused wouldn't work since we could not set the value if the app were paused. Could set it as an engine flag like --route

[jacob314]

On the topic of not forcing users to perform extra builds to cache shaders, why do we recommend that shaders are cached in profile build instead of allowing a debug build? Debug build combined with time dilation should be just about as effective for caching shaders.
In debug mode, using a Dart define would not be an issue.

[jonahwilliams]

Yeah, I believe the recommendation with profile mode is just too avoid losing many frames.

[jonahwilliams]

you could also run through the animations sequence multiple times, though that might be difficult if it is non-repeatable by nature (like a startup animation).

I wonder if the recording "persists" through a hot restart?

[dnfield]

I think what we really want here is some mode where the app "renders every frame". Time dilation is a sort of work around to get at that, but what we really want is a way to make sure that each and every frame that can be rendered is,no matter how long we have to wait for it. See also discussion at #85118