Hi Ludovic,
thanks for the thorough answer. I understand that batching all sequence types helps with performance.
Our use case for the synchronous runner has been to set up the widget to its initial animation state during construction. We “scrubbed” the animation to its first or last frame depending on, say for example, an “enabled” state on construction and then later when the user clicked on a different entry played the animation normally. This was to avoid having to add blueprint code for setting the initial or final state in blueprint logic which could get out of sync with the animation if someone edited it. A fade in animation could also be realized nicely with this approach because the animation could be set to the first frame in construct which would hide the widget before the first draw.
While this is still somewhat possible without the synchronous runner, this approach fails if the animations are not evaluated before painting the widget the next time which would cause the widget to show up in a wrong state for one frame, which is not really acceptable.
A combination of the “scrub to” (either from back or from front) behavior that is available in the level sequence player and a guarantee that animations are evaluated before the widget is drawn the next time would probably fulfill our requirements.