Skia renderer

[gsomix]

Skia
SkiaSharp

[alexreg]

Once we have everything in place to do this, it would be nice to tackle alternative rendering engines like Skia as soon as possible. It would certainly allow me to contribute to the library a bit more, since I'm rarely on Windows these days. :)

[ForNeVeR]

I think that addition of the alternate render engines will be the next big thing that we'll implement in WPF-Math. So, yeah, we have such plans.

[charlesroddie]

I need SkiaSharp for Xamarin. Look forward to using and contributing to wpf-math if/when this is done.

As far as the new proposed renderers go, SkiaSharp is somewhat universal in that if all you had were SkiaSharp you would still have WPF support, and will probably have Avalonia support too if/when that platform progresses to something releasable.

[ForNeVeR]

Okay, for now we have somewhat independent IElementRenderer interface (except for usage of GlyphRun type for text rendering; we'll need to abstract it). It should help in development of alternate renderers such as Skia and DirectX.

[charlesroddie]

https://github.com/dotnet/Microsoft.Maui.Graphics could be better than Skia in that it doesn't have the 5MB deployment size.

Replacing the WPF-specific renderer with this would solve the following issues:
#17
#96
#112
#281
#293

[ForNeVeR]

I see this as another (very viable!) alternative to some of these tasks (e.g. Avalonia and UWP support). We'd still need support for alternate frameworks, though having the new renderer would already be good and useful.

[charlesroddie]

You're saying

WPFMath
| - Graphics abstraction Layer (in WpfMath)
    | - Graphics abstraction layer (Maui.Graphics)
        | - Everything
    | - WPF
    | - Avalonia
    | - UWP

Why not flatten this

WPFMath
| - Graphics abstraction layer (Maui.Graphics)
    | - Everything

[ForNeVeR]

Because then we'll have to write an abstraction layer from MAUI to everything. And I bet somebody will blame MAUI font antialiasing and say that the "native" one for their platform works better.

[charlesroddie]

Because then we'll have to write an abstraction layer from MAUI to everything.

I'm not sure if I understand this point, but note that Maui.Graphics doesn't have a dependency on Maui (PR to clarify this).

font antialiasing

Maui.Graphics lists among its WPF "supported abstractions": SharpDX, SkiaSharp, Xaml & GDI. So as long as at least one of these supports the right antialiasing then current WpfMath users should be happy.

CSharpMath is likely to replace its abstraction layer and platform-specific implementations with Maui.Graphics. (link)

[ForNeVeR]

Currently, I see the future of WPF-Math as this (sorry for crappy graphics):

I.e. we may have various renderers, including MAUI.Graphics (but by no means limited to it), and various platform integrations, like with WPF, Avalonia, or some newer ones, like MAUI itself.

Not all renderers support all platforms (MAUI doesn't list Avalonia as supported, right? Only SkiaSharp, and then an integration of whatever SkiaSharp part MAUI supports with Avalonia would be required, even though Avalonia already uses SkiaSharp itself).

Also, note not all users require UI platform integration at all: some will be happy with just rendering the formulae to PNG or SVG images on the server-side, possibly in headless mode without UI libraries available.

Another important point is that MAUI.Graphics doesn't seem to support anything older than netstandard2.0, which would be too limiting WPF-Math applicability: we still have a lot of old school users (who've already been concerned about .NET 4 being dropped earlier), and, as of now, I plan to support .NET 4.5.2 for the known period of extended support (i.e. until 2023-10-10, oh my gosh, provided both myself, .NET, and our modern society as we know it will make it that far).