[Android] Fix HCPP frame synchronization when multiple frames run before a Choreographer traversal - #194591

…ore a Choreographer traversal (flutter#194591)

Fixes a few related synchronization issues in HCPP when the raster
thread gets ahead of the platform thread, or when two platform-thread
frame tasks run before Android's `Choreographer.doFrame()` has drawn the
first one. Together, this effectively moves HCPP presentation from
mailbox semantics (where a second frame arriving before `doFrame()`
overwrote the pending frame in `applyTransactionOnDraw`) to FIFO,
aligning with core Flutter.

The end result is that scrolling with multiple platform views looks a
lot, lot smoother.

1. Previously, `PlatformViewsController2.publishTransaction()` appended
every raster `SurfaceControl.Transaction` into a single flat
`pendingRasterTransactions` list, and `swapTransactions()` on the
platform thread drained the entire list at once. Because
`SubmitFlutterView()` posts its platform-thread task asynchronously
after submitting the overlay and main `SurfaceFrame`s, the raster thread
can start or finish frame `N+1` before frame `N`'s platform task runs
`swapTransactions()`. Draining the flat list caused frame `N` to merge
frame `N+1`'s transactions into its `onEndFrame()`, pairing frame
`N+1`'s Flutter surface buffers with frame `N`'s platform view layout
(and leaving frame `N+1`'s platform task without its transactions). This
adds `sealFrameTransactions()` and calls it on the raster thread at the
end of `SubmitFlutterView()` so `swapTransactions()` pops one sealed
frame batch at a time.
2. Similarly, on the platform thread, `onEndFrame()` calls
`flutterView.invalidate()` and
`rootSurfaceControl.applyTransactionOnDraw(tx)`, which defers drawing
the view hierarchy and applying the transaction until the upcoming
`Choreographer` traversal. If a second frame's platform task runs before
that traversal happens, it would immediately mutate the platform view
layout params and merge a second transaction into
`applyTransactionOnDraw`, overwriting the first frame before it was ever
drawn. `PlatformViewsController2` now defers a second frame's view
operations and transactions into a `QueuedFrame` while a frame is
already staged, and replays/commits it once the traversal finishes
(using a `Choreographer.FrameCallback` that posts an async message to
the front of the main `Handler` queue, plus a
`flushCompletedTraversalIfNeeded()` check in case `MessageLoopAndroid`
runs inside `MessageQueue.nativePollOnce()` right after `doFrame()`
before that `Handler` message is dispatched).
3. When two transactions on the same `SurfaceControl` do get merged
before a single draw (for example if 3+ frames arrive within one VSync
and coalesce in `QueuedFrame`), the later transaction's buffer
overwrites the earlier one, but Android's `SurfaceComposerClient`
retains both transaction completion callbacks in an `unordered_set` and
can invoke the newer callback before the older, superseded callback.
`AHBSwapchainImplVK` now tracks a monotonic `present_id` so a superseded
callback recycles its own dropped texture into `pool_` instead of
displacing `currently_displayed_texture_`.

---------

Co-authored-by: Gray Mackall <[email protected]>

…ore a Choreographer traversal (flutter#194591)

Fixes a few related synchronization issues in HCPP when the raster
thread gets ahead of the platform thread, or when two platform-thread
frame tasks run before Android's `Choreographer.doFrame()` has drawn the
first one. Together, this effectively moves HCPP presentation from
mailbox semantics (where a second frame arriving before `doFrame()`
overwrote the pending frame in `applyTransactionOnDraw`) to FIFO,
aligning with core Flutter.

The end result is that scrolling with multiple platform views looks a
lot, lot smoother.

1. Previously, `PlatformViewsController2.publishTransaction()` appended
every raster `SurfaceControl.Transaction` into a single flat
`pendingRasterTransactions` list, and `swapTransactions()` on the
platform thread drained the entire list at once. Because
`SubmitFlutterView()` posts its platform-thread task asynchronously
after submitting the overlay and main `SurfaceFrame`s, the raster thread
can start or finish frame `N+1` before frame `N`'s platform task runs
`swapTransactions()`. Draining the flat list caused frame `N` to merge
frame `N+1`'s transactions into its `onEndFrame()`, pairing frame
`N+1`'s Flutter surface buffers with frame `N`'s platform view layout
(and leaving frame `N+1`'s platform task without its transactions). This
adds `sealFrameTransactions()` and calls it on the raster thread at the
end of `SubmitFlutterView()` so `swapTransactions()` pops one sealed
frame batch at a time.
2. Similarly, on the platform thread, `onEndFrame()` calls
`flutterView.invalidate()` and
`rootSurfaceControl.applyTransactionOnDraw(tx)`, which defers drawing
the view hierarchy and applying the transaction until the upcoming
`Choreographer` traversal. If a second frame's platform task runs before
that traversal happens, it would immediately mutate the platform view
layout params and merge a second transaction into
`applyTransactionOnDraw`, overwriting the first frame before it was ever
drawn. `PlatformViewsController2` now defers a second frame's view
operations and transactions into a `QueuedFrame` while a frame is
already staged, and replays/commits it once the traversal finishes
(using a `Choreographer.FrameCallback` that posts an async message to
the front of the main `Handler` queue, plus a
`flushCompletedTraversalIfNeeded()` check in case `MessageLoopAndroid`
runs inside `MessageQueue.nativePollOnce()` right after `doFrame()`
before that `Handler` message is dispatched).
3. When two transactions on the same `SurfaceControl` do get merged
before a single draw (for example if 3+ frames arrive within one VSync
and coalesce in `QueuedFrame`), the later transaction's buffer
overwrites the earlier one, but Android's `SurfaceComposerClient`
retains both transaction completion callbacks in an `unordered_set` and
can invoke the newer callback before the older, superseded callback.
`AHBSwapchainImplVK` now tracks a monotonic `present_id` so a superseded
callback recycles its own dropped texture into `pool_` instead of
displacing `currently_displayed_texture_`.

---------

Co-authored-by: Gray Mackall <[email protected]>