-
Notifications
You must be signed in to change notification settings - Fork 29.7k
rectMoreOrLess equals, prep for 64bit rects #30942
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
Conversation
| /// | ||
| /// See also: | ||
| /// | ||
| /// * [moreOrLessEquals], which is for [double]s. |
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.
See also within. Because within also supports Rect let's make sure their behavior is consistent.
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.
Also, why can't we use within?
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 looks like we could, but it seems confusing. reading something like expect(find.byKey(fabKey).getRect(), within(Rect.fromLTRB(...)) makes me think we expect the fab rect to be smaller - whereasrectMoreOrLessEquals reads a little more clearly IMHO
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.
SGTM
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.
But let's make sure the two are more or less (:wink:) consistent.
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.
Can rectMoreOrLessEquals internally just defer to within to ensure they are consistent?
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.
That works for me. I'm trying to figure out why the semantics traversal test is behaving differently on different platforms right now.
|
We will have to update the |
|
LGTM, see also #31333 |
Description
flutter/engine#8524 had to be reverted because the increased precision fixed some issues, but caused our tests to fail for others.
In paritcular, FloatingActionButton animations involve a transform that gets very slightly translated. After going through various matrix multiplications, there's a slight loss of precision now that's captured by a double backed
Rect. That's resolved with a new matcher calledrectMoreOrLessEquals, which works likemoreOrLessEquals.The semantics change is because the rect also has more precision, and when that extra precision is pumped through to
SizedBoxit causes a failure. I'm hoping @yjbanov or @goderbauer can validate that this is safe - it seems so to me but I may be missing a bug in the semantics traversal algorithm.Related Issues
Fixes #30920
Allows us to reland flutter/engine#8524 (or something similar to it).
Tests
I added the following tests:
New tests for
rectMoreOrLessEquals.Updated tests in preparation for increased precision in
Rects.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.///).flutter analyze --flutter-repo) does not report any problems on my PR.Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?