Reland 2 (part 2): Enforce the rule of calling FlutterView.Render
#47095
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 or stuartmorgan on the #hackers channel in Chat (don't just cc them here, they won't see it! Use 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. |
| if (validRender) { | ||
| _render(scene as _NativeScene); | ||
| } | ||
| } |
There was a problem hiding this comment.
Summarizing conversation with @dkwingsmt: we suspect that dropping invalid renders is what caused the performance regression. This reland only drops invalid renders in debug mode, we expect that the performance test will be unaffected now. @dkwingsmt will run a perf test once this lands to verify this.
Ideally our render rule enforcement would be stricter. Ideally invalid renders would trigger assertion errors on debug mode and would be dropped in release mode. However, this causes significant unit tests failures. We should consider doing this after we've confirmed performance is unaffected by this change.
Original code which would dropped invalid render calls on release mode as well: https://github.com/dkwingsmt/engine/blob/e266da1854fc9e3e972e562e9c7d97e73eb738c6/lib/ui/window.dart#L356-L363
dkwingsmt
added
the
autosubmit
…136928) flutter/engine@3b0469b...503b842 2023-10-19 dkwingsmt@users.noreply.github.com Reland 2 (part 2): Enforce the rule of calling `FlutterView.Render` (flutter/engine#47095) 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 jimgraham@google.com,rmistry@google.com,zra@google.com 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://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
…47095) This PR relands part of #45300, which was reverted in #46919 due to performance regression. Due to how little and trivial production code the original PR touches, I really couldn't figure out the exact line that caused it except through experimentation, which requires changes to be officially landed on the main branch. After this PR lands, I'll immediately fire a performance test. This PR contains the render rule check performed by `PlatformDispatcher` of the original PR, the remaining changes to production code besides [the part 1](#47062). Since part 1 shows no regression, the changes of this PR is highly likely to be the culprit. Therefore I made some changes: The rule enforcement is no longer performed in release mode, but only in debug mode. This will cause behavior deviation between builds, but since the developer should be able to notice violation in debug mode anyway, I think this design is acceptable. It is intentional to not contain any unit tests or other changes of the original PR. They will be landed shortly after this PR. Part of flutter/flutter#136826. [C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR relands part of #45300, which was reverted in #46919 due to performance regression.
Due to how little and trivial production code the original PR touches, I really couldn't figure out the exact line that caused it except through experimentation, which requires changes to be officially landed on the main branch. After this PR lands, I'll immediately fire a performance test.
This PR contains the render rule check performed by
PlatformDispatcherof the original PR, the remaining changes to production code besides the part 1. Since part 1 shows no regression, the changes of this PR is highly likely to be the culprit. Therefore I made some changes: The rule enforcement is no longer performed in release mode, but only in debug mode. This will cause behavior deviation between builds, but since the developer should be able to notice violation in debug mode anyway, I think this design is acceptable.It is intentional to not contain any unit tests or other changes of the original PR. They will be landed shortly after this PR.
Part of flutter/flutter#136826.
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.