Skip to content

Properly start rasterizing before the framework cleans up #144584

@dkwingsmt

Description

@dkwingsmt

In the single-view Flutter, the framework calls FlutterView.render before doing clean-ups such as disposing the scenes. The FlutterView.render immediately sends the layer tree to the pipeline, therefore the rasterization can start before the framework's cleanups.

In the multi-view Flutter, this is harder, because handleDrawFrame has to traverse all views to send their layer trees to the engine, and the engine can no longer send them to the pipeline immediately (one frame must only produce one pipeline item), but has to wait for after handleDrawFrame to batch all the layer trees into one pipeline item. As a result, the rasterization will start after the cleanups.

The cleanup time can take a long time, since the user can put arbitrary code in end-frame callbacks of widgets. This is a performance regression for existing single-view apps.

We came up with two options:

Option 1. Double-pipeline structure

Each item for the FramePipeline now contains an inner-pipeline of layer trees. Every time a Render is called for a view, the layer tree is pushed to the inner-pipeline, and the rasterizer immediately consumes the layer trees for rasterization.

This is a non-trivial change (it might even require another thread for the inner pipeline), but it works for all cases, and might be evolved into the multi-rasterizer design in the future.

Option 2. Early end-frame

The engine records the view that have been called Render during this frame. If all registered views have been rendered, then the engine immediately asks Animator to end the frame.

This change is much smaller than option 1. It works for single view apps, but for multi-view apps it only works if all registered views are rendered (i.e. no hidden views), which probably covers the majority cases anyway.


Since we're trying to land the multiview changes, and avoiding regressing the single-view apps is a high priority, we probably want to implement option 2 first, and discuss if we'd like to migrate to option 1.

This issue is related to flutter/engine#51186 (comment).

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work lista: multi windowIssues related to multi window supportengineflutter/engine related. See also e: labels.frameworkflutter/packages/flutter repository. See also f: labels.team-engineOwned by Engine teamtriaged-engineTriaged by Engine team

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions