obsproject
UI: Fix the resize cursor with respecting the item rotation
Description
When rotating a scene item the resize cursor is not updated correctly. This is because the ItemHandle is also roated. In the UI this will lead to a false result as the diagonal cursor will not point towards the scaling direction when the item is rotated by 90° (counter) clockwise.
Before:
My solution is to invert the direction of the shown diagonal cursor, when the item is rotated by 90° (+ 45° and - 45°) counter clockwise and clockwise.
Same for horizontal and vertical resize cursors.
After:
Motivation and Context
fixes #7247
How Has This Been Tested?
I've tested it with nearly every rotation that is possible on windows with dev version.
When a source is flipped horizontal or vertical, the resize handle is still not working but this depends on bug: #7744 Rotate handle is not working when source is flipped I will try to fix it after this one.
What else should I test?
Types of changes
- Bug fix (non-breaking change which fixes an issue)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [ ] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
If this fixes a specific GitHub Issue, please use the keywords "Fixes #<Issue Number>". See:
- https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
- https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests
Please provide both before and after screenshots of the behavior.
How does this handle non-90° rotations? I suppose an equally valid question is how do we currently handle non-90° rotations?
How does this handle non-90° rotations? I suppose an equally valid question is how do we currently handle non-90° rotations?
There is no need to change anything on the non-90° rotations. When a item is rotated by 180°, then Top Left will be at the former position of Bottom Right. If you look at window-basic-preview.cpp L.659 and L.660, you can see that both handles use the same cursor. The same applies to horizontal and vertical cursors. But with a 90° clockwise rotation there is the problem that Top Left will be displayed as Bottom Left, what causes the bug.
How does this handle non-90° rotations? I suppose an equally valid question is how do we currently handle non-90° rotations?
There is no need to change anything on the non-90° rotations. When a item is rotated by 180°, then Top Left will be at the former position of Bottom Right. If you look at window-basic-preview.cpp L.659 and L.660, you can see that both handles use the same cursor. The same applies to horizontal and vertical cursors. But with a 90° clockwise rotation there is the problem that Top Left will be displayed as Bottom Left, what causes the bug.
To be clear, I'm not asking for changes. I'm just asking, "how does this handle non-90° rotations?" Put another way, could you please describe and/or provide screenshots of the before and after for that scenario? For example, 45° rotations.
@PatTheMav Thx for the review. Since I use a circular sector of 45°, the correct term would be "octant". By "q" I actually meant quotient, but octant is more precise. It is true that opposing diagonal pairs are treated as equal, but it shouldn't be a problem since it's irrelevant for the UI and the flag won't be used afterwards. But its important to mention that the flag is incorrect afterwards (when there is a rotation), regardless of this. If this is a problem somehow, then we should call UpdateCursor() with call by value.
"Octant" would be actually correct, yeah.
I agree that the interchangeable use of the handles is fine, insofar as it doesn't have a visual impact (the function is entirely unaffected by this).
Fixing that would require a bit more complex bit arithmetic (e.g. just shifting the left/right part to the top/bottom part for non-perpendicular angles wouldn't suffice).
I have tested it visually for all 8 rotation cases, and the resize functionality still works fine. So is this approach mergeable?
I have tested it visually for all 8 rotation cases, and the resize functionality still works fine. So is this approach mergeable?
Looks good overall, cannot tell when it will be merged, but it's on the docket.
@BGM99 could you please change the commit title to something like UI: Fix resize cursor to respect item transformation.