[BUG] Can not show UI elements on top of XF WPF SKGLView

[pauldendulk]

Description

When a class is derived from SKGLView UI elements on top of that element are not shown in XF WPF

Code

The custom SKGLView is created like this:

using SkiaSharp;
using SkiaSharp.Views.Forms;

namespace Mapsui.UI.Forms
{
    public class MyCustomView : SKGLView
    {
        public MyCustomView()
        {
            PaintSurface += MyCustomView_PaintSurface;
        }

        private void MyCustomView_PaintSurface(object sender, SKPaintGLSurfaceEventArgs e)
        {
            e.Surface.Canvas.Clear(new SKColor(255, 128, 128));
        }
    }
}

Put it in a page and put a button on top like this:

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
			 xmlns:mapsui="clr-namespace:Mapsui.UI.Forms;assembly=Mapsui.UI.Forms"
             x:Class="Mapsui.Samples.Forms.MainPageLarge">
    <ContentPage.Content>
            <Grid
                VerticalOptions="FillAndExpand"
                HorizontalOptions="FillAndExpand">
            <mapsui:MyCustomView x:Name="mapView"
    		    VerticalOptions="FillAndExpand"
                HorizontalOptions="FillAndExpand"
		        BackgroundColor="Gray" 
		        Margin="0" />
                <Button 
                    WidthRequest="160" 
                    HeightRequest="160" 
                    HorizontalOptions="Center" 
                    VerticalOptions="Center" 
                    Text="Hello"></Button>
            </Grid>
    </ContentPage.Content>
</ContentPage>

Expected Behavior

The button is visible as in XF UWP:

Actual Behavior

The button is not visible in XF WPF

Basic Information

• Version with issue: 1.68.2-preview.17
• Last known good version: wpf did not work at all in the previous version we used.
• IDE: VS 2019 professional
• Platform Target Frameworks: XF WPF
• Target Devices: Windows desktop

Related reports Mapsui got a bug reported here. Alerts are also not shown on top of the map.

[pauldendulk]

Here is a minimal reproducible example. https://github.com/pauldendulk/ButtonDoesNotShow

[pauldendulk]

@mattleibow Any update on this? We have a sample for WPF Forms. Users actually try to build apps based on this sample but have to hold their development when they find this issue. If this is not supported please let us know then we can remove the sample.

[charlenni]

Create another sample for this problem: SkiaTest. There you could see the problem too. See label in the top left corner and button in the top right corner.

[mattleibow]

Hi folks. I looked into this and it is because of an actual limitation of the windowing interoperability between WPF and the Win32 GLControl.

https://docs.microsoft.com/dotnet/framework/wpf/advanced/wpf-and-win32-interoperation#notable-differences-in-output-behavior

• HwndHost will appear on top of other WPF elements in the same top-level window. However, a ToolTip or ContextMenu generated menu is a separate top-level window, and so will behave correctly with HwndHost.
• HwndHost does not respect the clipping region of its parent UIElement. This is potentially an issue if you attempt to put an HwndHost class inside a scrolling region or Canvas.

This is directly related to #745 which is about providing an alternate means for GPU for WPF. Now that we have .NET Core WPF, this issue is moving up the list.

[pauldendulk]

@mattleibow Thanks for the update. If I understand correctly this will be fixed in a future version. What kind of fix should we look for in the release notes? You mention .NET Core WPF. The thread you point to talks about 'GPU-accelerated off-screen context', ANGLE, vcpkg, DX view in WPF. I am confused. Does it helpt to jump to .NET Core?

The reason I ask is I want to be very clear to our users about what to expect. We now offer the WPF forms sample. Users see this and invest in it and then end up disappointed. Perhaps we can point them to a future release, or remove the sample altogether. Should we tell them to wait for .NET core WPF?

Note, this is not a high priority thing for us. I am not urging you on. We just want to be clear to our users and not offer something that they should not invest in.

[mattleibow]

@pauldendulk The aim is to fix this in a future version. What will be happening is that we will switch from hosting OpenGL to direct DirectX usage. Right now, we use OpenGL in a hosted Win32 control which is fairly limited. If we switch to DirectX, we can draw directly on the surfaces.

The reason I mention .NET Core is that WPF appeared to be a lower priority before, but now that WPF has made a strong comeback, WPF support is now a higher priority. We have to fix this issue so that new users can be productive. The other info about ANGLE/vcpkg/etc are just the way we will get this support in. We may need to build some libraries or use some tool. Nothing is fixed in stone just yet on that.

We are currently still investigating the best way to support GPU and WPF.

[pauldendulk]

@mattleibow Ah, thanks, that clears things up for me. We also got our first WPF .NET Core request yesterday. Good to know skiasharp also has a high priority for that. We will start to support this as well.

[mattleibow]

If we can get this, then all the problems go away... I think: https://github.com/mono/SkiaSharp/issues/745

[mattleibow]

I am going to close this issue as 2.x is not getting new features and Xamarin.Forms is out of support.

However, for plain WPF we now have a new SKGLElement: https://github.com/mono/SkiaSharp/pull/2317