Skip to content
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

Add a Dart FFI method to synchronously render a frame #50492

Closed
wants to merge 3 commits into from

Conversation

dkwingsmt
Copy link
Contributor

This PR adds PlatformDispatcher.imposeSyncFrame.

This function is not used by anyone, nor is implemented by the engine. The usage and implementation should be added by a later PR. The full PR must be verified by a performance test, but the performance test currently has a problem of not being able to recognize local dart:ui changes.

Pre-launch Checklist

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • I read the Tree Hygiene wiki page, which explains my responsibilities.
  • I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
  • I listed at least one issue that this PR fixes in the description above.
  • I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
  • I updated/added relevant documentation (doc comments with ///).
  • I signed the CLA.
  • All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

@flutter-dashboard
Copy link

It looks like this pull request may not have tests. Please make sure to add tests before merging. If you need an exemption to this rule, contact "@test-exemption-reviewer" in the #hackers channel in Chat (don't just cc them here, they won't see it! Use Discord!).

If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix?

Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.

///
/// This method should not be used in usual cases. It is designed for
/// situations that require a frame is rendered as soon as possible, even at
/// the cost of rendering quality.
Copy link
Member

Choose a reason for hiding this comment

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

Can you give the warmup frame as an explicit example here? Some of the verbiage from https://main-api.flutter.dev/flutter/scheduler/SchedulerBinding/scheduleWarmUpFrame.html would fit here as well to motivate that use case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, can you take a look?

// the restriction of the performance test. Eventually, we should either land
// the full changes, or remove this method.
// https://github.com/flutter/flutter/issues/142851
void imposeSyncFrame() => _imposeSyncFrame();
Copy link
Member

Choose a reason for hiding this comment

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

In terms of naming, I favor forceSyncFrame. I do like the Sync in the name, though.

Copy link
Member

Choose a reason for hiding this comment

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

Why not just call it warmUpFrame? or something like that.

Copy link
Contributor Author

@dkwingsmt dkwingsmt Feb 9, 2024

Choose a reason for hiding this comment

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

Why not just call it warmUpFrame? or something like that.

I think "warm up frame" is a more application-level concept and belongs to the scheduler binding, and for PlatformDispatcher it's better to name it with what the developer makes the engine do.

Copy link
Member

Choose a reason for hiding this comment

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

but its only used for a warm up frame, and probably isn't usefulfor anything besides a warm up frame.

Copy link
Contributor Author

@dkwingsmt dkwingsmt Feb 9, 2024

Choose a reason for hiding this comment

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

We're expecting some developers calling the dart:ui package directly instead of going through the framework, who will have their own scheduling scheme and terms. I think it's better to leave room for them on how they use this method. (I've added scheduleWarmUpFrame to the doc as an example, do you think it helps easing your concern?)

Copy link
Member

Choose a reason for hiding this comment

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

But if you don't know what the usages are then its unlikely that you'll be able to design it in such a way as to accomidate them.

Copy link
Contributor Author

@dkwingsmt dkwingsmt Feb 11, 2024

Choose a reason for hiding this comment

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

I've added "used in scheduleWarmUpFrame" to document. Does it feel better?

(Although it's not in the framework yet, this is the PR to add it.)

@jonahwilliams jonahwilliams self-requested a review February 9, 2024 18:25
// the performance test. Eventually, we should either land the full changes,
// or remove this method.
// https://github.com/flutter/flutter/issues/142851
FML_UNREACHABLE();
Copy link
Member

Choose a reason for hiding this comment

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

This is in fact quite reachable. You could error log if you want to discourage calling this method but leaving a process exit accessible from dart:ui does not seem reasonable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This PR has been merged to #49950 because I realized that this PR does not improve the situation alone. Now this method is implemented.

@dkwingsmt
Copy link
Contributor Author

Closing this PR because I realized that this PR alone does not improve our situation. Framework needs the transitional warm up rendering (Animator:: OnAllViewsRendered ) and an implemented forceSyncFrame to switch its code smoothly, so this PR must be merged along with #49950. Discussion can continue in this PR if needed.

@dkwingsmt dkwingsmt closed this Feb 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants