cc @johnmccutchan @reidbaker for routing to reviewers. I believe John was already looking into this area recently.

It would help to see how this code is used in your plugin. As it stands now this is adding a lot of complexity to the engine with no clear upside.

@johnmccutchan

You can check the plugin and example here simple_platform_view branch external-view-synchronization.

BTW, this seems to be aimed at improving the performance of hybrid composition mode- why are you using that mode and not TLHC?

Because TLHC and VD do not render the same way native does.
By not interfering with the native render mechanism, this mode can preserve the native behavior and reduce bugs.
And TLHC cannot record SurfaceView as far as I know.

Because TLHC and VD do not render the same way native does. By not interfering with the native render mechanism, this mode can preserve the native behavior and reduce bugs. And TLHC cannot record SurfaceView as far as I know.

I'm aware that TLHC won't work with SurfaceView but aside from that, what specifically is wrong with TLHC and VD modes? Have you filed bugs detailing missing features / bugs in those modes? I'm asking because I'd like to get rid of Hybrid Composition mode and rely entirely on a render-to-texture implementation and I'd like to understand specifically what else needs to be fixed to enable this simplification.

Nothing wrong, it is just they are not real native, HC is real native but its performance is bad. So I want to implement this which have good performance and real native view. I can use it in some app that requires native-like performance.

The reason render-to-texture is hard to achieve native-like performance is that the performance of the native view is affected by the flutter widget. In this mode, native view rendering is not affected by flutter so the performance of it is good. The performance of Flutter using FlutterImageView is not as good as FlutterSurfaceView but it is much better than HC and I can switch back to FlutterSurfaceView anytime. Imagine an app like Google Maps when the map is native view and the UI is Flutter, this mode is good for an app like that.

From Engine PR triage: Based on the above discussion, I'm going to close this PR as I'm concerned that it does not appear to be solving an issue and/or is not aligned with other workstreams.

It's obviously for implementing features for plugins. Is it not allowed?

It's obviously for implementing features for plugins. Is it not allowed?

@XuanTung95
Hello, do you have any further research on this issue, I saw in flutter/flutter#133990 that you said at the end that a custom engine was distributed to do this without modifying Flutter. Is it possible to open source it, I'm having this problem with native ads using google_mobile_ads. Thank you very much!

@fe-spider
Check my plugin https://pub.dev/packages/simple_platform_view

Random thought: before, I don't think improving HC mode is posible because it create views during rasterization which must be called from UI thread. But what if I create image readers instead? It do not require UI thread. When the background and overlay inages arrives in the UI thread, I can create/destroy/position Views to construct the correct UI using information from the timestamp. This way rasterization can still be in the raster thread.
Update: The performance is still bad since it needs to render into multiple surfaces. For low-end android devices, it's better to render into a single surface.