Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

[e2e] Use new FrameTiming constructor. #2914

Closed
wants to merge 3 commits into from

Conversation

ditman
Copy link
Member

@ditman ditman commented Aug 10, 2020

Description

A new FrameTiming constructor was introduced here:
flutter/engine@409a5e5, and now one of the tests in the e2e plugin doesn't compile anymore.

(See here.)

This change updates the test to use the new API.

Related Issues

flutter/engine#20229

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.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (flutter analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
  • I updated CHANGELOG.md to add a description of the change.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • No, this is not a breaking change.

A new FrameTiming constructor was introduced here:
flutter/engine@409a5e5,
so we need to update the test for it to run in newer versions of
flutter.
@ditman ditman requested review from digiter and CareF August 10, 2020 18:41
Copy link
Contributor

@CareF CareF left a comment

Choose a reason for hiding this comment

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

Thank you for the updates! I should have updated this.
The newest version also require a vsyncStart field.

@@ -16,7 +16,12 @@ void main() {
rasterTimes = rasterTimes.reversed.toList();
List<FrameTiming> inputData = <FrameTiming>[
for (int i = 0; i < 100; i += 1)
FrameTiming(<int>[0, buildTimes[i], 500, rasterTimes[i]]),
FrameTiming(
buildStart: 0,
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the updates!
The new constructor introduced vsyncStart. Please use the following (or remove that 50+ and change the following expect accordingly:

        FrameTiming(
          vsyncStart: 0,
          buildStart: 50,
          buildFinish: 50+buildTimes[i],
          rasterStart: 500,
          rasterFinish: rasterTimes[i],
        ),

Copy link
Member Author

@ditman ditman Aug 10, 2020

Choose a reason for hiding this comment

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

I've added vsyncStart: 0 and buildStart: 0. For now the object that this code is testing doesn't seem to use the vsyncStart. I've left a TODO, linked to this issue in the code to revisit this.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good. I can handle this TODO.

Copy link
Contributor

@CareF CareF left a comment

Choose a reason for hiding this comment

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

LGTM

@digiter digiter requested a review from dnfield August 10, 2020 19:37
@dnfield
Copy link
Contributor

dnfield commented Aug 10, 2020

We should unbreak this upstream

@ditman
Copy link
Member Author

ditman commented Aug 10, 2020

I expect this to break test CHANNEL:stable. If it does, the engine change needs to be reverted / made backwards-compatible.

@CareF
Copy link
Contributor

CareF commented Aug 10, 2020

This feature doesn't have to be in e2e: we were considering it somewhere in the framework or the engine but was thinking that e2e is most relevant. But it seems that this is a very strong argument against this decision.

@ditman
Copy link
Member Author

ditman commented Aug 10, 2020

Tests appear to be vvvvery slow. I'll close this, because this is not the fix we need.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants