[Impeller] iOS/macOS: Only wait for command scheduling prior to present (redux) #41501
Conversation
|
It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact Hixie on the #hackers channel in Chat (don't just cc him here, he won't see it! He's on Discord!). If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
|
FYI @chinmaygarde, this returned to the original plan of forcing one |
|
This PR results in the same issue I ran into when I just removed the waitUntilScheduled - the artifact discovery popup on wonderous doesn't show up. |
|
(From local testing) |
bdero
force-pushed
the
bdero/unmerge-fix
branch
2 times, most recently
from
00d978e to
58b59d3
Compare
Hmm, this behavior seems to be happening for me at HEAD, without these changes? |
|
Uh oh. I must be on an older commit in flutter/flutter, guess its time to bisect |
|
|
|
Fixed the artifact discovery problem here: #41509 |
bdero
force-pushed
the
bdero/unmerge-fix
branch
from
58b59d3 to
1162035
Compare
…r to present (redux) (flutter/engine#41501)
…125578) flutter/engine@f2882af...cf97541 2023-04-26 [email protected] Migrate Windows AOT Engine to Engine V2. (flutter/engine#41515) 2023-04-26 [email protected] [Impeller] Store the root stencil on iOS (flutter/engine#41509) 2023-04-26 [email protected] [Impeller] iOS/macOS: Only wait for command scheduling prior to present (redux) (flutter/engine#41501) 2023-04-26 [email protected] [Impeller] removed collisions of dead command pools between tests. (flutter/engine#41490) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC [email protected],[email protected],[email protected] on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
2 participants
Reverts #40895.
Resolves flutter/flutter#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.
presentsWithTransactionworks whether theCATransactionstack is empty or not, and so the only difference here is thatpresentsWithTransactionis always turned on andpresentDrawableis always avoided (otherwise it tries to present too early and nothing renders when platform views are present).