[Windows] Window positions across monitors with different scale factors
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp
- Domain
- desktop, operating-systems
Research direction
Locate the C++ implementations of Window::GetPosition(), SetPosition(), the bounds calls, and DisplayManager's display bounds handling. Trace the existing GetScaleFactorForWindow conversion and WM_DPICHANGED behavior; done means positions and sizes remain consistent when saving, restoring, or moving windows between monitors with different scale factors.
Written by the indexing model from the issue text.
Description
On Windows, Window::GetPosition() / SetPosition() (and the bounds calls) convert between logical and physical pixels with the scale factor of the monitor the window is currently on (GetScaleFactorForWindow). With monitors at different scale factors, the same logical point maps to different physical points depending on where the window is. Saving a position on one monitor and restoring it (or restoring on another monitor) puts the window in the wrong place or makes it the wrong size.
Expected: one global coordinate space that matches DisplayManager's display bounds. That means converting with the scale factor of the monitor that contains the target point, and handling the WM_DPICHANGED resize that follows a move across monitors.
Background:
- leanflutter/window_manager#474: getPosition/setPosition wrong with multiple scaled screens (also #448, #536, #589)
- Dominant language
- C++
- Stars
- 34
- Forks
- 7
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 1
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from libnativeapi/nativeapi
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#81 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#80 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
libnativeapi/nativeapi#79 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#78 ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
libnativeapi/nativeapi#77 ·
All issues in libnativeapi/nativeapi
Similar issues
-
AuTest Bug Tests
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/trafficserver#13714 ·
-
bug build
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
facebookincubator/velox#19143 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tenstorrent/tt-metal#57393 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
objectionary/eo-graphs#74 ·