Tracking issue for Silk.NET 3.0 #209
Comments
|
For clarification. Would WebGL bindings mean that a Silk.NET project could run in the browser over Web Assembly (WASM)? |
|
Yeah exactly, our WebGL and WebGPU bindings are intended to work on Blazor WASM once created to maximise portability of .NET 6 apps. |
|
Mentioned in #345; Just wanted to add a +1 for MAUI support. |
|
MAUI support would also mean WinUI 3/Uno platform support I believe too, so that'd be cool. |
|
We have included MAUI support in our work in progress software development plan for 3.0 and will likely be our top priority after WinForms and WPF support, which analytics and discord activity indicate are in massive demand. This is definitely something we are keen on getting in. |
|
@Perksey FYI: for an ongoing example of a .NET 3D engine supporting WinUI 3 project reunion example |
|
Any idea when we'll get Metal bindings? |
No ETA for Metal, and its not something the team is working on at all right now, but we welcome any contributions to move us forward |
|
@dotnet/silk-dotnet I've tried to extrapolate all the info from the proposals (as currently approved) into this issue (see the updated description). It makes no assumption on the outcomes of the current SilkTouch or SilkTouchX/SilkX work, mostly just wanted this for tracking. Please let me know if you have any issues with the above. |
|
Likewise, if there's any other untracked promises for 3.0 we've made or the community wants to be made, please let me know! |
|
I think GLFW bindings are arguably < 0, I think we agreed those are a good PoC? |
|
Yes you are right... but do you really want a priority -1? That just feels silly! Unless we're using unsigned integers, then we'll a priority 4,294,967,295... I expect the SilkTouch Design & Development and GLFW bindings tasks to complete at the same time. |
|
I mean it doesn't matter so much, but I'd see GLFW PoC as a separate point - leaving Prio 0 GLFW as an additional item |
|
Okay, done thanks. |
|
I've updated the issue to reflect latest developments. This also has been changed to indicate that we're using SDL3 instead of GLFW as I believe is the consensus on the team, primarily because I've backed down haha |
|
Unless current plans change, generic math should get bumped up to preview 1 |
SilkTouch Notes
|
|
please, keep WPF and WinForms integration. Those are needed for real |
|
I am looking into using silk to replace other c# bindings in a project. Is it worth waiting for 3.0? What is the super rough time frame? |
|
I probably wouldn't wait as we have absolutely no guarantees that 3.0 will even release, let alone a timeframe for that happening. However, we are putting massive amounts of work into 3.0 so it probably won't be too far off, but still likely longer than the time it would take to build an app with 2.0 and migrate to 3.0 later. We hope to have a good migration story for 3.0 but can't promise it as it is a very breaking release. |
|
Keep it up gents. You got this. |
I don't know about others, but I for one am all for a breaking-but-uncompromised release more so than one that misses out on things due to a need for backward compatibility. The team is doing fantastic work! |
|
Thanks! To clarify where my head is at (this is not representative of the team), I am not backing down on breaking the API - our current API surface is not kind to IDEs and for this and many other reasons it must change in 3.0. The idea is if you have a 3.0 package in your dependency tree that you know about, then you’re opting into 3.0’s API. However, I believe that there’s something we can do about ABI compatibility and this is what I want to research further. Again this is my view, not that of the team, but ABI compatibility is important now that we have e.g. Uno Platform pulling us in - by being a complete ABI break, 3.0 would be unusable on Uno Platform, which is not what I want. I also want to show that we are dependable for these types of big solutions. So the goal would likely be 3.0 shipping reference assemblies with only the 3.0 API, but the assemblies containing a stub implementation of the 2.X ABI to forward to the 3.0 API. This way if you’re referencing a 3.0 package, your IDE will never pick up on the 2.X APIs, but they’ll be there just in case you pull in a package or an assembly that was built against 2.X. This also provides a nice migration story given that you can keep your code that is yet to be migrated in one project referencing 2.X, and slowly start moving it to another project that references 3.0 while still using code from your 2.X project. However, a lot of research needs to be done into this to see if it’s even feasible (there are a lot of problems to be solved with abusing reference assemblies in this way) so no promises and again I can’t stress enough that this is my idea and the Silk.NET team may shut it down. |
|
Very interesting. Thank you for explaining and breaking this down! |
Silk.NET 3.0 Roadmap
THIS IS A LIVING DOCUMENT
Overview
Welcome to the Silk.NET 3.0 roadmap! This tracks the current progress of 3.0 - the major rewrite project for Silk.NET 3.0. You can read more about why we're doing this in the 3.0 proposal, but basically the .NET world has changed a lot since Silk.NET was originally written (Silk.NET was written against .NET Core 2.1, long before "One .NET" existed), and we want to ensure we ship a library that encourages write-once-run-everywhere and embraces user feedback and modern bindings techniques developed elsewhere within the .NET Foundation.
Learn more about Silk.NET 3.0:
Proposed Features
SDP
Windowing
Input
SilkTouch & Bindings
Generic Maths
TODO
Milestones
NOTE: The below milestones will be complemented by regular experimental feed updates. The Silk.NET team may add additional previews at their discretion.. Rough timelines for each of the previews may be added to this issue at a later date if the Silk.NET team has a high degree of confidence that they can be met.
THE FEATURES IN EACH PREVIEW SPECIFIED HEREIN DO NOT NECESSARILY HAVE TO BE COMPLETED IN THAT ORDER, IF YOU WOULD LIKE TO WORK ON SOMETHING, PLEASE DO SO! The dependencies for each work item are specified in the Proposed Features section.
The priorities above basically map 1:1 into previews as defined in the SDP's original roadmap as below:
Untracked Features
NOTE: None of these features are guaranteed for 3.0 and may be pushed to 3.X or cancelled altogether. Some of them have been demoted from the original priorities specified in the SDP.
The text was updated successfully, but these errors were encountered: