This repository was archived by the owner on Feb 25, 2025. It is now read-only.
rename the DL bounds accumulation methods to be more transparent #30484
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gw280
approved these changes
Dec 23, 2021
flar
added
the
waiting for tree to go green
chinmaygarde
added a commit
to chinmaygarde/flutter_engine
that referenced
this pull request
Dec 24, 2021
No functional change. Makes the display list subsystem easier to navigate as the major classes are in their own TUs. Also avoids importing unnecessary headers when the previous kitchen sink header was imported. I've tried to remove all display list related imports and start from scratch but I may have missed some files. Minor structs and classes (like the ones in utils, ops, etc..) still don't get their own TUs though. There were [two](flutter#29562) [related](flutter#30484) changes being made to this subsystem that have since landed. So I don't think I am stepping on anyones toes with the reorganization. Happy to incorporate any work-in-progress changes being made to the this subsystem before submitting.
engine-flutter-autoroll
added a commit
to engine-flutter-autoroll/flutter
that referenced
this pull request
Dec 24, 2021
chinmaygarde
added a commit
to chinmaygarde/flutter_engine
that referenced
this pull request
Dec 28, 2021
No functional change. Makes the display list subsystem easier to navigate as the major classes are in their own TUs. Also avoids importing unnecessary headers when the previous kitchen sink header was imported. I've tried to remove all display list related imports and start from scratch but I may have missed some files. Minor structs and classes (like the ones in utils, ops, etc..) still don't get their own TUs though. There were [two](flutter#29562) [related](flutter#30484) changes being made to this subsystem that have since landed. So I don't think I am stepping on anyones toes with the reorganization. Happy to incorporate any work-in-progress changes being made to the this subsystem before submitting.
chinmaygarde
added a commit
that referenced
this pull request
Dec 28, 2021
…30487) No functional change. Makes the display list subsystem easier to navigate as the major classes are in their own TUs. Also avoids importing unnecessary headers when the previous kitchen sink header was imported. I've tried to remove all display list related imports and start from scratch but I may have missed some files. Minor structs and classes (like the ones in utils, ops, etc..) still don't get their own TUs though. There were [two](#29562) [related](#30484) changes being made to this subsystem that have since landed. So I don't think I am stepping on anyones toes with the reorganization. Happy to incorporate any work-in-progress changes being made to the this subsystem before submitting.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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 change is mostly cosmetic to reduce confusion in the future. When I saw the code in
BoundsCalculator::restoreI thought it was a bug because it was modifying the bounds bykSaveLayerFlags, but it turns out that constant doesn't set any flags and so the bounds were not being modified by the current attributes so there was no bug there and it was a trick question.The test case here actually passes without the code changes because there was never a bug, I added it just to verify the condition that I was worried about.
To prevent future "Oh no!" moments I renamed the bounds accumulation methods to hopefully be a little clearer, I added doc comments to them, and I broke out the code that records a simple bounds from the code that records an attribute-modified bounds. The new comment in
restore()should hopefully be clearer about what is going on.(A string description change for a couple of the DL_canvas tests got included here. It is harmless, but I noticed the description was wrong a few days ago and the change got incorporated here...)