fix widget built twice during warm up frame#39079
Conversation
There was a problem hiding this comment.
I might as well create an api to just schedule attachRootWidget and flutter test can override this api. This might make it more clean, but I am not sure if it worth to expose an api for that
There was a problem hiding this comment.
since it is no longer possible to dirty thing in the middle of warm up frame, I have to change the way to reproduce double builds. if we are ok to remove the null check in nestedscrollview, we can remove this test as well
There was a problem hiding this comment.
I intend to keep this check as there might be other corner case that hit this, but i cannot think of any now.
There was a problem hiding this comment.
Turn these into asserts then?
There was a problem hiding this comment.
testerbinding is no longer overriding scheduleWarmUpFrame, there is no point to test it?
There was a problem hiding this comment.
reminding myself, we can add this back since I decide to keep the override
There was a problem hiding this comment.
this shouldn't be private, and it should be documented (and @Protected)
|
This will definitely have to go through the breaking change announcement process. Might be worth trying to run it through the internal Google test suite and see how many things we break there, too, to get an idea of how much breakage this will cause. |
goderbauer
left a comment
There was a problem hiding this comment.
Great debugging to figure this out!
Can you throw the "breaking change" label on here and sent out an announcement?
There was a problem hiding this comment.
Turn these into asserts then?
|
Looks like there are some tests on cirrus that were supposed to fail, but they are now passing. |
goderbauer
left a comment
There was a problem hiding this comment.
This looks good, but we should announce it as a breaking change and as Hixie pointed out, it may be good to run this through Google's internal test suite to see what breaks there.
There was a problem hiding this comment.
... attaches the root widget...
|
@kpsroka FYI |
|
internal test suite passed, breaking change email sent. |
goderbauer
left a comment
There was a problem hiding this comment.
LGTM
Probably good to wait until next week with submission to give people some time to respond to the breaking change.
There was a problem hiding this comment.
nit: I would probably remove the see also here since the sentence above just said the same thing.
2f77a48 to
53a3a7f
Compare
53a3a7f to
a8aebfc
Compare
|
Was there a breaking change announcement for this change? If so, @chunhtai will you please link it here? |
|
|
Thanks! |
Description
The runapp work as follow
1, build rendering tree
2, schedule warm up frame
...(async gap)
3, run async draw frame
There is a chance engine will flush user setting in the middle of 2 and 3 which will dirty rendering tree. and draw frame will have to rebuild the rendering tree
With this pr the runapp work as follow
1, schedule build rendering tree
2, schedule warm up frame
...(async gap)
3, run async build rendering tree
4, run async draw frame
In this case, it does not matter whether something try to dirty render tree in the middle of 2 and 3 as there is no rendering tree to dirty.
This will however affect flutter test since it override schedulewarmup frame to be synchronized function to make sure runapp run synchronously. To addjust that, I implements a private runapp that flush timer after the regular runapp and removed the schedulewarmup override.
I do not use the callback solution we talked about @Hixie @goderbauer since that will create code duplication in flutter test binding and widgetflutterbinding. However, this approach might be a bigger breaking change for people who work directly with binding.
Related Issues
#31195
Tests
I added the following tests:
'WidgetBinding build rendering tree and warm up frame back to back'
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]). This will ensure a smooth and quick review process.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?