-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Fix the first frame logic in tracing and driver #35297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
7a75868 to
247424c
Compare
gaaclarke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with the profiling code but it LGTM except for my comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this happening after the frame has been presented or rasterized? The language of this PR is talking about rasterization but what I found out is that what I was really interested in is not when the frame was rasterized but when it was presented, which is a subtle difference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll revise the language to make it clear that:
- We're only waiting for rasterization
- Usually, the time that a frame is rasterized is very close to the time that it gets presented. Specifically, rasterization is the last expensive phase of a frame that's still in Flutter's control.
|
Ping @Hixie and @goderbauer |
goderbauer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have all the context to properly review this, maybe @Hixie can also take a look?
dev/devicelab/manifest.yaml
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why mark so many as flaky? Isn't this just changing the behavior of only the transition test for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although this test doesn't wait for the first frame, the way that we measure the start_up time changes. Hence I marked all start_up tests to be flaky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there value in doing all of this in release mode? Or should this be guarded to only profile and debug mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this to release mode so _firstFrameCompleter and thus WidgetsBinding.firstFrameRasterized is available in the release mode. It might be useful to handle the splash screen during add2app?
|
@goderbauer : do my answers solve your concerns? |
dnfield
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I'm hoping we can pretty quickly determine if this test actually causes flakes or not and either revert or mark as not flaky.
499aa82 to
e4454fc
Compare
Codecov Report
@@ Coverage Diff @@
## master #35297 +/- ##
==========================================
- Coverage 55.31% 54.23% -1.08%
==========================================
Files 190 190
Lines 17590 17589 -1
==========================================
- Hits 9730 9540 -190
- Misses 7860 8049 +189
Continue to review full report at Codecov.
|
|
Adding @jonahwilliams as the reviewer as rebasing the PR to the head of master triggers the tool codecov tests. Ping @goderbauer for the overall review. If there's no objection, I'll land this soon to start measuring our first frame latency correctly. |
|
You can ignore the codecov bot - it's not quite working. |
|
It is correct in that the tools code here is not covered by tests. I think we've decided that its not the responsibility of contributors making small changes to rewrite the tools to be testable |
goderbauer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This reverts commit 68fc723.
|
For posterity, this was reverted because it was breaking Flutter devicelab tests |
…ter#35297)" (flutter#37027)" This reverts commit 3068fc4.
…" (flutter#37027) This reverts commit 68fc723.
…7192) This relands #35297 The followings have been done to fix the broken tests: 1. Add `didSendFirstFrameRasterizedEvent` extension and its tests 2. Wait for `didSendFirstFrameRasterizedEvent` instead of `didSendFirstFrameEvent` during start up tests 3. Mark missed (probably newly added) start up tests as flaky
|
@liyuqian Can we mark the previously existing tests non-flaky again and/or revert this PR? We can't be having these critical benchmarks be considered ok-to-break. |
|
@Hixie : please see #37192 (comment) |
This should fix #31442 and #34867