The rendering rule is a calling convention documented in FlutterView.Render:

  /// This function must be called within the scope of the
  /// [PlatformDispatcher.onBeginFrame] or [PlatformDispatcher.onDrawFrame]
  /// callbacks being invoked.
  ///
  /// If this function is called a second time during a single
  /// [PlatformDispatcher.onBeginFrame]/[PlatformDispatcher.onDrawFrame]
  /// callback sequence or called outside the scope of those callbacks, the call
  /// will be ignored.

This rule is very important to implementing multi-view without having to introduce new APIs. However, historically these illegal calls were not ignored and could cause unintended effects that many things were actually relying on.

With multiple PRs, we managed to make it closer to removing violations, but we still haven't fully enforced it.

The current status:

• On debug build, illegal calls are caught and skipped by the PlatformDispatcher.
• On release build, illegal calls are caught and skipped by the Animator.

We should:

• Unify the behavior of the debug build and the release build.
• Make both behavior assert on (and skip) illegal calls.

Obstacle:

• Currently a performance regression is caused by this change (see Revert "Reland: Enforce the rule of calling FlutterView.Render (#45300)" engine#46919). However, we suspect that the regression is entirely caused by 2 frames being dropped, and those 2 frames are illegally drawn warm-up frames.
  • Update: The cause for the regression has found. Properly render the warmup frames #142851 needs to be resolved before this issue.
• The framework unit test harness is written in a way that calls render directly, and we can't change it for now since there are no dependency injection around FlutterView and PlatformDispatcher.