Optimize the transformRect and transformPoint methods in matrix_utils… #37275
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR reintroduces the changes from PR #36396 that were reverted
because the calculations would turn a rect that spanned from -maxFinite
to maxFinite into an infinite result rect.
The revert included a new test for infinite rects. I renamed the description
of that test to more closely reflect what was being tested, but it now passes
with the new fix (and the full tests were all run with the test for infinite size
hardcoded to "true" so the new path accurately passes all existing tests for
matrix transformation even though it is rarely executed).
The new fix now checks if the width or height of the rect is infinite and backs
off to a safer version of the transform operation that more closely matches
what used to be done, but eliminates unnecessary operations.
The tests cost a few percentage points regression from the original fix to check
the size of the rect and even if the slow but safe path is taken, it is still about
twice as fast as the original code.
The results below exercise only the optimized affine and perspective paths,
but if you hard-code the test for infinite rects to just "true", you can see the
results for the slow path which are generally about twice as fast as the original
code and maybe 25-50% slower than the fast paths.
Here is the original commit message with some updated numbers:
Primarily these methods no longer allocate any objects other than their
return values.
Additionally, the math in the methods is reduced compared to the general
case math based on known input conditions.
Results from a Moto E2 phone...
Before:
After original fix:
After new fix:
Results from a Samsung Note 9:
Before
After original fix:
After new fix: