Skip to content
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

Merged
merged 3 commits into from
Apr 4, 2023

Conversation

zadjii-msft
Copy link
Member

Fixes a bug where you'd drag across the boundary and the new window would be at the wrong size

related to #14957

@carlos-zamora carlos-zamora added the Needs-Second It's a PR that needs another sign-off label Apr 3, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot removed the Needs-Second It's a PR that needs another sign-off label Apr 3, 2023
Comment on lines 1285 to 1290
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;
Copy link
Member

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 };
Copy link
Member

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

Copy link
Member Author

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? 🤷

@zadjii-msft zadjii-msft enabled auto-merge (squash) April 4, 2023 13:49
@zadjii-msft zadjii-msft merged commit c0f1456 into main Apr 4, 2023
@zadjii-msft zadjii-msft deleted the dev/migrie/oop/3/a-short-rest branch April 4, 2023 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants