-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Skia renderer #18
Comments
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 |
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
Why not flatten this
|
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. |
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).
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). |
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.
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. |
We are already halfway there, using sort of intermediate IElementRenderer abstraction. It still relies on certain WPF primitives (
I think we were looking into it, and found no common ground, for now at least.
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. |
Skia
SkiaSharp
The text was updated successfully, but these errors were encountered: