Make WPF cross-platform (MacOS and Linux support)

[x2bool]

Please port WPF to other platforms so we could use it to build desktop software for other operation systems.

[juanfranblanco]

Have you seen https://github.com/AvaloniaUI/Avalonia ?

[dotMorten]

It's definitely not in the current plan: https://github.com/dotnet/wpf/blob/master/Documentation/contributing.md

We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF.

Considering how platform specific WPF is, this would be a major undertaking

[alexbakker]

I'm not too familiar with how WPF works, but as far as I know it relies on D3D for rendering. In the case of Linux, someone would have to (a) port it to use GL(ES)/Vulkan and (b) write an X11/Wayland backend for it.

[kekekeks]

@alexbakker I think that could be solved by linking to Winelib, but that's more of a packaging work that has to be done on application level rather than in WPF code

[feliwir]

Exchanging the current rendering backend with something crossplatform e.g. like https://github.com/mellinoe/Veldrid would be the correct approach in my opinion. Not sure why they explicitly state that they do not want something like that.

[richlander]

Just like @dotMorten says, we are not taking cross-platform implementations, per our Contributor Guide.

We look forward to many contributions to WPF. This request is out of scope for the project.

From a technical standpoint, WPF depends on multiple Windows components: D3D (DirectX), DWrite, User32, GDI+, WISP (Touch), and several others (including Windows Runtime dependencies). The interaction with these components is complex, critical and not architected with cross-platform in mind. As a result, our focus is on completing open source of WPF and bringing it to parity with .NET Framework.

I am closing this issue as a result.

[zezba9000]

As 'feliwir' says the rendering backend could be replaced or be updated and Windows specific APIs like GDI+ or other User32 APIs are already supported by Mono. Areas that directly link to WinAPIs via DllImports or whatever would just have to be ported to use the Mono version to start with (later ported to use .NET Standard). Just my thoughts without actually looking.

Maybe there should just be a WPF subset for other platforms like WASM, Android, iOS, etc. WPF could be made to run as a UWP app as well.

[Kryptos-FR]

Disclaimer: what follows is a rant.

@richlander closing the issue and refusing the debate is a very dick move.

Now that WPF is open source and under the .Net Foundation, it is not up to Microsoft only what the future of it should be. If the majority of the community wants it, we have to at least try.

Seems like Microsoft still has a lot to learn how open source and communities work. I understand the difficulties and implications and possibly it will not be realistic to do so. But saying "no never" and "we will reject any attempt" is not a sane way to interact with the community. You have people ready to contribute for free to the project so you need to show at least some respect for their wishes and be more open minded.

[dotMorten]

@Kryptos-FR That's not really fair. He clearly stated it's out of the scope of what they can support, and it was already documented before this issue was logged, so what's there to debate? He never said you can't go ahead and fork this repo and attempt taking things cross-plat. And we're not talking about a small part to flip a few switches to compile it against Linux and Mac - WPF is so closely tied to the Windows APIs, it is basically a complete rewrite, and code and UI was never designed for x-plat in the first place. IMHO I'd rather they focus on using their resources on improving WPF on Windows, than go on a wild goose-chase shoehorning this onto a Mac, and instead provide something more modern built from scratch that could be such a cross-platform UI, designed for xplat from the ground up.

[richlander]

Exactly, @dotMorten. We are being clear and transparent. In fact, I think we know exactly how open source works. We are setting the rules of engagement for this particular repo, but also licensed the code very favorably and are happy to see others use this code for scenarios that are out of scope for this repo. We're also happy to take code back, should it continue to be licensed favorably and it aligns with future scenarios.

We've also learned from our experience from CoreCLR, CoreFX and other repos. We have cases where issues have stayed open for years where nothing has happened. To a degree, we've voted by not applying any effort on some of those requests. That model is potentially more friendly, but it arrives at the same product outcome. That's not a bad model, but we want to avoid it where we have a clear point of view up front. That's what's happening here. It also allows others to stake their claim if they are passionate, with a clear sense of the engagement model with upstream.

Let's also be crystal clear. This is a very hard project. If the cost was low, this would be a very different conversation and very likely a different outcome. We have enough trouble being compatible with OpenSSL and that's just one library.

[zezba9000]

@Kryptos-FR MS is just taking the position (from my perspective) of they're not going to spend money supporting platforms they don't 'directly' make money in or is hard for them to measure the value of short term (which is a little off as they supports macOS but only for the sake it brings in Azure developers not realizing I think people need better client side tools to even use Azure [thats a larger topic though]). Thus Its the communities responsibility to fork and port WPF and if it does have value to MS (which I would argue does) the community will have to illustrate that to MS. This is just how big companies work which sometimes don't see the value of innovation outside their bubbles / eco systems if you will.

There is a lot of value in a cross platform XAML that looks the same on every platform, is compile type checked, has a visual editor in an IDE and based around the .NET or C# eco system. MS has at least given people a starting point if they have the resources to port it (which is far more than I expected to happen tbh).

@dotMorten Many apps written in WPF would have great value on other platforms. If these apps were using Azure it would end up making MS money in the long run. People who don't see this value are a little disconnected I think. .NET Core has solved the cross platform issues in its eco system in every aspect besides the desktop and client side (no HTML is not the answer for many reasons). It is in some ways both MS's and the communities responsibility to solve that remaining client side UI issue as both parties will share the rewards. In this case I think the community has to start the trail rolling.

[dotMorten]

@zezba9000 Don't get me wrong: I'm not at all saying a cross-platform UI is a bad idea and not needed - what I'm saying is I think making WPF cross-plat would be a waste of (a lot of) resources, and we'd be better off inventing something new from scratch - also IMHO if we were to go the XAML route, we'd be better off starting with UWP as a base.

[zezba9000]

@dotMorten I agree WinUI might be a better base or something new that lives outside of the platform its running on conceptually (then platform specific APIs like .NET Core has for Windows now could be made). This would also help MS from needing to keep reinventing XAML for each new platform they create. If WPF was designed correctly to start with, they could have just had a WPF version running as a UWP app. If that makes sense.

However the gravity to use existing knowledge and code bases is probably strong for WPF. Just look at the stars on WPF vs WinUI in GitHub... people clearly want a WPF like Desktop solution more than something else. From what I can tell. Its a lot faster to dev with for sure.

[xiexin36]

Please at least be open to discuss these.

[10Dev]

Exactly, @dotMorten. We are being clear and transparent. In fact, I think we know exactly how open source works. We are setting the rules of engagement for this particular repo, but also licensed the code very favorably and are happy to see others use this code for scenarios that are out of scope for this repo. We're also happy to take code back, should it continue to be licensed favorably and it aligns with future scenarios.

We've also learned from our experience from CoreCLR, CoreFX and other repos. We have cases where issues have stayed open for years where nothing has happened. To a degree, we've voted by not applying any effort on some of those requests. That model is potentially more friendly, but it arrives at the same product outcome. That's not a bad model, but we want to avoid it where we have a clear point of view up front. That's what's happening here. It also allows others to stake their claim if they are passionate, with a clear sense of the engagement model with upstream.

Let's also be crystal clear. This is a very hard project. If the cost was low, this would be a very different conversation and very likely a different outcome. We have enough trouble being compatible with OpenSSL and that's just one library.

@richlander Perhaps you could reconsider and simply take the well worded contents of your post above to insert into this issue's "description" and then suffer the annoying situation of leaving the issue OPEN forever which you stated is a possible option.

Considering how well-loved WPF is to so many people, you might be faced with a multitude of endless repeats of this issue. By taking the current approach, it simply does not "read well" and comes off cold-hearted through no bad intent of yours, just the situation.

I'm just suggesting that it will calm everyone down and leave a "safety valve" if you just leave this open as a kind of "wisdom of the crowds" or just plain old wisdom...

[ranqn]

I think what the community want is just an open source, cross-platform XAML-based UI framework, not a cross-platform WPF. We can have an open source cross-platform XAML-based UI framework, because we now have WPF open sourced, we can take the stuff and build one, but the one we'll be building is just not WPF, it just won't exist in this repository under the name of Windows Presentation Foundation.

So I think the correct question should be 'Can we have an open source, cross-platform XAML-based desktop solution?'. Apparently it's not an easy one to answer.

[raffaeler]

@Ran-QUAN frankly speaking I am not sure that would be the right direction. Let me say that many years ago I asked several times to port WinRT/XAML cross-platform, but now many development shifted to web and mobile, and XAML failed to improve over the years.

Don't get me wrong, I love WPF and wrote tons of apps but there are multiple flaws in XAML.

• The inability to provide a solid designer is a major stopper for most of the developers. I stopped using a designer a long time ago but it is still a blocker for many.
• The verbosity of XAML was supposed not to be a problem because initially the designers would manage that. But in large apps, you have to take care of your XAML by hand.
• XAML in UWP and WPF is significatively different. And in UWP there are a lot of missing features that prevented porting many apps. What XAML are we talking about? Is the WPF one (the most complete) really the best? I don't think so.
• The missing lifecycle of the views (pages or simply windows) is a major problem for writing a decent MVVM support. Those are not the only things of course, just the first ones I had in my mind. Converters syntax and versatility can probably be easily fixed and improved but they have been a source of complains for years.

Paradoxically it's far more easier to port winforms cross-platforms (as Mono had for years using Wine) in comparison to the effort of WPF (because of DX and other components). Not the best choice at all, but definitely the fastest.

[costincaraivan]

@richlander In my opinion @10Dev is right, put part of your comment into the Contributing Guide and make that a bit softer. The soft approach could be something like this:

"We will accept contributions that make WPF cross platform provided that they come through high quality pull requests, which include:

• a detailed architectural plan justifying the decisions made
• detailed specifications of the changes made
• good test coverage for the contributed code
• widely adopted, stable and high quality dependencies."

This would kill basically all "hit-and-run" contributions I assume you're afraid of 😄

[danwalmsley]

Why not focus on existing projects already modelled from uwp and wpf like http://github.com/AvaloniaUI/Avalonia that make this already a reality, with many apps already using it.

[zezba9000]

@danwalmsley (Unless this has changed) The big issue with Avalonia is it doesn't generate C# types in a partial class for the code behind allowing for type safe / compile time checked XAML. Which both WPF and WinUI do. This is a huge advantage over HTML, Androids UI, QML etc. Without this Avalonia really isn't that different from using some other UI that relies off runtime errors instead of compile time ones.

Also companies like Telerik etc aren't supporting it like they're with WPF and WinUI. You say we should extend existing projects but why not extend the ones that already have much larger support and tools? I see nothing wrong with changing direction when new doors open is all I'm getting at.

[kekekeks]

DevExpress/Telerik products also rely on Win32 API or DirectX. We've tried to port some open-sourced Telerik controls from UWP to Avalonia and discovered that we can't because they are using custom DirectX rendering.

[worldbeater]

Glad to see .NET evolving! Hope Avalonia will also become a part of .NET Foundation someday. Really an impressive framework with poweful styling system. WPF, beloved by many developers, could borrow some ideas from that framework, like value conversion syntax, binding to async values or binding from code. Worth mentioning, that we can already create cross-platform applications using ReactiveUI or Caliburn.Micro frameworks alongside with Xamarin, WPF and Avalonia :1st_place_medal: :100:

[HumanEquivalentUnit]

@Kryptos-FR

Seems like Microsoft still has a lot to learn how open source and communities work. [..] You have people ready to contribute for free to the project so you need to show at least some respect for their wishes and be more open minded

Have we learned nothing from the recent Node/NPM disaster? Communities don't get to make demands on people who give their hard work away for free. Even if it's Micrsoft and even if you hate them.

See Rich Hickey (creator of Clojure)'s comment here: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.

Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints.

Asking for it, asking about it, is OK. Stating that someone needs to listen to you because you have demands and you want more free things, is not OK.

However the gravity to use existing knowledge and code bases is probably strong for WPF. Just look at the stars on WPF vs WinUI in GitHub... people clearly want a WPF like Desktop solution more than something else. From what I can tell. Its a lot faster to dev with for sure.

People are aware they can pay for Windows and get WPF .. right?

[juanfranblanco]

@worldbeater it looks that you are trying to achieve the same as me, mixing ReactiveUI + "xUIFramework" (Prism, MVVMCross, Caliburn.Micro) to create a generic set of guidelines / framework for cross platform applications (https://github.com/Nethereum/Nethereum.UI.Desktop). Your example is excellent (https://github.com/worldbeater/ReactiveMvvm).

Now although slightly off topic if we could have alignment on frameworks too (Prism, Cross, Caliburn, MvvmLight) that could support all platforms, for scenarios simple and complex (depending on the platform) for navigation, menus, good old regions, module injection, etc that will be awesome, so much knowledge, work and many lessons learnt we had with WPF, Silverlight, Xamarin, Avalonia, etc, etc and all the frameworks that have been created to support them.

[glyad]

Have you seen https://github.com/AvaloniaUI/Avalonia ?

I just want to explain, why I can't like your proposal with Avalonia.

1. Your advertisement is off topic, since we are discussing WPF here.
2. The AvaloniaUI is pretty nice project, great work, but...
3. AvaloniaUI lacks compatablity with WPF framework;
4. it's simply impossible to compile WPF-based sources (excluding platform dependend code) with Avalonia
5. it hasn't support from UI control vendors;
6. etc...

Let's think together, how to reanimate really great framework, which serves thousands of serious projects perfectly, and do not vaste community resources with to develop another Xamarin, or Silverlight, or UWP, or something another.

[ebugusey]

It's an open source project. You can fork it and do with it whatever you want. If dev team doesn't want to support some other platform it's in their right to do so. Because being cross-platform is not easy, especially for UI components.

[legistek]

It's amazing to me how some people think open source means they get to demand that the maintainers do whatever is asked of them with no right to pursue their own strategic agenda.

Microsoft didn't have to open source WPF at all. I'm extremely glad they did. I've wanted cross platform WPF for many years. (Not Avalonia; not Xamarin.Forms (though I am a fan of that too); I wanted to be able to take my existing WPF apps and simply recompile them to other platforms).

The only thing that was impeding that from happening was the closed source license (the reference source was always public, but it was not licensed to make derivative works). Now that that barrier is gone, cross-platform WPF will eventually happen. Whether Microsoft bankrolls it is a different story. I don't see Apple or Linux Foundation investing much in Windows app development...

All that aside, I think the difficulties in making WPF cross platform might be a smidge exaggerated. I've studied the aforementioned reference source extensively. The overwhelming majority of it does not depend on Windows, because unlike Windows Forms, as we all know WPF handles all the rendering from the top level window on down.

And when you think about it, WPF was architected to be cross platform, and we know this - why? - because of Silverlight! Remember, Silverlight ran on MacOS eons ago. So we know it can be done. Trivial? No. Doable? Absolutely. So now the community can take a stab at doing it finally and will start out 90%+ of the way there.

[4creators]

@legistek Very good point indeed.

For a while I was afraid that MSFT will decide to keep WPF as closed source what would make any work in making xplat support for WPF/UWP based .NET UX platform much more difficult. I fully understand MSFT position due to currently insignificant market share of Linux desktop and availability of recently aquired Xamarin xplat mobile framework. It does not make sense for company to double invest in xplat UX which would mainly target mobile devices.

However, it is different story with FOSS community. MSFT enabled us to make WPF/UWP cross platform and it is up to community to get it done. Since none of the UX repos would accept any code for xplat support we have no choice but go for it in independent fork. I would not be surprised if some folks from MSFT would join such community effort on their own though.

There is long lived thread https://github.com/dotnet/designs/issues/12 which is used to track this issue where we received clear answers from dotnet maintainers @jkotas and @AdamYoblick how community should proceed. We should work in community forks and since all CI infrastructure is or soon will be based on Azure DevOps we could leverage free open source offerring https://github.com/dotnet/designs/issues/12#issuecomment-444563442.

I have created organization DotNetUX and forked wpf, winui, winforms repos there and plan to work on porting wpf/winui to macOS and Ubuntu by leveraging already existing oss libraries with DirextX translation layers to vulcan and metal. If anyone wants to join the effort and shape it's goals pls ping me.

By any means I am not trying to be the lead of team working on such project nor the lead developer. I am ready to share or even transfer ownership of this repos/organization to recognized open source foundation or organization with wide OSS community representation. By living up to the standards of oss communities I would like to participate in a community where every actively contributing member would have equal rights with regard to determining project directions and accepting commits.

[zezba9000]

@legistek @4creators I agree, the difficulty of porting WPF seems exaggerated (while it would take some time). You just have to replace some Windows only dependencies with platform agnostic ones.

The major breaking changes that would need to happen or I say should happen is:

1) Replace D3D rendering back-end with an agnostic graphics API that can target D3D9-12, D2D, Vulkan, GL, GLES, Metal, etc. Any open source frameworks like Telerik or whatever that depend on D3D could just get ported at some later date to the newer platform agnostic graphics API this folk of WPF is build on.

2) The HLSL lang used for shaders could get replaced with C# syntax using Rolsyn to transpile a C# subset to different GPU program targets like HLSL, GLSL, CG, etc for maximum portability which also allows for a better degree of control and familiarity.

3) Other aspects like MessageBoxes and most other commonly used WPF features etc from an API point of view would be 100% or near 100% the same as just the WinAPI part need to be made agnostic on the backend.

In short you may want to think of this WPF version as you think of .NET Core to .NET Framework. They are largely compatible but some critical frameworks and moving parts need to be changed to make it run smoothly on more platforms.

[juanfranblanco]

@glyad i have by no means any relationship with Avalonia, so no advertisement, but after evaluating for ages many cross platform solutions, and knowing how difficult will be to implement WPF, the closest solution is Avalonia. Up until now the WPF internals were not available, now you actually have the possibility to use them to make a compatible layer with something like Avalonia, which aims to be very similar to WPF. Also we could start talking about the Xaml Standard, but that did not go anywhere. Why duplicate when you can collaborate an enhance.

[kekekeks]

make a compatible layer with something like Avalonia

I'm planning to take a shot at compatibility layer once the entire code base is available. I believe it could be done without modifying the code base by replacing some classes with shim implementations using MSBuild only. That could live as a repo that uses WPF as a submodule, so keeping the source in sync with this repo should be easy.

The thing is that our DrawingContext API is almost identical to one in WPF, so wrapper would be rather thin. I'll have to add a partial class to make System.Windows.Controls.Control to implement IVisual. That would allow to render WPF control hierarchy using existing Avalonia rendering engine.

Window class and PresentationSource would most likely need to be rewritten completely. The input system could also live as a compatibility shim.

Our layout and input systems are really, really close, you can take a look at our embedding to WPF implementation here. We are using D3DImage/WritableBitmap for rendering, but that boundary isn't needed if we are in control of the rendering system.

Said compatibility layer would allow to mix and match WPF and Avalonia controls.

[glyad]

@juanfranblanco, thank you for your answer. I'm sorry for my sentences with "advertising of Avalonia". Anyway, the key question is about of the compatibility on a level of the public interface with current version of WPF framework, e.g. can I compile my existing WPF sources with another WPF-like framework, like as Avalonia, or not. I started to develop with WPF at 12-03-2006. Since December 2006 I developed, architectured, consulted more, than 100 projects in Israel. At least part of them is still in life till now, but no company will rewrite tons of code (+XAML). There is the only way for WPF future and this way is to become cross-platform preserving full compatibility with public interfaces. If Avalonia can answer to this qestion , it's welcome!

[juanfranblanco]

@glyad don't worry I fully understand, companies won't invest if they don't see a clear future of the platform as a whole (ie cross platform), even if 90% of their users will remain in Windows.

[kekekeks]

@glyad "Full compatibility with public interfaces" will never happen, because public interfaces aren't cross-platform.

A notable example would be PlacementMode enumeration for popup. It has Absolute and AbsolutePoint values that need a way to position the popup relative to screen coordinates. In Wayland protocol which is now replacing X11 there is no such concept as "screen" coordinates. You can only have some kind of positioning rules that allow to place your popup relative to some other surface (window or popup). If you are relying on absolute window coordinates (like AvalonDock) that won't work either.

WebBrowser control is tightly coupled with internet explorer in-process engine. Even if one would somehow implement the entire DHTML COM API on top of Chromium, modern web browsers have their javascript and rendering in a separate process.

WPF allows you to run UI on any thread. There is no way you can do this on OS X with Cocoa. So all your code that creates windows from background threads simply can't work on Mac.

Anything you are doing in overridden WndProc will simply won't work. Mono has tried to emulate window messages that are going through WndProc for their managed WinForms implementation and that ended poorly.

There are also tons of WinAPI-specific and ActiveX-related stuff that can't be portable.

The list goes on and on.

Basically, the only thing you can get is some Silverlight-like subset of API. We can do some kind of compatibility layer on top of Avalonia that allows to run 80% of WPF views, but that's it.

[glyad]

Thank you @kekekeks,

You're right. I fully understand the issue with constrains mentioned. Yes, it looks impossible to port some things in their current meaning as is. Could you agree that VS-like (AvalonDock-like) UI is possible on Wayland? So, it's about an issue with platform dependend definitions of things.

The example with browser was really great! The browser control was based on IE7 (I don't remember exactly). It was showstoper for many usage scenarios with modern html/js content. I solved this problem in following way: (1) detect the latest installed version of IE com server, (2) instatiate the IE component in borderless window (3) create my own window z-index manager (4) show IE component's window on top of the owner window, (5) change position, sizing, and visibility of IE hosing window in concequence with behaviour of owner window. It's all about how to render some things on various platforms.

Issues with coupling to Win32 and COM API's are more complicated. I also think that most of them aren't resolvable. OK... There are platform constraints for full compatability. Probably, for the part of them may be possible to find implementational work-arounds.

You wrote "Basically, the only thing you can get is some Silverlight-like subset of API". YESSS! Silverlight 5 was the best candate to make great cross-platform UI framework. We developed desktop level applications srarting from using of versions 4 and 5 of Silverlight. I think, need to continue with SL5 way to achieve "portable WPF".

Regards,

[kekekeks]

Could you agree that VS-like (AvalonDock-like) UI is possible on Wayland

Yes, but AvalonDock will have to be reimplemented to use drag-n-drop instead of tracking window positions.

The problem about WebBrowser is ObjectForScripting and Document properties. It's expected that they allow JS code to interact with C# and vice versa. That won't work property because of multiprocess architecture of the modern web browser engines where web content runs in a separate process in sandboxed environment.

I think it should be possible to run most of the xplat controls on top of existing Avalonia rendering engine. Flow document model might be tricky since we haven't quite yet finished our own one (still struggling with text layout engine on top of Skia). Viewport2D currently can't be supported since we don't have proper integration with OpenGL yet.

[popcatalin81]

I would really love WPF on Raspberry PI ... it would be the dream.

[valeriob]

Someone else is doing the most promising xplat ui toolkit, and it's not Xamarin :( https://youtu.be/D-o4BqJxmJE?t=538

[raffaeler]

It would not make sense for Google to promote a Xamarin based solution given the size of the package and the problems the community is meeting. Xamaring can work decently for business apps, but IMO is certainly not a general purpose solution.

[valeriob]

It would not make sense for Google to promote a Xamarin based solution given the size of the package and the problems the community is meeting. Xamaring can work decently for business apps, but IMO is certainly not a general purpose solution.

Yea ofc, i mean it's sad that google is tackling the problem and not Microsoft. I'm not saying that WPF should be that solution, it's just that i see a big opportunity not being perused by Microsoft. Google is preparing the road for THE native platform to develop native application for, so they will be able to innovate Android (with Fuchsia of whatelse on the desktop). Microsoft is not doing anything in that regard, meanwhile they dropped Edge, so google is going to control the developer space in the future with this trend.

[raffaeler]

It is sad indeed. There have been multiple occasions in the past, but they tried to force UWP adoption with the 'Windows only' restriction which is a no-go since a long time. The currently most widely adopted solution is Electron which has the big advantage to reuse web skills (it's hard to find a XAML developer, far more easier an html/css one).

[dotMorten]

would really love WPF on Raspberry PI ..

You can already run UWP-based xaml apps on them. Performs better too

[zezba9000]

would really love WPF on Raspberry PI ..

You can already run UWP-based xaml apps on them. Performs better too

UWP on the Pi doesn't use the GPU. Linux is way faster in every area on those things.

[dotMorten]

Use a dragonboard instead and you'll get full DX acceleration

[zezba9000]

Use a dragonboard instead and you'll get full DX acceleration

I have one (they're cool), still slower than using Linux on a PI with GPU acceleration that requires way less power to do the same thing and cost a lot less too. More bang for your buck when you use GNU Linux and a lightweight compositor :)

[Nassiel]

I don't really get the point of developing WPF for a cross-platform .net framework and develop it as a non-cross platform. I could understand that WPF depends too much on DirectX... but we already have the standard.net for that, why a new one which do the same? This one should be based on OpenGL to make it truly cross-platform. But, well I just hope you'll recapitulate.

[KodamaSakuno]

I don't really get the point of developing WPF for a cross-platform .net framework and develop it as a non-cross platform.

The original .Net Framework is dying, it's hard to get more features which .Net Core has at the same time. By moving to .Net Core, desktop apps can get much benefit from .Net Core with new APIs, language features and performance improvements.

[kekekeks]

This one should be based on OpenGL to make it truly cross-platform.

For your information OpenGL is deprecated on Mac OS X and the support for it will be removed in the future.

[zezba9000]

This one should be based on OpenGL to make it truly cross-platform.

There is no such thing as a fully "native" cross platform graphics, audio or input API. There are always some platforms that don't support one vs the other because of hardware or OS reasons. You have to use agnostic APIs / standards that sit on top of these fragmented layers.

[feliwir]

Like https://github.com/mellinoe/veldrid