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).

[charlesroddie]

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.

SVG is the most interesting thing here as that is a case that Maui.Graphics would probably not support. So maybe an intermediate format would be needed:

type DrawableElement =
    | Text of text:string * Position * Font
    | Line of ...
    | Path of ... // hopefully not too many of these

type Drawable(canvasDimentions:..., elements: ImmutableArray<DrawableElement>) = ...

If there were such a thing it could be shared between CSharpMath and WpfMath, along with the Drawable -> Maui.Graphics function.

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

You guys have it hard in Russia! But unless they are paying you a lot for this support, I would suggest dropping it. The idea that devs want to use updated software but are unwilling to update their systems doesn't make much sense and dropping legacy support is better for everyone, including for complaining devs as it forces them to make better decisions.

[ForNeVeR]

SVG is the most interesting thing here as that is a case that Maui.Graphics would probably not support. So maybe an intermediate format would be needed:

type DrawableElement =
    | Text of text:string * Position * Font
    | Line of ...
    | Path of ... // hopefully not too many of these

type Drawable(canvasDimentions:..., elements: ImmutableArray<DrawableElement>) = ...

We are already halfway there, using sort of intermediate IElementRenderer abstraction. It still relies on certain WPF primitives (GlyphRun), but the plan is to eventually extract/generalize those.

If there were such a thing it could be shared between CSharpMath and WpfMath, along with the Drawable -> Maui.Graphics function.

I think we were looking into it, and found no common ground, for now at least.

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

You guys have it hard in Russia! But unless they are paying you a lot for this support, I would suggest dropping it. The idea that devs want to use updated software but are unwilling to update their systems doesn't make much sense and dropping legacy support is better for everyone, including for complaining devs as it forces them to make better decisions.

I disagree. I currently believe that we shouldn't drop support for a bit outdated technologies just because of minor problems with supporting them. If it starts to cause major problems, I'll consider switching it to a lower support level (such as keeping 4.5.2-related stuff in a separate project, a separate package or something), but in the current state of things, I don't think we should get rid of 4.5.2 (or a newer .NET Framework versions) completely right now.

Also, my previous statement was done before the latest announcement of 4.5.2 being obsoleted at 2022. So, we'll be able to switch to 4.6.2 in about a year. What a relief :)

And, no, nobody's paying me for WPF-Math support (or, for that matter, for any of my own open source work not related to my current employment) — which is fine, and I'm just trying to do my best to allow people to use the library for as broad a range of projects as rationally possible. You know there's a lot of GUI development done on outdated tech stacks.

As far as the platform vendor claims to support the technology, I'll try to not drop the support for it, too. This is not related to any new stuff I develop, but related to the libraries which already offer support for these platforms.

[johnnyontheweb]

Hello, so you have a sample of IElementRenderer implementation for Skia?
I have a .net standard library in which I would render some LaTeX formulas as images, using Skia + XamlMath.Shared.
This is mainly because System.Drawing.Common is no more supported.

I'm very confused on how to proceed to write the Renderer. Thanks in advance for any help

[ForNeVeR]

No, we don't have pure Skia implementation of IElementRenderer. So far, we only have Avalonia implementation — would that fit your use case? It should support .NET Standard. In theory, at least.

While Avalonia itself uses Skia, the implementation is not Skia-based because we rely on Avalonia font rendering and resource management mechanism.

If you are interested in creating a new non-UI IElementRenderer, you might take a look at my take on Windows Forms implmenentation in #378 — that one has all the necessary parts implemented from scratch, including resource loading, renderer and whatnot. If you figure out how to map the same concepts to pure Skia, I'd gladly accept such a contribution, and support it in the main library.

[johnnyontheweb]

Thanks for your prompt reply. I'm trying and I'll let you know - it seems harder than expected.

[ForNeVeR]

For the record, I do not expect this task to be easy. We provide very basic capabilities for implementing alternative renderers, and so far it's not utilized for anything drastically different (except for the WinForms branch I mentioned). So, this is quite experimental tech and might require changes in core. I'd be happy to include these, or discuss a partial implementation you are doing, or challenges you met.

[johnnyontheweb]

I worked with Skia and XamlMath.Shared nuget packages, but this I found very difficult to replicate the behaviour of WpfMath.
In particular, I cannot find out how to handle this method (originally in WpfSystemFont):

    public Result<CharInfo> GetCharInfo(char character, string textStyle, TexStyle style)
    {
        var typeface = _typeface.Value;
        if (!typeface.TryGetGlyphTypeface(out var glyphTypeface))
        {
            return Result.Error<CharInfo>(new TypeFaceNotFoundException(
                $"Glyph typeface for font {this.fontFamily.BaseUri} was not found"));
        }

        var metrics = GetFontMetrics(character, typeface);
        return Result.Ok(
            new CharInfo(character, new WpfGlyphTypeface(glyphTypeface), 1.0, TexFontUtilities.NoFontId, metrics));
    }

Perhaps the example given is too little, but I am not giving myself a short-term deadline for this project - I believe there's still much more to do.
Thanks in advance for any kind of advice, by now I simply need to overcome the described issue.

Skia-XamlMath_rev01.zip

ps
project is in vb.net, which does't have "record" (e.g. WpfGlyphTypeface). However, it does not seem to be necessary to use c# ( see dotnet/vblang#584). In any case, I can easily convert the sample to c#.

[ForNeVeR]

Skia supports working with fonts: https://learn.microsoft.com/en-us/dotnet/api/skiasharp.skfont?view=skiasharp-2.88

The general naming looks quite similar, even if not identical, to what we have in other frameworks. I believe it should be possible to extract the data we need from this.

project is in vb.net, which does't have "record" (e.g. WpfGlyphTypeface). However, it does not seem to be necessary to use c# ( see dotnet/vblang#584). In any case, I can easily convert the sample to c#.

Having a working prototype is much more important than having it in the "right" language. Feel free to change the code in XAML-Math if it's incompatible with VB.NET in some places (though I expect it to be compatible and fully usable from VB.NET). If you are more comfortable using VB.NET, I am totally ok with that. More languages — more fun.