-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use DIPs for the window bounds when tearing out #15094
Conversation
static_cast<float>(dragPositionInPixels.y), | ||
static_cast<float>(windowSize.width), | ||
static_cast<float>(windowSize.height) }; | ||
rect = winrt::Windows::Foundation::Rect{ inDips.to_winrt_rect() }; | ||
windowBoundsReference = rect; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just windowBoundsReference = inDips.to_winrt_rect();
should be fine I think.
// Convert to DIPs for the size, so that dragging across a DPI boundary | ||
// retains the correct dimensions. | ||
const auto sizeInDips = windowSize.scale(til::math::rounding, 1.0f / scale); | ||
til::rect inDips{ dragPositionInPixels, sizeInDips }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should the drag position be DIP'd as well? after all... we use it for positioning
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea this is weird - we already know exactly the pixel location we want the window to open at. We don't want a position to scale based off the resolution of the target display.
We could theoretically get the scale of the target display and unscale the position to DIPs then scale back, but that doesn't seem valuable? 🤷
Fixes a bug where you'd drag across the boundary and the new window would be at the wrong size
related to #14957