dotnet
DrawReversibleLine / DrawReversibleFrame draws in wrong position with multiple monitors
.NET version
9.0.5
Did it work in .NET Framework?
Not tested/verified
Did it work in any of the earlier releases of .NET Core or .NET 5+?
Code used to work. Seems like a regression in either dotnet or windows itself
Issue description
Tracking for zooming a graph in an application that has been working for many years suddenly started misbehaving around 12/2024.
With multiple monitors only, the graphics operations appear in an incorrect position on the desktop, outside of the application's window.
See demo code below.
Also see this stack overflow issue:
https://stackoverflow.com/questions/79595420/system-windows-form-method-controlpaint-drawreversibleframe-seems-to-have-a-bu
Steps to reproduce
Run this app on a system with latest windows and multiple monitors. https://github.com/coderb/DrawReversibleLineBug
Can you remember the point in time for which you can say with a comparably high probability that it still worked with the .NET version current at that time? That would help us very much in tracking down the regression cause.
@KlausLoeffelmann it was definitely broken as of 12/2024- that's when I created the repro but I spent the last 6 months trying different combinations of hardware / drivers / monitor configs to no avail. I think it must have been working not too long before that but I dont know the exact date. thanks.
also something kind of weird is that after setting up a new machine with a fresh os install I have had the code working properly, but after a reboot it displays the issue. really puzzling.
This issue appears to be the same as issue https://github.com/dotnet/winforms/issues/13529, as the splitter bar in PropertyGrid mentioned in that issue is drawn by DrawReversibleLine. As mentioned, in the description in #13529, the error occurs also on .NET Framework 4.8.1, and in the property pane in VS2022.
I just tested with single monitor on my laptop: Then everything is fine.
It seems as the error is related to the adjustments for High DPI or scaling in cases with multiple monitors. But not the scaling in itself. My laptops scaling is 200%
It is also remarkable that the SplitContainer works properly in the cases when the DrawReverseLine error occurs. That can be verified by using the WinFormsControlsTest's Splitter test.
(Same comment left in #13529)
I'll close #13529, as that issue is about the same error as this issue, i.e. the same issue.
Here are the description etc. from #13529 in case that can contribute to the seach for a solution
#13529: PropertyGrid: Splitter bar out of position when resizing the help pane at the bottom of a PropertyGrid
.NET version
.NET version: 10.0.0-preview.4.25258.110 (Currently the latest publicly available preview version)
Did it work in .NET Framework?
No
Did it work in any of the earlier releases of .NET Core or .NET 5+?
Testing with the latest .NET versions (net60, net70, net80) give the same error. Same for .NET Framework 4.8.1
Issue description
When trying to resize the HelpPane at the bottom of a PropertyGrid, a splitter bar appears to indicate the new position of the split. But it displays a wrong position.
The error seems to be related to the handling of hight DPI, which is controlled by the ApplicationHighDpiMode property in the project settings. Changing this setting in WinFormsControlsTest from SystemAware to PerMonitorV2 reduces the deviation slightly, but it is still significant.
dotnet/winforms commit tested: 1e15c5140 25.04.2025 4:25 CET .NET version: 10.0.0-preview.4.25258.110 OS: Windows 11 Pro, version: 24H2 Hardware: Lenovo Yoga Slim 7 14Q8X9 (Laptop)
- Display on Laptop: Resolution=2944x1840, Scale=200%
- External monitor: Resolution=1920x1080, Scale=100%
Steps to reproduce
This error can easily be reproduced on a setup with two or more displays by running the WinFormsControlsTests (in dotnet/winforms), open a PropertyGrid and try to resize the HelpPane at the bottom. The same error can be seen e.g. in the Property pane in VS2022 and anywhere where PropertyGrid is used
@tvidvei - I'm not sure that this is the same issue. This may be more related to changes in the operating system. @JeremyKuhne - can you check on whether we have seen changes from the OS around the same time.
@Olina-Zhang can you please see if you can repro the issue described here?
@merriemcgaw Yes, I can repro this issue in my machine with multiple monitors, regardless of the DPI value setting: drawing is in the wrong position, .NET 8/9 and .NET framework 4.8 have the same result:
https://github.com/user-attachments/assets/f10a4feb-4e70-4603-b973-4440f6da8a5d
And if I disconnect extra monitor, remaining one monitor, it cannot repro: drawing is in the correct position.
@merriemcgaw my hunch is that this is a windows bug rather than dotnet or a driver issue.
something that may be of interest to whoever investigates this is an additional issue i have observed:
popup items (eg MainMenu and a custom calendar editor control I use) will sometimes (<5% of the time) on the first click display on the wrong monitor and position, and if immediately dismissed and re-clicked show up in the correct place.
feels like either a caching issue or race condition/threading bug deep inside the windows api.
For me, the problem was with the NVIDIA driver. Scaling was set for the screens there. After I turned off scaling, the rectangles were drawn in the correct position again.
Regards, Holger
@HStoni54 I get this with multiple systems, some of which only run intel drivers.
I believe I have seen things work properly for a while after the initial install of a driver, but then the problem reappears after a reboot.
@merriemcgaw has this been reported to the windows team and is there any status on whether they can reproduce and if so when a fix is targeted for? thanks.
You're right. After rebooting, the rectangles are displayed on the wrong screen again.
Regards, Holger
My observation is that DrawReversibleFrame takes the background from the correct screen and then draws it on the wrong screen. Perhaps this will help with troubleshooting.
Regards, Holger