Skip to content

Conversation

@liyuqian
Copy link
Contributor

This should fix #31442 and #34867

@Piinks Piinks added engine flutter/engine related. See also e: labels. framework flutter/packages/flutter repository. See also f: labels. c: performance Relates to speed or footprint issues (see "perf:" labels) c: contributor-productivity Team-specific productivity, code health, technical debt. labels Jul 1, 2019
Copy link
Member

@gaaclarke gaaclarke left a 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.

Copy link
Member

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.

Copy link
Contributor Author

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:

  1. We're only waiting for rasterization
  2. 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.

@liyuqian
Copy link
Contributor Author

liyuqian commented Jul 8, 2019

Ping @Hixie and @goderbauer

Copy link
Member

@goderbauer goderbauer left a 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?

Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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?

Copy link
Contributor Author

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?

@liyuqian
Copy link
Contributor Author

@goderbauer : do my answers solve your concerns?

Copy link
Contributor

@dnfield dnfield left a 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.

@codecov
Copy link

codecov bot commented Jul 24, 2019

Codecov Report

Merging #35297 into master will decrease coverage by 1.07%.
The diff coverage is 16.66%.

Impacted file tree graph

@@            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
Flag Coverage Δ
#flutter_tool 54.23% <16.66%> (-1.08%) ⬇️
Impacted Files Coverage Δ
packages/flutter_tools/lib/src/tracing.dart 1.88% <16.66%> (-0.04%) ⬇️
...lutter_tools/lib/src/build_system/targets/ios.dart 0% <0%> (-100%) ⬇️
packages/flutter_tools/lib/src/compile.dart 31.56% <0%> (-43.53%) ⬇️
packages/flutter_tools/lib/src/commands/run.dart 19.13% <0%> (-41.63%) ⬇️
...ckages/flutter_tools/lib/src/commands/devices.dart 53.84% <0%> (-23.08%) ⬇️
...tter_tools/lib/src/build_system/targets/macos.dart 64.7% <0%> (-11.77%) ⬇️
packages/flutter_tools/lib/src/run_cold.dart 0% <0%> (-10.39%) ⬇️
...ackages/flutter_tools/lib/src/resident_runner.dart 45.18% <0%> (-8.04%) ⬇️
packages/flutter_tools/lib/src/base/utils.dart 87% <0%> (-7.5%) ⬇️
packages/flutter_tools/lib/src/version.dart 93.1% <0%> (-2.47%) ⬇️
... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa6384c...e4454fc. Read the comment docs.

@liyuqian liyuqian requested a review from jonahwilliams July 24, 2019 19:36
@liyuqian
Copy link
Contributor Author

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.

@dnfield
Copy link
Contributor

dnfield commented Jul 24, 2019

You can ignore the codecov bot - it's not quite working.

@jonahwilliams
Copy link
Contributor

jonahwilliams commented Jul 24, 2019

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

Copy link
Member

@goderbauer goderbauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@liyuqian liyuqian merged commit 68fc723 into flutter:master Jul 26, 2019
jonahwilliams pushed a commit that referenced this pull request Jul 26, 2019
jonahwilliams pushed a commit that referenced this pull request Jul 26, 2019
@tvolkert
Copy link
Contributor

For posterity, this was reverted because it was breaking Flutter devicelab tests

liyuqian added a commit to liyuqian/flutter that referenced this pull request Jul 29, 2019
johnsonmh pushed a commit to johnsonmh/flutter that referenced this pull request Jul 30, 2019
johnsonmh pushed a commit to johnsonmh/flutter that referenced this pull request Jul 30, 2019
liyuqian added a commit that referenced this pull request Jul 31, 2019
…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 liyuqian deleted the fix_first_frame branch August 7, 2019 16:58
@Hixie
Copy link
Contributor

Hixie commented Aug 25, 2019

@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.

@liyuqian
Copy link
Contributor Author

@Hixie : please see #37192 (comment)

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

c: contributor-productivity Team-specific productivity, code health, technical debt. c: performance Relates to speed or footprint issues (see "perf:" labels) engine flutter/engine related. See also e: labels. framework flutter/packages/flutter repository. See also f: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

flutter driver tests need to know when the GPU thread finishes rendering the first frame

9 participants