@goderbauer, does this seems like it's going good direction? I haven't had much time to play with it, but on the surface it seems to fix the issue:

It looks like this PR breaks both external texture rendering and platform view rendering on Android:

If you want instructions on running/debugging these locally:

https://github.com/flutter/flutter/tree/master/dev/integration_tests/android_engine_test

Golden file changes are available for triage from new commit, Click here to view.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Changes reported for pull request #164322 at sha cc5e1c0

This needs additional work to support external textures.

• Marking new external texture available without regenerating trees will unconditionally repaint all views. This would not be a blocker for this PR (it is not a regression).

• Marking new external texture available may not repaint view with texture. This is definitely a blocker. Framework currently does not know that the texture is dirty and if there is no other render object in the view that needs to be repainted the view is skipped from compositing. This may explain failing goldens on android. A frame is scheduled, but the framework has no idea that the platform view texture is dirty. I'm also not sure if the embedder marks new texture available on change, but even if it did it wouldn't be enough.

I think we'll need to wire MarkTextureFrameAvailable to framework to ensure that the view with dirty texture is always recomposited when regenerating layer trees.

We'll also need to make sure that Android embedder calls MarkTextureFrameAvailable for platform view textures. This might be already the case, I'll need to check. @matanlurey, any thoughts?

Stretch goal: Rasterizer::DrawLastLayerTrees should only repaint trees with dirty textures. Assuming that's the only reason right now to redraw layer tree without regenerating. Is it?

Its sort of a design goal of MarkTextureFrameAvailable that it bypasses the UI thread if possible, to reduce the framerate and workload for android applications with animating platform views. So making that roundtrip back to UI seems like a step backwards.

I'm not actually sure why skipping the repaint is causing a black screen though. the engine should happily enough use the previous layer tree.

I think I didn't explain it well. MarkTextureFrameAvailable bypasses the UI thread, and that works as expected, the problem happens when both MarkTextureFrameAvailable() and ScheduleFrame are called. Now we can no longer bypass the UI thread (because frame is scheduled), but as far as Flutter is concerned, nothing in RenderObject tree is dirty, so nothing gets composited (with this PR).

This seems to be the situation with platform views on Android. Instead of just rendering previous layer tree, a frame is scheduled by the embedder.

hmmmmmmm. I guess we could post messages to both raster and UI task but that feels ... hacky. (Honestly the whole external texture interop feels hacky anyway...)

Consider the following example with multiview:

View1 has external texture that has new frame but no dirty render objects
View2 has some state change and dirty render objects

With this PR, we would only recompose View2, since there are no dirty render objects in View1.
To fix this, MarkTextureFrame available will likely need to call into UI thread to mark the texture render object as dirty. This should not schedule new frame, that would kill the point of external textures, but the frame is already scheduled because of View2 so framework needs to know that View1 needs recomposing.

I guess post thread merge, the texture is actually going to be marked dirty on the combined platform/ui thread, so calling back into UI doesn't seem that bad

This pull request executed golden file tests, but it has not been updated in a while (20+ days). Test results from Gold expire after as many days, so this pull request will need to be updated with a fresh commit in order to get results from Gold.

For more guidance, visit Writing a golden file test for package:flutter.

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

Greetings from stale PR triage! 👋
What is that status of this PR?

There are issues with it. I'll close it for now.