xaml-math
xaml-math copied to clipboard
ForNeVeR
Skia renderer
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. :)
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.
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.
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.
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: https://github.com/ForNeVeR/wpf-math/issues/17 https://github.com/ForNeVeR/wpf-math/issues/96 https://github.com/ForNeVeR/wpf-math/issues/112 https://github.com/ForNeVeR/wpf-math/issues/281 https://github.com/ForNeVeR/wpf-math/issues/293
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.
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
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.
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)
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).
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.
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.