Is this bug related specifically to tooling in Visual Studio: No
Problem description:
graphic becomes corrupted soon after program startup. Seems that WPF zooms the content of the controls. See video for details: https://1drv.ms/v/s!AuaupcqeIy50hqYKPc8JV_qCfx8G6A?e=rHgHNt
The video shows a simple WPF application with only two buttons. No code behind.
PC configuration:
i9-9900K 3.6 GHz
16GB RAM
Mainboard: MSI MPG Z390 Gaming Pro Carbon
Intel UHD Graphics 630, driver version 26.20.100.7755 7 09.01.2020
2 displays: 1xFullHD on HDMI, 1xBenQ PD3200U on display port. Problem exists on both monitors
Actual behavior: graphical representation unusable.
Expected behavior: graphical controls should be displayed normally
Minimal repro:
<Window x:Class="WpfApp15.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
FontSize="40"
Title="MainWindow" Height="450" Width="800">
<Grid>
<Button Content="Button" HorizontalAlignment="Left" Margin="134,88,0,0" VerticalAlignment="Top"/>
<Button Content="Button" HorizontalAlignment="Left" Margin="241,199,0,0" VerticalAlignment="Top"/>
</Grid>
</Window>
@drjofu This looks like an instance of #707. Likely this is due to a specific component interfering with WPF. Check for things like Realtek Sonic Studio and Nahimic software.
@rladuca Even if such software is installed, why does this happen in WPF / .NET Core but not in WPF / .NET Framework? In any case, this has to be fixed in .NET Core, because many people write WPF applications, for which we cannot dictate and explain to users that you are not allowed to use audio programs such as Realtek Sonic Studio and Nahimic together with WPF applications ,
@HSchwichtenberg I disagree, this is not an issue for WPF to fix. In a few months, these vendors may decide to inject into the process and interfere in other unforeseen ways. We can't ensure that there is no way for WPF to be affected by these sorts of techniques.
The only reason this didn't happen in .NET Framework is there seems to be concerted effort in these programs to detect WPF or .NET and leave the process alone (as @stevenbrix found during his investigation). The vendors need to update their software to either do the same for .NET Core or, even better, find an alternate way to achieve their goals.
@drjofu Barring evidence to the contrary, I am going to close this as a duplicate of #707. If you think that it isn't please comment here and I'll re-open.
Most helpful comment
@HSchwichtenberg I disagree, this is not an issue for WPF to fix. In a few months, these vendors may decide to inject into the process and interfere in other unforeseen ways. We can't ensure that there is no way for WPF to be affected by these sorts of techniques.
The only reason this didn't happen in .NET Framework is there seems to be concerted effort in these programs to detect WPF or .NET and leave the process alone (as @stevenbrix found during his investigation). The vendors need to update their software to either do the same for .NET Core or, even better, find an alternate way to achieve their goals.