Tracking issue for Silk.NET 3.0

Question

Tracking issue for Silk.NET 3.0

Perksey opened this issue 5 years ago · 33 comments

Perksey commented 4 months ago

Not today

👀2

Answer 1 · 2021-02-26T21:07:23.000Z

For clarification. Would WebGL bindings mean that a Silk.NET project could run in the browser over Web Assembly (WASM)?

Answer 2 · 2021-02-26T21:24:47.000Z

Yeah exactly, our WebGL and WebGPU bindings are intended to work on Blazor WASM once created to maximise portability of .NET 6 apps.

Answer 3 · 2021-08-27T21:43:41.000Z

Mentioned in #345; Just wanted to add a +1 for MAUI support.

Answer 4 · 2021-08-27T23:41:48.000Z

MAUI support would also mean WinUI 3/Uno platform support I believe too, so that'd be cool.

Answer 5 · 2021-08-27T23:58:09.000Z

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.

Answer 6 · 2021-09-13T12:07:11.000Z

@Perksey FYI: for an ongoing example of a .NET 3D engine supporting WinUI 3 project reunion example

Answer 7 · 2023-01-16T04:14:51.000Z

Any idea when we'll get Metal bindings?

Answer 8 · 2023-01-16T04:16:50.000Z

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

Answer 9 · 2023-07-27T18:06:24.000Z

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

Answer 10 · 2023-07-27T18:06:44.000Z

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!

Answer 11 · 2023-07-27T19:55:39.000Z

I think GLFW bindings are arguably < 0, I think we agreed those are a good PoC?

Answer 12 · 2023-07-27T19:58:01.000Z

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.

Answer 13 · 2023-07-27T20:09:34.000Z

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

Answer 14 · 2023-07-27T20:10:13.000Z

Okay, done thanks.

Answer 15 · 2023-11-21T06:22:11.000Z

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

Answer 16 · 2024-01-21T02:02:49.000Z

Unless current plans change, generic math should get bumped up to preview 1

Answer 17 · 2024-01-24T03:36:18.000Z

SilkTouch Notes

Mods should be able to declare ordering, TransformFunctions currently must be before PrettifyNames because PrettifyNames, despite having a ridiculous amount of code accounting for it, isn't fully compatible with having lots of functions with the same name. This is its own issue that needs to be worked through, but for now the solution is just whacking the TransformFunctions at the end of the pipeline.
- Is this because of return type conflicts? Should we make this a better experience?

Answer 18 · 2024-12-18T09:36:34.000Z

please, keep WPF and WinForms integration. Those are needed for real

Answer 19 · 2025-01-14T06:58:47.000Z

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?

Answer 20 · 2025-01-14T12:41:52.000Z

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.

Answer 21 · 2025-02-05T20:49:16.000Z

Keep it up gents. You got this.

Answer 22 · 2025-02-05T21:56:24.000Z

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.

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.
Semantic versioning! That's what Major-digit releases are for. 🤭

The team is doing fantastic work!

Answer 23 · 2025-02-05T22:06:27.000Z

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.

Answer 24 · 2025-02-05T22:09:08.000Z

Very interesting. Thank you for explaining and breaking this down!

Answer 25 · 2025-02-11T21:37:33.000Z

Big tracker update today! Windowing 3.0 has just landed on the experimental feed, it is in theory implemented on all platforms but we haven't tested Android or iOS yet. Win32 bindings have started work thanks to the excellent @curin (who is also reviewing all of my stuff, the guy never stops) and may make it into 3.0 Preivew 1. Input's proposal work is now approved as well (thanks to a great many contributions from @domportera!), and this is next to start implementation (likely by me). OpenAL bindings remain the last thing after this that stands before a 3.0 Preview 1, and I would personally love if a community contributor wanted to give it a go but if not this should be an easy thing to do at the tail end of the dev cycle.

Thank you to the experimental feed early adopters, you are amazing and your input is really valuable!

Answer 26 · 2025-04-12T17:53:37.000Z

@Perksey
Regarding Windowing 3.0, based on #209 (comment)

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

One can conclude that the 2022 windowing 3.0 proposal has outdated backend definition

The decision has been made to drop SDL due to complications and the fact that all non-desktop targets are distinctly unique in their own right. We believe that in creating platform-specific code for each of these will result in significantly more robust support for each of these platforms.

QUESTION: Should we drop our SDL bindings too?
MAINTAINERS' ANSWER: Yes, it's no longer used by us and a library such as SDL is a large amount of maintenance weight to carry. Akin to us dropping EGL in the 1.X-2.0 transition, we will be dropping our SDL answer.

BTW, going forward with SDL3 was a very solid choice, it's kind of unofficial industry standard, promoted by Epic and Valve, hard tested, and virtually supports any gaming platform still alive

Answer 27 · 2025-04-12T18:03:05.000Z

Yes this is true, the proposal is out-of-date, but I vaguely recall putting some "the team reserves the right to change the reference implementation" get-out wording in there so... I guess it's still correct?

Answer 28 · 2025-04-12T18:05:11.000Z

Correction: it's this issue that is linking to an out-of-date proposal. The main branch has a rewritten proposal.

Answer 29 · 2025-04-12T18:12:05.000Z

windowing 3.0 all good, thanks for the clarification

Answer 30 · 2025-07-01T19:43:38.000Z

@Perksey is it possible for Silk.NET 3.0 to take advantage of the SDL3 main callbacks optimizations for mobile?

There are platforms that would rather be in charge of that while loop: iOS would rather you return from main() immediately and then it will let you know that it's time to update and draw the next frame of video. Emscripten (programs that run on a web page) absolutely requires this to function at all. Video targets like Wayland can notify the app when to draw a new frame, to save battery life and cooperate with the compositor more closely.

Answer 31 · 2025-07-01T19:44:49.000Z

@3xau1o yes and on the 3.0 branch we already are.

Answer 32 · 2025-07-06T05:58:24.000Z

@Perksey Is 3.0 branch can use OpenGL ES as WebGL when compiled as wasm as of now?

Tracking issue for Silk.NET 3.0

Silk.NET 3.0 Roadmap

Overview

Proposed Features

SDP

Windowing

Input

SilkTouch & Bindings

Generic Maths

Milestones

Untracked Features

SilkTouch Notes