tree a0a2b6bc031621844cf998d9b43dc053e21a8e78
parent e965485fb41878034788c1c55b985ad9df8bb016
author Brandon DeRosier <bdero@google.com> 1682531451 -0700
committer GitHub <noreply@github.com> 1682531451 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkSWR7CRBK7hj4Ov3rIwAACCIIAILCtC7hKeNXWBAxyZympfh0
 aP44/TL8YQxxBoN/naOPXKgVe0o8JOXKRe5QA9wf7RS3NJNhhh58+PNK5jX0OZxA
 YTrcS/A06yWgBnTLcNESpni9+cHCmI9PmgIiLHe94dr4+6vWd/iLQmTpo8XyaFXV
 Tne3qm8FiHa790MD4gnUmpFPbb1doY/p76XwtYH418ATTf0UmbEm0Ntfw8l5zmzP
 3VTLKGfqatA78Y6FAe0Mo9lWNxPlNtvSnnxu6V4NMjxj+7Kn+vQVQunjLCXbC3VD
 tVHaLgiaRS1p4rxdpm59TajLhi3GXPUE9pEjHyUNkFWWomC2h2B2VSACOBU8lQI=
 =jtF6
 -----END PGP SIGNATURE-----
 

[Impeller] iOS/macOS: Only wait for command scheduling prior to present (redux) (#41501)

Reverts https://github.com/flutter/engine/pull/40895.
Resolves https://github.com/flutter/flutter/issues/120399 (again).

A bunch of frames get pumped on the main thread _without a transaction_
just before unmerging occurs (I don't know why this happens), and so
checking the current thread to determine whether we need to present with
a transaction or not isn't sufficient. In the prior fix, after the
unmerge, the raster thread would hang for one second while waiting for
the next drawable to get freed up (happens on the second raster thread
frame post-unmerge), and then subsequent presents would just do nothing
for a while, but eventually recover.

`presentsWithTransaction` works whether the `CATransaction` stack is
empty or not, and so the only difference here is that
`presentsWithTransaction` is always turned on and `presentDrawable` is
always avoided (otherwise it tries to present too early and nothing
renders when platform views are present).