-
Notifications
You must be signed in to change notification settings - Fork 6k
Dynamic view sizing [dart:ui] #48090
Conversation
b195365 to
a6e7539
Compare
|
Quick note: The framework tests are failing until flutter/flutter#138565 is submitted to the framework to prepare for this PR. |
4ac52a2 to
dc20c1e
Compare
| final double devicePixelRatio; | ||
|
|
||
| /// The size requested for the view in logical pixels. | ||
| /// The size requested for the view in physical pixels. |
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.
How did we find out this should be physical instead of logical? Is it a bug fix or a behavior change?
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.
The value was always in physical pixels, it was just documented wrong. Luckily, it is a doc comment on a private class, so the doc was never actually public.
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.
Backup evidence that this has always been in physical pixels and we just documented it wrong: This value is returned by the physicalSize getter on FlutterView:
Line 163 in dba80be
| Size get physicalSize => _viewConfiguration.size; |
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've found Physical vs Logical pixels is painful in the web, especially if one trusts the docs :P
ditman
left a comment
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!
(Here's the changes I did to get web support)
dkwingsmt
left a comment
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
6649419 to
31f6762
Compare
| }); | ||
|
|
||
| /// Creates view constraints that is respected only by the given size. | ||
| ViewConstraints.tight(Size size) |
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 can't this be const?
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.
size.width and size.height are invalid constant values, according to Dart (In theory, they could be getters that do some crazy computation using information only available at runtime.). Since they are used in the initializer list below, the constructor cannot be const, sadly.
(Same applies to the existing BoxConstraints.tight constructor)
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.
Ahh, right, makes sense. Too bad there's no way to make a final property not be overridable with a getter.
Towards #134501. Required to roll flutter/engine#48090 into the framework. **DO NOT SUBMIT until #138648 and flutter/engine#48090 are ready.**
31f6762 to
34ae397
Compare
|
auto label is removed for flutter/engine/48090, due to - The status or check suite Linux Framework Smoke Tests has failed. Please fix the issues identified (or deflake) before re-applying this label. |
| /// | ||
| /// At startup, the constraints for the view may not be known before Dart code | ||
| /// runs. If this value is observed early in the application lifecycle, it may | ||
| /// report constraints with all dimensions set to zero. |
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.
Does "constraints with all dimensions set to zero" mean the resulting size must be 0? I don't know if this sentence needs to be said, because the sentence alone feels important on the surface but it's really just a temporary state. And the constraints are less like "known" but more like "set" by the engine.
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.
Yes, it means the only size allowed will be zero. It matches what was previously documented on physicalSize.
| /// This value does not take into account any on-screen keyboards or other | ||
| /// system UI. If the constraints are tight, the [padding] and [viewInsets] |
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.
Does "not take into account" mean the size include or exclude these system UI? I think "include/exclude" will be clearer.
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 is using the same terms we use on physicalSize to document the same thing). I find include/exclude more confusing because it depends on your perspective whether the padding is included or excluded.
| /// be obscured by system UI. If the constraints are loose, this information | ||
| /// is not known upfront. |
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.
What do you mean by "this information is not known"? Shall we just assert that only tight constraints can have non-zero padding and insets?
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 is basically describing platform limitations. No platform currently makes it possible to know this information upfront, but in theory a platform could provide it.
Towards #134501. Required to roll flutter/engine#48090 into the framework. Two new subclasses of FlutterView were added recently for testing (in #138849) that I missed in my previous PR (#138565).
Co-authored-by: David Iglesias <ditman@gmail.com>
Co-authored-by: David Iglesias <ditman@gmail.com>
Co-authored-by: David Iglesias <ditman@gmail.com>
34ae397 to
92a4dd2
Compare
…139103) flutter/engine@0a098bd...2be7191 2023-11-27 goderbauer@google.com Dynamic view sizing [dart:ui] (flutter/engine#48090) 2023-11-27 dnfield@google.com Roll shaderc to google/shaderc@37e2553 (flutter/engine#48415) 2023-11-27 skia-flutter-autoroll@skia.org Roll Skia from 4c964f8c4738 to 600986ba305d (6 revisions) (flutter/engine#48419) 2023-11-27 1961493+harryterkelsen@users.noreply.github.com [canvaskit] Enable multiview rendering (flutter/engine#48301) 2023-11-27 30870216+gaaclarke@users.noreply.github.com [Impeller] updated gaussian blur tests to use device private textures (flutter/engine#48417) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC jacksongardner@google.com,rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Towards #134501. This change is based on flutter/engine#48090. It changes the `RenderView` to be dynamically sized based on its content if the `FlutterView` it is configured with allows it (i.e. the `FlutterView` has loose `FlutterView.physicalConstraints`). For that, it uses those `physicalConstraints` as input to the layout algorithm by passing them on to its child (after translating them to logical constraints via the device pixel ratio). The resulting `Size` that the `RenderView` would like to be is then communicated back to the engine by passing it to the `FlutterView.render` call. Tests will fail until flutter/engine#48090 has rolled into the framework.
Towards flutter#134501. Required to roll flutter/engine#48090 into the framework. **DO NOT SUBMIT until flutter#138648 and flutter/engine#48090 are ready.**
Towards flutter#134501. Required to roll flutter/engine#48090 into the framework. Two new subclasses of FlutterView were added recently for testing (in flutter#138849) that I missed in my previous PR (flutter#138565).
…lutter#139103) flutter/engine@0a098bd...2be7191 2023-11-27 goderbauer@google.com Dynamic view sizing [dart:ui] (flutter/engine#48090) 2023-11-27 dnfield@google.com Roll shaderc to google/shaderc@37e2553 (flutter/engine#48415) 2023-11-27 skia-flutter-autoroll@skia.org Roll Skia from 4c964f8c4738 to 600986ba305d (6 revisions) (flutter/engine#48419) 2023-11-27 1961493+harryterkelsen@users.noreply.github.com [canvaskit] Enable multiview rendering (flutter/engine#48301) 2023-11-27 30870216+gaaclarke@users.noreply.github.com [Impeller] updated gaussian blur tests to use device private textures (flutter/engine#48417) If this roll has caused a breakage, revert this CL and stop the roller using the controls here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll Please CC jacksongardner@google.com,rmistry@google.com,zra@google.com on the revert to ensure that a human is aware of the problem. To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose To report a problem with the AutoRoller itself, please file a bug: https://issues.skia.org/issues/new?component=1389291&template=1850622 Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
Towards flutter#134501. This change is based on flutter/engine#48090. It changes the `RenderView` to be dynamically sized based on its content if the `FlutterView` it is configured with allows it (i.e. the `FlutterView` has loose `FlutterView.physicalConstraints`). For that, it uses those `physicalConstraints` as input to the layout algorithm by passing them on to its child (after translating them to logical constraints via the device pixel ratio). The resulting `Size` that the `RenderView` would like to be is then communicated back to the engine by passing it to the `FlutterView.render` call. Tests will fail until flutter/engine#48090 has rolled into the framework.
Towards flutter/flutter#134501.
This PR makes the following changes to the public dart:ui API:
FlutterView.pysicalConstraintsproperty that describes max and min width and height for a view. The framework is allowed to size theFlutterViewto anySizethat meets these constraints.sizeargument toFlutterView.render. The framework provides the chosenSizethat meets the aforementioned constraints to therendermethod. If theFlutterView.pysicalConstraintsare tight (minHeight == maxHeight and minWidth == maxWidth) the argument is optional to remain backwards compatible. In all other cases, aSizemust be provided.ViewConstraintsclass, which is basically thedart:uiversion ofBoxConstraints(This is similar to how we haveViewPaddingin dart:ui to mirrorEdgeInsetsfrom the framework). It describes the constraints of aFlutterView, i.e. it powers theFlutterView.pysicalConstraintsproperty.This change does not wire anything up to the embedders. For now,
FlutterView.pysicalConstraintsjust returns tight constraints for the embedder-provided size of the view (FlutterView.physicalSize) and the size provided toFlutterView.renderis ignored (after it is checked that it meets the constrains).This PR enables the framework to implement the new dynamic view sizing and embedders to separately expose the new functionality to their clients.
Presubmits will fail until flutter/flutter#138565 is submitted to the framework.
DO NOT SUBMIT until flutter/flutter#138648 is ready.