[ARM64][Windows 11]: Running Freshly Created Avalonia 11.0.0-preview4/5 application returns a transparent window

Describe the bug Running Avalonia applications using 11.0.0-preview4,preview-5 and even nightly builds on native Windows on Arm devices (Surface Pro X / Windows Dev Kit 2023) fail to properly display window contents. By default, only the outer frame of the window is created while the inner contents are completely transparent.

To Reproduce Steps to reproduce the behavior:

1. Run dotnet new avalonia.app -f net7.0 -av 11.0.0-preview4 from an Arm64 Windows 11 device
2. Run dotnet publish -c Release -r win10-arm64
3. Execute the exe from the published output directory
4. Notice the app runs with a transparent window
5. Update the dependencies to 11.0.0-preview5
6. Remove Mode property from <FluentTheme> declaration in App.axml
7. Execute the same process
8. Notice the transparent window exists

Expected behavior Creating a new application from the Avalonia.Templates should properly run without modification for Windows Arm64.

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Windows 11 22530 Arm64
• Version 11.0.0-preview5

Additional context The interesting thing is deleting av_libglesv2.dll from the output directory will cause the app to load properly. I’m assuming this is a composition issue related to #8776 ?

[antondie]

I see the same issue with Avalonia 11.0.0 preview 8 on a Windows 10 Edition Windows 10 Home Version 22H2 Installed on ‎13.‎09.‎2021 OS build 19045.2965 Experience Windows Feature Experience Pack 1000.19041.1000.0

running in Vitrualbox 6: Device name DESKTOP-E0GIKCL Processor AMD Ryzen 5 5600G with Radeon Graphics 3.89 GHz Installed RAM 4.00 GB System type 64-bit operating system, x64-based processor Pen and touch No pen or touch input is available for this display

Removing av_lbglesv2.dll from the build fixes the problem as well as using OpenGL as mentioned by snickler

[antondie]

As far as I can see the issue arises when the system tries to dispatch the frame of the core window. The core window frame and the title bar are build and rendered correctly, but disposing the frame at creates an exception in Skia and never returns to the main program loop. The transparent core window still exist after that and can be moved or sized. Closing it, however does not end the main program loop. You need to kill the program task with task manager. I think it is related to an issue also reported in SkiaSharp: https://github.com/mono/SkiaSharp/issues/2125 The native surface may run under a different thread?

In case of Windows 10 in Virtualbox the issue disappears when I disable the 3D Graphics acceleration!