[e2e] Use new FrameTiming constructor.

[ditman]

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.

[CareF]

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

[CareF]

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],
        ),

[ditman]

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.

[CareF]

Sounds good. I can handle this TODO.

[CareF]

LGTM

[dnfield]

We should unbreak this upstream

[ditman]

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

[CareF]

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]

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