-
Notifications
You must be signed in to change notification settings - Fork 27.2k
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
TextField border gap padding improvement #92940
Conversation
… doesnt break other cases
@@ -418,12 +418,11 @@ class OutlineInputBorder extends InputBorder { | |||
|
|||
const double cornerArcSweep = math.pi / 2.0; | |||
final double tlCornerArcSweep = start < scaledRRect.tlRadiusX | |||
? math.asin((start / scaledRRect.tlRadiusX).clamp(-1.0, 1.0)) | |||
? math.acos(1 - start / scaledRRect.tlRadiusX) |
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.
Here's the PR where this line originally came from: #34515. The new calculation appears to work for that case 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.
A suggestion
final double tlCornerArcSweep = math.acos((1 - start / scaledRRect.tlRadiusX).clamp(0.0, 1.0));
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.
Thanks, I was worried about not having the clamp in there anymore. Will try it now.
@@ -432,7 +431,7 @@ class OutlineInputBorder extends InputBorder { | |||
const double trCornerArcSweep = cornerArcSweep; | |||
if (start + extent < scaledRRect.width - scaledRRect.trRadiusX) { | |||
path | |||
..relativeMoveTo(extent, 0.0) | |||
..moveTo(scaledRRect.left + start + extent, scaledRRect.top) |
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 change and the previous changes near line 425 make the gap the correct width. Before, it was too wide.
Gold has detected about 2 new digest(s) on patchset 1. |
The broken goldens are practically unnoticeable 1 pixel differences, so that's good. I'll plan to just accept those once I finalize this PR. I should also run the Google tests on this and watch out for breaking other visual diff tests. |
I have raised a pull request on your fork with the working solution I wrote. See if that help 😬. |
Gold has detected about 2 new digest(s) on patchset 3. |
Correct math for top left and top right border corners
Gold has detected about 4 new digest(s) on patchset 6. |
Gold has detected about 12 new digest(s) on patchset 8. |
Gold has detected about 12 new digest(s) on patchset 9. |
Gold has detected about 1 new digest(s) on patchset 10. |
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). If you are still iterating on this change and are not ready to resolve the images on the Flutter Gold dashboard, consider marking this PR as a draft pull request above. You will still be able to view image results on the dashboard, commenting will be silenced, and the check will not try to resolve itself until marked ready for review. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
I've accepted the goldens changes, which as I expected were just two unnoticeable 1 pixel color changes plus the new golden tests I created. |
I ran the Google test and got a few failures, but they were all the same as the goldens: a pixel or two that's a slightly different color. I'll change it to pass and plan to accept the changes after merge. |
? math.asin((start / scaledRRect.tlRadiusX).clamp(-1.0, 1.0)) | ||
: math.pi / 2.0; | ||
final double tlCornerArcSweep = math.acos( | ||
(1 - start / scaledRRect.tlRadiusX).clamp(0.0, 1.0), |
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.
question: is it guaranteed that the radiusX can't be 0?
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.
Good catch. I just tried this out and it can in fact be zero, but the clamp will make sure that it gets back on track and the behavior is correct. No errors are thrown.
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.
TIL! So NaN.clamp(0, 1) == 1
? But shouldn't the 1 - NaN
be evaluated first and throw an error?
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.
turns out, 1 - NaN = -NaN
. So it finally clamps to 0.0.
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.
And 1/0
is actually Infinity
in Dart and not NaN
, so it makes a little more sense.
Previously, the calculations for the border gap weren't quite right in all cases, and would sometimes result in extra unwanted padding. Here's an example where gapPadding is set to zero, meaning that the border should just touch the label, but it didn't:
With this PR, the same code gives the correct result:
Todos
Related issues
Fixes #82321
Old PR that may have caused this bug: #34515