Create a new cross-platform view that supports different GPU backends

[mattleibow]

Is your feature request related to a problem? Please describe.

Right now, both SkiaSharp.Views.Forms and SkiaSharp.Views.Maui only support using OpenGL in the SKGLView since this was the only backend at the time.

Describe the solution you'd like

Time has moved on and we need a GPU view that swaps out the backend controls based on the preferred backend for each platform.

Describe alternatives you've considered

The only alternative now is to create a new renderer and copy the code from this repo.

Additional context

[mgood7123]

like switching between GL and Vulkan at runtime?

[mattleibow]

From @taublast in https://github.com/mono/SkiaSharp/pull/2747#issuecomment-1959771472

We can let people choose the rendering backend at initialization with .UseSkiaSharp(optional settings) with enum of kind Vulkan, GL, ..., Auto.. so the correct handler will set to be used globally for the SKGLView. A case when one would want to select backend at run-time I can think of is when one specific backend reveals itself not working on device so dev would want to programmatically select another one?..

[taublast]

In those hypothetical settings, we could also have the fallback backend option: for example, we set .UseSkiaSharp(settings), inside settings we indicate that we want Vulkan and the fallback to be GL. If we do not specify the fallback we would get a non-accelerated handler if Vulkan is not available. So the hard part (maybe not?) is to check the compatibility/availability of a given backend type at startup.

[mgood7123]

for anyone wanting to create a DirectX view

(skia/tools has many bindings for such including D3D12 - tools/window/WindowContext.h, tools/window/win/WindowContextFactory_win.h, std::unique_ptr<WindowContext> MakeD3D12ForWin(HWND, const DisplayParams&), the returned window manages the underlying context and provides a sk_sp<SkSurface> via getBackbufferSurface(), and includes other functions such as resize, rendering must be done manually by whatever creates the WindowContext)

you may want to look at these for "smooth window resizing"

• NOTE: currently the SkGLControl (WinForms) does smooth resizing, not sure if MAUI GL control also does same, but given MAUI/WinUI3 (ui-xaml) itself has this problem, it is unlikely since i assume the GL contents itself will also be affected
• • https://github.com/microsoft/microsoft-ui-xaml/issues/2506
• • https://github.com/microsoft/microsoft-ui-xaml/issues/5148
• • (do note that although this displays same behavior, it is reported as a fix for the TITLE BAR only) https://github.com/dotnet/maui/issues/13479#issuecomment-1442431197
• (specifically win32 would proceed to resize the window before the application had been redrawn leading to visible black bars, and the immediate return would lead to win32 generating resize events at a rate far higher than any renderer could handle - https://github.com/rust-windowing/winit/pull/250)

the following links can provide more information on the underlying issue of DirectX and the Windows Desktop Manager (WDM) specifically how WM_SIZE messages and directx swap chain present are handled

https://raphlinus.github.io/personal/2018/04/08/smooth-resize.html

• https://github.com/rust-windowing/winit/pull/250
• https://github.com/rust-windowing/winit/issues/786

[mgood7123]

In those hypothetical settings, we could also have the fallback backend option: for example, we set .UseSkiaSharp(settings), inside settings we indicate that we want Vulkan and the fallback to be GL. If we do not specify the fallback we would get a non-accelerated handler if Vulkan is not available. So the hard part (maybe not?) is to check the compatibility/availability of a given backend type at startup.

i would also like to make use of Skia's multi-backend configuration to provide this ability

(GrContext itself has multiple graphical backends as we all know, among GL, DX12, VK, METAL, and ANGLE)

we could handle runtime-backend switching via some api however such must be done carefully to avoid the user effectively locking themselves out of the current instance by switching to an incompatible/faulty api

(could also be implemented as a "config" file somewhere which is loaded upon startup as an alternative to selecting the backend at runtime if such an interaction cannot be implemented or is undesired, tho android may be tricky due to scoped storage, /data unreadable, permissions, and others)

(may be faulty due to poor driver support or unsupported requirements (eg, i think not all versions of mac support METAL, while newer ones i think removed GL entirely in favor of METAL, or your windows OS might be incapable of running DX12, or you lack Vulkan driver support))

(may also be faulty due to skia rendering bugs (if any) in a given backend that happen to disappear in another)

for example, switching the api might generate an event that we must explicitly (pref interactively) respond to in order to verify the new api is working as expected with their application

kinda like switching to a new display configuration, the system will revert back if "OK" is not clicked within 30 seconds (possibly cus the screen went black due to some unsupported configuration or other issue)

[Kation]

@mgood7123 Currently SkiaSharp windows runtime does not compile with define SK_DIRECT3D. Can we add define SK_DIRECT3D?

[mgood7123]

depends on if skia itself is compiled with D3D support, try it :D