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
Request DartPerformanceMode.latency
during transitions
#110600
Conversation
Is there a way to ignore a test file for web platform? |
|
The problem is a compile error, ui.DartPerformanceMode is missing members on the web implementation. You'll need to add those in before this can land - and also file a bug for the API verification check missing it. |
Done: flutter/engine#35806 |
Once that rolls, you won't need to skip this on the web since its just a no-op there |
/// Even if the result is `true`, the engine may choose to ignore the request or | ||
/// the performance mode may not be guaranteed to be the one requested. | ||
/// | ||
/// If conflicting requests are made, only the first request will be honored. |
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 the first? Shouldn't it be the "highest" one?
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.
This was the situation I was trying to guard against:
- C1 requests
latency
mode, and it is activated. - C2 requests
throughput
mode, we will deny this request, and not record the request anywhere.
In the current design, the primary situation I'm concerned with is the transitions requesting latency
mode. if there are multiple conflicting requests, I am not adding them to any queue, only one of two things are supported now:
- If no performance mode request is active, a component can request a specific performance mode.
- If a performance mode
P
is active, another component can extend the lease on onlyP
until dispose is called.
I think supporting a queue of requests is not necessary for the use-case that I'm solving. Hope this answers #110600 (comment) as well.
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 see. Can you document that behavior on the method? And we can also simplify the implementation then. We only need to keep track of the active mode and how many handles we have given out for it. No need to imply with the implementation that we can keep track of different modes.
Also, as a side effect this means if somebody where to request balanced all other requests are blocked, which seems a little odd. When nobody has requested a mode we also run in balanced and we are happy to switch to any other mode.
5a0db7c
to
2973fcb
Compare
2973fcb
to
327c3ec
Compare
@@ -249,6 +257,8 @@ abstract class TransitionRoute<T> extends OverlayRoute<T> { | |||
_animation = createAnimation() | |||
..addStatusListener(_handleStatusChanged); | |||
assert(_animation != null, '$runtimeType.createAnimation() returned null.'); | |||
_performanceModeRequestHandle = | |||
SchedulerBinding.instance.createPerformanceModeRequest(this, ui.DartPerformanceMode.latency); |
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.
nit: indent by two spaces.
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.
It's already indented with 2 spaces, maybe i'm missing something?
/// Even if the result is `true`, the engine may choose to ignore the request or | ||
/// the performance mode may not be guaranteed to be the one requested. | ||
/// | ||
/// If conflicting requests are made, only the first request will be honored. |
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 see. Can you document that behavior on the method? And we can also simplify the implementation then. We only need to keep track of the active mode and how many handles we have given out for it. No need to imply with the implementation that we can keep track of different modes.
Also, as a side effect this means if somebody where to request balanced all other requests are blocked, which seems a little odd. When nobody has requested a mode we also run in balanced and we are happy to switch to any other 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.
LGTM with some nits
/// See also: | ||
/// | ||
/// * [PerformanceModeRequestHandle] for more information on the lifecycle of the handle. | ||
typedef PerformanceModeCleaupCallback = void Function(); |
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.
Since this type isn't used anywhere, it can be a VoidCallback
instead
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.
It is still used in PerformanceModeRequestHandle
, I think this typedef makes it easier to see when this callback will be invoked.
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.
Sorry, I meant that the type is not used in a public APi, so this can be private or use an existing type - right?
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.
Ah right, will change it to private.
Co-authored-by: Jonah Williams <jonahwilliams@google.com>
Co-authored-by: Jonah Williams <jonahwilliams@google.com>
Co-authored-by: Jonah Williams <jonahwilliams@google.com>
eb76fea
to
633d54c
Compare
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 callback is invoked when a request for [DartPerformanceMode] is disposed. | ||
/// | ||
/// See also: | ||
/// | ||
/// * [PerformanceModeRequestHandle] for more information on the lifecycle of the handle. | ||
typedef _PerformanceModeCleaupCallback = VoidCallback; |
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.
You can just delete this and use VoidCallback
directly wherever _PerformanceModeCleaupCallback
is currently used.
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 think it's useful for the reader, makes it easy to understand that this type is called when the performance mode is resolved. Let me know if you feel strongly about it, and I can change it up in a follow-up PR.
This change makes it so that a call is made to request the latency performance mode, added in flutter/engine#35614 during transitions. It is to be noted that any requests made to this are not guaranteed to be honored.
This is an initial version of the change where there are no guardrails against indefinitely requesting the latency performance mode, these will be added as needed in follow-up PRs.