Skip to content

Explore more retained rendering #23535

Closed
Closed

Description

@liyuqian

After finishing our first milestone of retained rendering (#21756), let's explore what more we can achieve with retained rendering. Here are some examples:

Activity

  1. self-assigned this
    on Oct 25, 2018
  2. added
    engineflutter/engine related. See also e: labels.
    c: performanceRelates to speed or footprint issues (see "perf:" labels)
    frameworkflutter/packages/flutter repository. See also f: labels.
    and removed on Dec 11, 2018
  3. added this to the milestone on Aug 7, 2019
  4. Hixie commented on Jan 9, 2020

    @Hixie
    Contributor

    @liyuqian Can you elaborate on "Explore if we can add an option to RepaintBoundary and improve performance significantly by using snapshot of a layer subtree that's not a child of an OpacityLayer"?

  5. liyuqian commented on Jan 10, 2020

    @liyuqian
    ContributorAuthor

    @Hixie : I was thinking about raster caching the whole layer subtree for either a TransformLayer (#24627), or an ImageFiltered layer. See #32662 for more details. @flar has been doing a lot of work recently (including introducing the new ImageFiltered layer flutter-team-archive/engine#14491). So @flar may be able to provide more details.

  6. removed their assignment
    on Jan 10, 2020
  7. flar commented on Jan 10, 2020

    @flar
    Contributor

    ImageFiltered does cache if its child layer is stable, but it is only stable if you use a RepaintBoundary.

    Right now we recreate a lot of layers even if nothing changes. I'm still digging into our strategies there, but a lot of it probably hinges on the way that we manage Picture layers. They are recreated if the part of the tree they are in is visited even if they themselves don't involve any Widgets/RenderObjects that changed.

    They are also created from groups of RenderObjects that are next to each other in a depth-first traversal of the tree, but that don't necessarily all descend from a single parent. If the picture was generated from a single RenderObject then we might be able to just check a flag on that object, but pictures are actually generated from a group of them and since they aren't aware that they are all contributing to the same picture together, we end up with no specific flag that can be checked to see if the picture is dirty and so we pessimistically recreate it every time we traverse the tree.

    I have a change pending that can try to make a better determination if a picture is actually changing, but it is more reactive than I'd like and it doesn't have as much impact as I'd like to see. I'm still investigating its potential and thinking of alternate solutions. A preliminary version of it can be seen in a branch on my fork of the framework repo in this commit: flar@bc131bf

    If we can get our layers to be reused more then it becomes a lot more feasible to cache layer renderings in the engine with a few lines of code in the engine layers and potentially without requiring developers to use RepaintBoundary all the time.

  8. added
    P2Important issues not at the top of the work list
    on May 29, 2020
  9. removed this from the milestone on Aug 17, 2020
  10. jonahwilliams commented on Aug 13, 2024

    @jonahwilliams
    Contributor

    Impeller is moving away from full scene or layer based caching. Closing as obsolete.

  11. github-actions commented on Aug 27, 2024

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  12. locked as resolved and limited conversation to collaborators on Aug 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Important issues not at the top of the work listc: new featureNothing broken; request for a new capabilityc: performanceRelates to speed or footprint issues (see "perf:" labels)engineflutter/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

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions