-
-
Notifications
You must be signed in to change notification settings - Fork 421
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Initial group codegen
* Fix some trimming oddities
* Fix HintTargetPGI and others similarly situated
* Base typing and namespacing
* Cast enum members, fix stray semicolons, Silk.NET.OpenGL builds again
* Group and bool transformations
* Fix erroneous cast order
* Add Delete(singular) overloads (ArrayParameterOverloader)
* Add SAL object model & Khronos length metadata parsing
* ArrayParameterTransformer w/ tests
* Integrate ArrayParameterTransformer
* Support SupportedApiProfileAttribute generation with metadata
* PrettifyNames conflict resolution now actually works
* Fix casting transformation ambiguity bugs
* Fix metadata retrieval for reserved identifiers
* Fix unit tests
* Fixup for all caps names
* Fix naive trimming bug
* More self-review comments
* SDL bindings
* Fix naming regression
* Prettify & extract the nested _e__{Union,Struct,FixedBuffer} structs
* Function pointer generation
* Add a second pass to name delegates based on usage!
* Fixes from self-review
* Windowing 3.0 Iteration 1 with Dependency Injection - scrapped
* WIP Windowing 3.0 for real this time
* Some more work
Will be pausing here as I need to change the bindings, and to be honest I don't want to do that without doing the SilkTouch refactor first.
* Rejig the repo structure
* Save progress, as I am deleting the progress
* Create a Roslyn compilation & workspace
* Bugfixes, generation runs with renaming but is slow and outputs wrong
* Some more bugfixes
* Fix mods not saving outputs, unnecessary subdirs, filenames, and other renamer issues
* Add IResponseFileMod, fix EntryPoint not in DllImport, and other fixes & improvements
* Delete some stray files
* Minor nits
* Initial commit of the SymbolFinder rename experiment
* This is the new renamer
* Fix ctors and dtors, stop using `using static`s
* Regenerate bindings
* Use public Roslyn APIs and parallelise
* Fix buidl
* Add ISurfaceProvider
* Add a write-up on the PAL HLU concepts/status for the future
* Remove the hosting API
* Start on a more clean sheet and conservative implementation
* Separate files
* Lay out impl, add new APIs from proposal
* Add a Utf8String helper type, and transform string constants to use it
* Move bakery functionality into a mod separate from SupportedApiProfiles
* Rename GetTypeDeclaration to BakeMember
* Cache the result of function pointer loading
* Fix vulnerability?
* Recognise some #define enums, improve pfn type gen, update SDL, more fixes
* Update ClangSharp (with no changes!!!!1111!1!!!111 🎉)
* Commit cache files too
* Add SDL_gpu (and other missing headers such as SDL_vulkan)
* Check-in rsp changes, add namespace for windowing, add SDL_main bindings
* Work on more of the implementation
* Triangle with Silk.NET.Windowing 3.0
* Implement all APIs
* Wire up all relevant events
* Sweep a macOS deficiency under the rug
* Apply initial configuration, surprisingly little code...
* Initial work on native build workflow
* Stop using YAML for GITHUB_OUTPUT
* Add GH_TOKEN env var to stage2
* Use an action for comment writing instead
* Fix permissions, try to fix expr issue
* Same again
* Fix PR comment location
* Replace the comment rather than append to it
* Start of native build job
* Attempt to fix matrix
* Add a job name, fix build script permissions issues
* Add OSX build for SDL
* Start of commit job
* Add missing checkout
* Use official action to checkout PR
* Fix permissions issues
* Update native binaries for bc82423
* Start of linux-x64 SDL build
* Sudo for apt
* apt-get update
* Checkout submodule
* Fix path error
* Update native binaries for ece2459
* Add linux-arm and linux-arm64
* Use glibc 2.34 on linux-arm for Y2038 support
* Update native binaries for 3e3df2c
* Add win-arm, win-arm64, win-x64
* Fix dir structure
* Attempt to keep win-arm support, may be on the chopping block though
* Fix batch script error
* Use curl instead of wget?
* Fix winsdk install?
* Remove 32-bit Windows on Arm support
* Use a Microsoft Developer Command Prompt
* Fix vcvarsall path
* Use Ninja - libsdl-org/SDL##11487
* Update native binaries for 601bb66
* Fix artifact download path
* Fix the fix
* Update native binaries for 4630438
* Add iOS and tvOS for SDL
* Fix file permissions
* Update native binaries for 45f36d0
* Add Android build for SDL
* Apparently sdkmanager is not in PATH
* Install Python 3.11
* Install Ninja
* Update native binaries for d7d3c69
* Try to ungitignore the Android jar
* Update native binaries for f79ad90
* Add an easy update script
* Include org.libsdl.app bindings with the aar, working package now
* Update native binaries for 8cf95c2
* Some cleanup, and add docs
* Fix build
* Install workloads in test too
* Update native binaries for 186f907
* Fix build (not ideally)
* Update native binaries for 44b9933
* Dummy commit to run Test/Build again
* Remove old code
* Fix it
* Stop downloading previews?
* Add dependency to native package for SDL
* Fix build
* Only duplicate the VersionSuffix for natives
* Add SilkActivity
* WG comments
* Fix build?
* More build fix attempts
* Use the condition guards for xplat builds
* Fix csproj
* Clear locals to try and fix weird .NET SDK bug
* Add workaround from dotnet/maui#27215
* Fixes from self review
* Rectify remaining self-review comments
* nit
---------
Co-authored-by: The Silk.NET Automaton <9011267+dotnet-bot@users.noreply.github.com>- Loading branch information
1 parent
9bf9279
commit 1b87a6b
Showing
243 changed files
with
75,435 additions
and
37,459 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Binary file not shown.
Binary file not shown.
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
18 changes: 18 additions & 0 deletions
18
docs/for-contributors/Windowing/Implementations/SDL3/event-pump.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| # The Event Pump | ||
|
|
||
| The largest influence in the `ISurfaceApplication` design is the fact that for many platforms only the entry thread is | ||
| allowed to interact with the window manager (e.g. for the purposes of events). This creates a problem because rendering | ||
| is very much not single-threaded, nor are most use cases where the user has multiple windows. As such, | ||
| `ISurfaceApplication` gives the implementation freedom to decide what the most appropriate thread is to call into the | ||
| surface to raise events. This is further emphasised by the definition of `ISurfaceChildren` where the user can only | ||
| `Spawn` a surface, and not have a blocking call they can send off to their own thread. This allows the child windows to | ||
| use the same event thread and synchronization. This is likely inconvenient for rendering scenarios though | ||
| (e.g. for OpenGL where it's one thread per context/window, but all surfaces use the same thread by default...), for | ||
| which I expect that we'll add the ability to multithread for certain events in `SurfaceTimingOptions` or | ||
| `SurfaceTickOptions`. This however has been excluded from the initial 3.0 proposal. | ||
|
|
||
| Note that `SDL_AppEvent` is only guaranteed to be called on the event thread for events raised by the window | ||
| manager/operating system. As such, we always assume that those events are on the event thread when received and invoke | ||
| the window directly. For other events, we should be wary of concurrency. Note that I have absolutely no idea what this | ||
| means for things like our `Surface.Continue` method for `IsEventDriven` - right now this isn't implemented. Read more | ||
| here: https://github.com/libsdl-org/SDL/issues/11387 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| # Silk.NET.Windowing | ||
|
|
||
| Silk.NET.Windowing is our cross-platform windowing abstraction. For more information about what it is, see the [proposal](../../proposals/Proposal%20-%20Windowing%203.0.md). | ||
|
|
||
| As per the proposal, Windowing is implemented in exactly one project/assembly containing the abstractions and one | ||
| "reference implementation" given available target information (e.g. TFM). Today, this includes: | ||
| - SDL3, used for every platform. | ||
|
|
||
| If the user doesn't want to use our reference implementation, it is expected that they use the trimmer to make its | ||
| presence benign. | ||
|
|
||
| Note that for each "reference implementation" it is expected that there shall be a matching Silk.NET.Input "reference | ||
| implementation" capable of receiving an `INativeWindow` from the Silk.NET.Windowing implementation in use. How you | ||
| interpret this requirement is up to you, e.g. we could have a Silk.NET.Input Win32-specific implementation that uses | ||
| `Win32PlatformInfo` for our SDL3 surface, likewise we could have a Silk.NET.Input SDL3 implementation that receives a | ||
| `Win32PlatformInfo` from a Silk.NET.Windowing implementation and automatically creates a wrapping window - this is up to | ||
| you (but try to keep it sane please, that last one sounded extremely cursed). Ultimately, the goal is the user being | ||
| able to pull in `Silk.NET.Windowing` and `Silk.NET.Input`, create a surface, be able to do `surface.CreateInput()` and | ||
| it all Just Work. Right now, this equates to a 1:1 match of Silk.NET.Windowing/Silk.NET.Input implementations, and is | ||
| not expected to change. | ||
|
|
||
| Silk.NET.Input is completely independent from Silk.NET.Windowing this time around, unlike 1.X/2.X. This is because we | ||
| believe the Input HLU can target wider applicability beyond just receiving input for a window, with VR being the | ||
| principal use case in mind when making this decision. For more information, read the [Multi-Backend Input proposal](../../proposals/Proposal%20-%20Multi-Backend%20Input.md). | ||
|
|
||
| Most of the files within the top-level Windowing directory are exactly as proposed. The exception is the `Surface` | ||
| class, which seeks to make as much common as humanly possible (this includes the Render/Update timing logic and some | ||
| other auxiliary functions). Beyond that, this is functionally an interface. The actual entry-points into the Windowing | ||
| API, `ISurfaceApplication.Run` and `IDetachedSurfaceLifecycle.TryCreate`, are defined `partial`ly with matching | ||
| implementation parts in the `Implementations` subdirectories. | ||
|
|
||
| To find out more about the implementation details, see the `Implementations` directory. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| # Future Improvements | ||
|
|
||
| Initially when we were having design discussions around Silk.NET 3.0's Windowing API, we wanted to introduce a | ||
| lower-level API upon which our high-level API. The idea being that this would be an extensible API for which there would | ||
| be lower implementation friction and delegating common boilerplate code to a common higher-level implementation i.e. | ||
| there's very little work for us to do in mapping our API into new backends. This would functionally be a PAL, but the | ||
| details of this would depend on the actual requirements we derive as part of designing this API. Ultimately it was | ||
| determined that this work was simply out-of-scope for the initial 3.0 release as the extensibility benefits emerging | ||
| from having a lower-level API was determined to not be a requirement for the initial release, and was not included in | ||
| the original Working Group approved software development plan. | ||
|
|
||
| We're well aware this sounds very similar to what our friends at OpenTK are planning for 5.0, for much of the same | ||
| reasons. Indeed we still have community members who are also OpenTK community members that were advocating for it for | ||
| this reason. It's great to consider this sort of prior art, the sharing of insights and lifting eachother up is what | ||
| makes open-source amazing after all. We should also consider how other libraries like SDL and GLFW handle this | ||
| internally. Much like OpenTK, there is motivation for adding a lower-level API to Silk.NET to reduce the implementation | ||
| friction in adding more windowing backends as we believe esoteric platforms like mobile could be served well by them. | ||
| Unlike OpenTK, for desktop there's less appetite due to the shear number of platforms that would cause a lot of | ||
| maintenance effort - OpenTK 4.0 moved to use GLFW because of this, and most of the issues logged before this were | ||
| regarding its per-platform custom implementations, whereas Silk.NET 3.0 is keen to optimise for maintainability and | ||
| delegating maintenance effort to more expert sources (as we have done for SilkTouch by using ClangSharp's P/Invoke | ||
| Generator) like SDL is part of this so we can focus on crafting the best user experience specific to our project. Hence | ||
| why even if we would add this lower-level API, unlike OpenTK 5.0 I don't think we'd use it to implement desktop | ||
| windowing ourselves. But that can change after the initial release, and in any case having this lower-level API would be | ||
| useful. | ||
|
|
||
| When reviewing OpenTK specifically, their API design is indeed sound however the mechanisms by which it was exposed to | ||
| the higher-level API left a lot to be desired. Namely, using a dictionary of enums to implementations did not feel like | ||
| the best way to do this. There are likely more intelligent things we can do with the type system to make these patterns | ||
| more JIT friendly and also more extensible - having an enum enumerating the component types requires the extensibility | ||
| model to be defined in a way that is contrary to how the type system works e.g. to define components that are extensions | ||
| beyond our standard set. It was also deemed to be desirable to use `static abstract`s for this sort of low-level API, | ||
| which does help towards JIT friendliness, but this needn't prejudice any future efforts towards these goals - this was | ||
| just an idea. | ||
|
|
||
| Ultimately, to make our solution more write-once-run-everywhere, the API design philosophy behind the `Surface` | ||
| type was primarily to make it seem like a modular "component bag" e.g. `window.OpenGL` for OpenGL-specific | ||
| functionality, rather than having specific APIs always exposed as part of the standard interface but only valid for | ||
| usage in specific circumstances. The `IView` separation in 2.X achieved what we wanted somewhat, but this again left a | ||
| lot to be desired given that writing against `IView` instead of `IWindow` is contrary to what most users were doing | ||
| (this is also likely a symptom of being an afterthought introduced quite late into the 1.0 Preview cycle). By using this | ||
| design philosophy, our users have to get used to not assuming that functionality is available, meaning that users are | ||
| encouraged to write in a way that is portable instead of them having to go out of their way by writing against `IView` | ||
| as in 1.X and 2.X. | ||
|
|
||
| As for the extensibility goals (i.e. additional components being defined on top of our standard API), my hope was to | ||
| eventually have a `GetComponent` API on `Surface` which things like `window.OpenGL` were defined on top of. This has | ||
| been excluded from the 3.0 initial release, but we could in theory add something like this without the PAL concepts in | ||
| this document being implemented - a component-based architecture for our high-level API and a component-based | ||
| architecture for our low-level API can be developed independently. An example of why we might want this is a virtual | ||
| reality extension that manages the creation of OpenXR bindings from a surface, but this is just one example. It is | ||
| possible that "extension everything" might make this easier on the user while also making it easier for us (e.g. | ||
| extension everything defining an `window.OpenXR` property that implicitly checks the component can be created or | ||
| whatever, `DependentHandle` can probably used for this if we wanted or we could just use `window is IMyComponent` - | ||
| again these are all just ideas, this is just to demonstrate the idea of the API shape). Way earlier in 3.0's development | ||
| we were discussing the use of `IDynamicInterfaceCastable`, but the Silk.NET team were not able to implement support for | ||
| this in the Mono runtime in an acceptable timeframe and complexity level. All of these details depend on how and if we | ||
| make it possible to attach components to existing implementations without requiring modification of the original | ||
| backend. I would quite like this to be the case, but again it depends on the nature of the high-level component-based | ||
| architecture and/or the low-level component-based architecture i.e. where is the extensibility point. | ||
|
|
||
| As much as we didn't continue down the path illustrated in this document, it was certainly explored somewhat before we | ||
| decided it wasn't needed for 3.0 (engineers like to overengineer, go figure). The first exploration was essentially a | ||
| static dependency injection API i.e. a [`IHluComponentRegistry`](https://github.com/dotnet/Silk.NET/blob/56af8e1b34dc41a43de10dff45d09d25f12e8e57/sources/Core/Core/Abstractions/IHluComponentRegistry.cs) | ||
| provides components (these can be changed together for extensibility) that configures a [`Surface`](https://github.com/dotnet/Silk.NET/blob/56af8e1b34dc41a43de10dff45d09d25f12e8e57/sources/Windowing/Common/Surface.cs) | ||
| (well, a [`IHluComponentHost`](https://github.com/dotnet/Silk.NET/blob/56af8e1b34dc41a43de10dff45d09d25f12e8e57/sources/Core/Core/Abstractions/IHluComponentHost.cs) | ||
| which `Surface` implements) with the components. There was also some [source generator magic](https://github.com/dotnet/Silk.NET/blob/56af8e1b34dc41a43de10dff45d09d25f12e8e57/sources/Core/Analyzers/HluSourceGenerator.Hosts.cs) | ||
| explored to make this more JIT friendly, but that itself had some downsides e.g. one object being an implementation type | ||
| of multiple component types had two references stored in the surface. These problems aren't insurmountable but | ||
| ultimately it was determined that making an entire dependency injection API just for this was a bit silly. | ||
|
|
||
| After this attempt at implementing these concepts, another attempt was made that encompassed the low-level API desired | ||
| to reduce implementation friction. Essentially, [`ISurfaceHost`](https://github.com/dotnet/Silk.NET/blob/129d4957ce1058252723add2f6890fb53f234432/sources/Windowing/Common/Hosting/ISurfaceHost.cs) | ||
| had a bunch of lower-level APIs as `static abstract`s that essentially boiled down to "get a property, set a property" | ||
| on surface objects or surface requests. Didn't quite get round to implementing the "additional component" extensibility | ||
| concepts described but this could likely be done using type chaining and essentially changing those get/set property | ||
| methods to accept a generic "property type", but again these are just ideas - this was never realised or prototyped. | ||
| This was progressing well enough, and had some decent benefits as well like centralising all the [multi-threading logic](https://github.com/dotnet/Silk.NET/blob/129d4957ce1058252723add2f6890fb53f234432/sources/Windowing/Common/Hosting/MultiThreadedSurfaceHost%601.cs) | ||
| at the lowest level of implementation. | ||
|
|
||
| All in all, there's a lot of benefits to having a modular, component-based, and extensible approach to designing our | ||
| windowing API and this is definitely something we're keen to pursue. But for now, we determined that for the 3.0 initial | ||
| release we only needed to do this for the user-facing API (as per the goals stated in the SDP to make the API more | ||
| encouraging of write-once-run-everywhere) and as much as we want to fulfill that `GetComponent` extensibility vision to | ||
| allow extensions of our standard API set, that also isn't needed for the initial release. Nonetheless, it was key to | ||
| ensure we had enough jumping off points to ensure this can be implemented in the future, and also to implement the | ||
| lower-level, implementation-facing API to make our life easier if we did want to add more backends outside of SDL. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1,3 @@ | ||
| #include <SDL3/SDL.h> | ||
| #include <SDL3/SDL_main.h> | ||
| #include <SDL3/SDL_vulkan.h> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,2 +1,6 @@ | ||
| --remap | ||
| SDL_fabsf=float.Abs | ||
| VkSurfaceKHR=ulong | ||
| VkInstance=void* | ||
| VkPhysicalDevice=ulong | ||
| VkAllocationCallbacks=void |
Oops, something went wrong.