Embedder uses too many surfaces for platform views

[knopp]

Here is example application that has 4 platform views interleaved with Flutter content:

It uses a total of 5 surfaces, each one has size of entire window (because resizing surfaces is expensive). However there is no content directly painted over platform view so this entire scene could be rendered to the background surface and the end result would be same, saving 4 surfaces.

Another example - 4 platform views with Flutter content painted above the views:

This still uses 5 surfaces, but the same visual result can be represented by only two surfaces - content that is painted below platform views in first surface and content that is painted above platform views in second surface.

Same scene, painted with https://flutter.dev/go/optimized-platform-view-layers:

optimized-platform-view-layers.mov

Initially, there are two surface, but as they move to not paint over platform views, only one surface remains.

[stuartmorgan]

Won't this potentially create a lot of view allocation and destruction during animation?

[knopp]

I assume you mean surface allocations? Is the scenario something like a platform view being repeatedly covered and then uncovered by Flutter content during animation?

If this turns out to be a problem we can cache the surfaces more aggressively in the embedder and release only after they haven't been used for n-frames (or some time). Hover same scenario right now on iOS would currently result in repeatedly creating and destroying one or two CAMetalLayers per platform view, which is quite a bit more expensive than a single surface and I assume it's not a big issue in practice there so I don't think it's going to be here.

[lucalooz]

Hi @knopp,
do you think that flutter/engine#43301 could have a positive impact on #129632?

[knopp]

Hi @knopp,
do you think that flutter/engine#43301 could have a positive impact on #129632?

Unlikely, because iOS doesn't use the embedder API and the platform view implementation is very much different between these two. It might eventually get migrated to embedder API, which in my opinion should improve platform view performance quite a bit, but I'm not aware of any timeline for this.

[jwinarske]

@knopp Is this example available somewhere? I have started work on platform views support for Wayland compositor on Linux, and this would be a great starting point.

[knopp]

@knopp Is this example available somewhere? I have started work on platform views support for Wayland compositor on Linux, and this would be a great starting point.

https://github.com/knopp/layer_playground

Might not be up-to-date with latest platform view API in Flutter though.

[jwinarske]

@knopp great thanks!

[renanyoy]

This fix removed the ability to use Opacity(...) on platform views, platform views are only displayed when opacity = 1 now and hidden otherwise.

In my usage, as many platform views are displayed a lot faster. I can avoid using opacity now.. it's just to signal it.

[knopp]

I seem to be unable to reproduce this with layer_playground example:

(blue rectangles are platform views wrapped with 0.5 Opacity). So there must be some additional factor.

[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.