Annotate code with coordinate system information #313
Merged
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 pull-request should contain no functional changes. It is only meant to annotate various methods and attributes with explicit information about whether logical or physical pixels are being used.
The current usage patterns have been used to determine whether to mark existing code as dealing with physical or logical coordinates.
This is part of a larger set of changes that are meant to add HighDPI support for Wayland.
Naming conventions
The
_px
and_dip
suffixes are sometimes used for variables depending on whether their data represents physical or logical pixels respectively. Obviously, this is not strictly necessary but it does make it easier to differentiate between the two when writing code that deals with both coordinate systems.In Wayland terms, buffer coordinates correspond to physical pixels and surface coordinates correspond to logical pixels. Usually the relationship between the two is:
buffer_size = surface_size x output_scale
.Note: I agree to delegate all rights related to this PR to Sony.