| Summary: | Monitor DPI transition on latest Windows 10 causes infinite window growth | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Katelyn Gadd <kg> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | WAITING --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | ||
| Version: | HG 2.1 | ||
| Hardware: | x86 | ||
| OS: | Windows 10 | ||
| Attachments: |
before (ideal resolution, on 150% dpi monitor)
After a few mousemove events on the 100% dpi monitor |
||
Created attachment 3828 [details]
After a few mousemove events on the 100% dpi monitor
Do you have a patch to fix this that we can include in SDL 2.0.10? Thanks! I honestly don't know SDL well enough to fix this. I could look into it some. Is there a particular SDL sample or testcase I should use to verify all the DPI-related stuff? I don't want to just end up fixing it for my scenario and breaking it for others. |
Created attachment 3827 [details] before (ideal resolution, on 150% dpi monitor) If you enable the new 'permonitorv2' DPI awareness mode using an app manifest (app.manifest) in recent versions of Windows 10, SDL windows will grow infinitely on mousemove once they transition to a monitor with lower DPI. I'll attach two comparison screenshots. I wasn't able to build a reduced repro yet, but from what I can tell the problem is that V2 scales non-client portions of the window and SDL appears to use integer pixels for non client and client size calculations. If the base windows DPI is say 150% (like my 4k monitor) and the window transitions to a 100% DPI window, the values are no longer integral pixel counts and as a result SDL produces rounding errors. When that happens every mouse move causes large vertical growth (because the titlebar is big) and slow horizontal growth. Moving back to the original monitor stops the growth but leaves the size incorrect. Set component to events since it happens during mousemove event processing.