SFML.Net 3 - Planning

[eXpl0it3r]

I thought to create an issue to collect some of the ideas that have been floating around, that could potentially be implemented with SFML.Net 3. Feel free to add your comments on any topic below. If something requires a bigger discussion, we can always split into separate issue.

• Span API: Add Span APIs #185
• Naming convention adjustments? Interfaces do not follow C#'s naming convention.  #204
• Reduce PInvoke calls whenever possible and without duplicating the implementation logic
  • Use IEnumerable<Vertex>
  • Prefer TimeSpan instead of SFML.System.Time
• Support for AOT

.NET Version

Currently SFML.Net uses netstandard2.0 which provides maximal support for .NET Framework as well as .NET 6+

I'm of the opinion that as a library we should try to retain maximal support for as long as possible. As such I'm advocating for staying with netstandard2.0 and pulling in "polyfill" NuGet packages as needed.

At the same time, I do acknowledge that .NET Framework has long reached its EOL, even if it's still "supported" by Microsoft and thousands of applications still using it. As such I'm also open to move away from netstandard2.0, breaking support for .NET Framework, in the cases where a feature is very beneficial but not netstandard2.0 compatible.

Does multi-targeting provide any benefits?

[ShadowMarker789]

.Net Framework totally hasn't reached EOL.

Since the .Net Framework is a part of Windows itself - the Windows support lifecycle applies to the entirety of the versions of Framework that the OS supports.

With Windows 11 still fully supporting .Net Framework, it'll be many, many years for it to still be used and relevant, particularly in the enterprise space (where I still use it, for reference).

Unless you have very specific needs (such as interface default implementations, interface static methods, unmanaged function-pointer jangling) I don't think there's anything that you can't do in NS2.0.

I am confident that one can expose out a modern .Net API for the entirety of SFML3.0 so long as the capabilities are exported sufficiently in CSFML.

Not that I ever expect .Net Framework to "really die" anyway.

Besides, .NET Framework 4.8 was only released Apr 18, 2019. That's not ancient.

[WBMPH]

Would there be a way to have SFML.Net run in the browser under wasm?

[eXpl0it3r]

No, as SFML / CSFML doesn't support this use case.

[JackTheSpades]

Perhaps consider using the built in Vector/Matrix structs of the System.Numeric namespace for floats at least where possible? And of course things like the actual Drawing.Color struct instead of the custom SFML.Graphics one.

[eXpl0it3r]

And of course things like the actual Drawing.Color struct instead of the custom SFML.Graphics one.

System.Drawing has some OS specific limitations, as such I'd rather not use that namespace and thus not use Drawing.Color.

[LeftofZen]

I personally don't think supporting .NET Standard is worth it. .NET 6+ provides many performance benefits a low-level library like this one can utilise and keeping it on Standard is hamstringing yourself at this point.

Agreed on relying minimally on Windows-only code (like System.Drawing) and using more cross-platform structures.

[ShadowMarker789]

I personally don't think supporting .NET Standard is worth it. .NET 6+ provides many performance benefits a low-level library like this one can utilise and keeping it on Standard is hamstringing yourself at this point.

Agreed on relying minimally on Windows-only code (like System.Drawing) and using more cross-platform structures.

We use SFML.Net in .Net Framework applications and moving to .Net 6+ would break compatibility and render it unusable in our deployments.

As it happens, we use SFML.Net in enterprise development right now, and we don't have any viable alternatives to migrate to without significant development burden. We used SFML.Net as a drop-in replacement to our legacy WinForms GDI+ drawing routines.

[WBMPH]

Nothing prevents you from staying on version 2? I personally think the benefits outweigh sticking to a legacy framework.

[charleyah]

Everything listed so far is achievable in .NET Standard 2 with limited tooling for AOT, but still achievable.

Staying On .NET Standard 2

• Retains .NET Framework compatibility.
• .NET Spans can be provided by adding System.Memory dependency.
• .NET Vector Types can be provided by adding System.Numerics.Vectors dependency.
• AOT can be implicitly supported, but there won’t be tooling available to identify any code incompatibilities. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=windows%2Cnet8#limitations-of-native-aot-deployment
• Won’t benefit from compile-time IL Gen improvements in .NET 6+
• In theory, should still benefit from runtime and JIT code gen improvements in .NET 6+ that don’t rely on specific IL Gen or API hints not available in .NET Standard. https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/

Moving To .NET 7+

• No .NET Framework compatibility.
• .NET Spans are available.
• .NET Vector Types are available.
• AOT can be explicitly supported with code warnings to identify incompatibilities.
• pinvoke compile-time stub generation that would remove potential startup overhead would be available. https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke-source-generation
• Can benefit from all performance improvements from .NET 6+

Multi-Targeting .NET Standard 2 and .NET 7+

• AOT can be explicitly supported while retaining .NET Framework compatibility.
• pinvoke compile-time stub generation would be available, but at the cost of duplicating pinvoke code for the two targets.
• In VS 2022 at least, multi targeted .NET projects have clear warnings to identify what APIs aren’t available in a given .NET target to ensure code is portable.

My Thoughts

The performance considerations aren’t definitive without benchmarks to guarantee how better performance will be by compiling SFML.Net to .NET 6+.

If AOT is desired, I would suggest multi-targeting if .NET Framework compatibility is retained. That way, the tooling is available to verify the project’s AOT compatibility at compile time. A .NET 8 AOT published app targeting Windows using SFML.Net 2.6 can a display SFML window today. So, there is some feasible AOT compatibility already on Windows.

Multi-Targeting will help bridge new features in, but ideally shouldn't be done at the cost of code duplication for each target. AOT tooling is a project level configuration so won't have this issue. If there isn't clearly identified features that SFML.Net can benefit from in .NET 6+, then there isn't much reason to drop .NET Standard.

.NET Framework may not be receiving any further development outside of security and future compatibility updates, but it’s certainly not dying any time soon sadly. For reference .NET 4.6.2 end date is January 2027 and .NET Framework 4.8.1 has no end date yet. https://learn.microsoft.com/en-us/lifecycle/products/microsoft-net-framework

[TheVeryStarlk]

I agree with LeftofZen on to move from Standard and support modern .NET versions (7+) for SFML 3.0. This would also make it possible to make SFML AOT-friendly by refactoring from using DllImport to LibraryImport.