[3.0 preview 4/5] Windows 10 (1809) DPI size not working for WPF application

[TobiasSekan]

The selected DPI size under Windows 10 is not working for WPF applications,
the WPF application use always a 100% DPI scale.

Tested with:

• SDK 3.0.100-preview3-010431 - Working
• SDK 3.0.100-preview4-011223 - Not working
• SDK 3.0.100-preview5-011568 - Not working
• All from https://dotnet.microsoft.com/download/dotnet-core/3.0

System:

• Windows 10 - 1809 (Build 17763.437)
• DPI: 125%
• Resolution: 1920 x 1200
• Visual Studio 2019 - Version 16.1.0 Preview 3.0

[poqut]

It might be the same issue that I've posted earlier #624

@TobiasSekan Can you please check if it's working as expected if you launch the same or another window from your startup window after the application started?

[TobiasSekan]

Hello

Initial situation

• New WPF application project with no changes to MainWindow.xaml and MainWindow.xaml.cs
• Expected window size 984px x 555px
• Wrong window size 784px x 442px
• The window has always the correct size in the draft-view of Visual Studio 2019

Tests

1. App.xaml with StartupUri
2. App.xaml with Startup and 1x new MainWindow().Show();
3. App.xaml with Startup and 1x new MainWindow().ShowDialog();
4. App.xaml with Startup and 2x new MainWindow().Show();

Results

1. not working 😢
2. not working 😢
3. not working 😢
4. Working 🎉 (on the second window)

BTW: the surface Language is always en-EN

Workaround (for controller and MVVM scenarios)

// App.xaml
<Application x:Class="WpfApp1.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             Startup="Application_Startup" />

// App.xaml.cs
private void Application_Startup(object sender, StartupEventArgs e)
{
    var window = new MainWindow();
    window.Show();
    window.Hide();

    window = new MainWindow();

    // Don't use InitializeComponent() in MainWindow.xaml.cs to avoid double initialization
    window.InitializeComponent();

    window.Show();
}

// MainWindow.xaml.cs
internal MainView()
{
    // Don't use InitializeComponent() in MainWindow.xaml.cs to avoid double initialization
    // InitializeComponent();

    // change default surface language (en-en) to current used language
    if(LanguageProperty.GetMetadata(typeof(FrameworkElement)).DefaultValue is XmlLanguage language
    && !language.IetfLanguageTag.Equals(CultureInfo.CurrentCulture.IetfLanguageTag,
                                        StringComparison.OrdinalIgnoreCase))
    {
        LanguageProperty.OverrideMetadata(
            typeof(FrameworkElement),
            new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture
                                                                             .IetfLanguageTag)));
    }
}

Reference for tests

// App.xaml
<Application x:Class="WpfApp1.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             StartupUri="MainWindow.xaml" />

// App.xaml
<Application x:Class="WpfApp1.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             Startup="Application_Startup" />

// App.xaml.cs
public partial class App : Application
{
    private void Application_Startup(object sender, StartupEventArgs e)
    {
        new MainWindow().Show();
    }
}

// App.xaml
<Application x:Class="WpfApp1.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             Startup="Application_Startup" />

// App.xaml.cs
public partial class App : Application
{
    private void Application_Startup(object sender, StartupEventArgs e)
    {
        new MainWindow().ShowDialog();
    }
}

// App.xaml
<Application x:Class="WpfApp1.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             Startup="Application_Startup" />

// App.xaml.cs
public partial class App : Application
{
    private void Application_Startup(object sender, StartupEventArgs e)
    {
        new MainWindow().Show();
        new MainWindow().Show();
    }
}

[BigBadBleuCheese]

This is happening in Windows 10 1903 as well.

[BigBadBleuCheese]

I've added an implementation of @TobiasSekan's workaround that works for me:

protected override void OnStartup(StartupEventArgs e)
{
    var wnd = new Window
    {
        AllowsTransparency = true,
        Height = 0,
        Opacity = 0,
        ShowInTaskbar = false,
        Width = 0,
        WindowStyle = WindowStyle.None
    };
    wnd.Show();
    wnd.Hide();
    // do startup work
    base.OnStartup(e);
}

[hillin]

@BigBadBleuCheese Nice workaround! Also call wnd.Close() after base.OnStartup(e); to allow the process to exit.

[BigBadBleuCheese]

Okay, so, DO NOT open a window that allows transparency like what I posted above. Just leave that out, like so:

protected override void OnStartup(StartupEventArgs e)
{
    var wnd = new Window
    {
        Height = 0,
        ShowInTaskbar = false,
        Width = 0,
        WindowStyle = WindowStyle.None
    };
    wnd.Show();
    wnd.Hide();
    // do startup work
    base.OnStartup(e);
}

For reasons that will probably always remain a mystery, I experienced this little gem. While also using MaterialDesignInXamlToolkit, the app will be fine until the machine is locked and then unlocked (I know right: what?), at which point the WPF UI thread will enter the fog of native code, pegging out a logical processor, never to return. Everything (that's not a worker pool thread) stops. Removing the Material Design package removed the problem. But also not opening a window allowing transparency fixed it.

(I'm still thinking: seriously, what?)

[weltkante]

@BigBadBleuCheese when you lock/unlock the machine some DirectX stuff starts failing until its reinitialized, because the lock screen runs under a different security model it doesn't share GPU resources and takes them forcefully away. The WPF rendering thread probably sits in a loop not recognizing rendering is failing, trying over and over again. It probably happens in a code path related to transparent windows (maybe material design is using some feature rarely combined with transparent windows).

I'd expect it to be debuggable once the rendering engine is open sourced. If you can repro with a simple app just referencing material design and creating a window, it'd be useful to open that as a separate issue so it can be fixed later.

[BigBadBleuCheese]

@weltkante, I actually did a complete conversion over to .NET Framework 4.7.2's WPF just to make sure it wasn't a problem with the .NET Core implementation and it happened in the former as well. Just want to clarify I'm throwing absolutely zero shade here.

I'll try to put together a lowest common denominator version of this issue and toss it into a repo for far better developers than me to consider looking at. Thanks for the reply. ;)