Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:
[x] I've formatted my code according to Natron's code style
[x] I've searched the pull requests tracker to ensure that this PR is not a duplicate
PR Description
What type of PR is this? (Check one of the boxes below)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Improvement (non-breaking change which does not add functionality nor fixes a bug but improves Natron in some way)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
What does this pull request do?
This change refactors RenderScale so that much of the code that uses it is much simpler. It also makes it much more explicit that Natron does not actually allow/support the x & y scale to be different from each other. Functionally this should be equivalent to the existing code and no new functionality was added.
Moved RenderScale declaration to its own file.
Removed inheritance from OfxPointD so implementation could be changed.
Made data members private to hide implementation and created helper methods to capture common use patterns.
Change TrackerNodeInteract::selectedMarkerScale to a double since it didn't really need to be a RenderScale.
Added named constant for RenderScale with x & y set to 1.
Changed the underlying implementation from a pair of doubles to an unsigned int that stores the mipmapLevel.
Have you tested your changes (if applicable)? If so, how?
Yes. I've tested this locally with a few project files. The unit tests all pass locally and in the GitHub Actions.
Futher details of this pull request
This came about mainly from me trying to understand why mipmapLevels and RenderScales were being passed around to different APIs and sometimes both were passed together. There also appeared to be more conversions to/from mipmapLevel then actual use of the doubles so it seemed to make sense to just convert the underlying representation to the mipmapLevel. I suspect further simplifications can be made in follow up changes and some usage of RenderScale can go away or be replaced with the equivalent mipmapLevel parameter. This change was just intended to leave the existing abstraction in place, but make the API more explicit and constrained.
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request. Additionally, make sure you've done all of these things:
PR Description
What type of PR is this? (Check one of the boxes below)
What does this pull request do?
This change refactors RenderScale so that much of the code that uses it is much simpler. It also makes it much more explicit that Natron does not actually allow/support the x & y scale to be different from each other. Functionally this should be equivalent to the existing code and no new functionality was added.
Have you tested your changes (if applicable)? If so, how?
Yes. I've tested this locally with a few project files. The unit tests all pass locally and in the GitHub Actions.
Futher details of this pull request
This came about mainly from me trying to understand why mipmapLevels and RenderScales were being passed around to different APIs and sometimes both were passed together. There also appeared to be more conversions to/from mipmapLevel then actual use of the doubles so it seemed to make sense to just convert the underlying representation to the mipmapLevel. I suspect further simplifications can be made in follow up changes and some usage of RenderScale can go away or be replaced with the equivalent mipmapLevel parameter. This change was just intended to leave the existing abstraction in place, but make the API more explicit and constrained.