You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The framework has evolved a lot over time and with evolution comes bloat. I would really like to have this project be as slim as possible, while still having a good number of features that accommodate most use cases. However, the planned features for version 2 are expected to bloat up the framework exponentially. Specifically features like the proposed:
Improved OS integration
Cross-platform IME support
Better renderer
This discussion is a place to discuss the issue of bloat in the framework, so that we can find a point where minimal workflows are as minimal as possible, while complex applications can still work for many of our users.
The SDL3 question
We decided to commit to switching to SDL3, since IME support in GLFW will not be a thing for the foreseeable future and it is the only windowing library that works on mobile, as well as on desktop. It is a bit bloated though.
SDL3 and the framework share some similarities in the way they handle modules, so while live builds of SDL3 that you can find in most distributions will be quite bloated, since all the options will be enabled, it is not like you have a choice with the distribution builds of the framework.
My though it that, maybe we can switch to SDL3, minify and remove parts of it that we don't need, such as APIs that duplicate ones that are available in the C++ standard library, and then for the rest, we can include them in the modules system, since we have no choice over this either way.
Another solution is to implement an adapter that uses a plugin-like interface to dynamically load a backend. This way we can have an SDL and GLFW backend that can be loaded at runtime. I expect that this will be a disaster when it comes to maintaining it to be honest.
Better renderer
Currently we have a basic renderer that can only renderer dear imgui UI and nothing more. However, in the future we want to allow people to design their own custom graphics pipelines so that applications with more complex rendering needs can still be made with the framework.
We can either:
Replace the current renderer with some off-the-shelf solution, which is not satisfactory due to our need for OpenGL and WebGPU support, at least until WebGPU is supported everywhere and OpenGL can be removed(this is mainly an issue of shading languages and poor support on the web)
Keep the minimal renderer but create an adapter abstraction that allows people to add their own custom rendering engines through a unified interface
I think point 2 is the way to go, though point 1 would be great in the future when we an really only roll with Vulkan and WebGPU, or even with just WebGPU when support is universal across both desktop, mobile and web platforms.
Conclusion
What are your opinions? The current questions are:
Do we modularise the platform-dependent parts of the framework?
Opinions on switching to SDL3? How should the integration be handled?
Do we modularise the renderer?
The text was updated successfully, but these errors were encountered:
The framework has evolved a lot over time and with evolution comes bloat. I would really like to have this project be as slim as possible, while still having a good number of features that accommodate most use cases. However, the planned features for version 2 are expected to bloat up the framework exponentially. Specifically features like the proposed:
This discussion is a place to discuss the issue of bloat in the framework, so that we can find a point where minimal workflows are as minimal as possible, while complex applications can still work for many of our users.
The SDL3 question
We decided to commit to switching to SDL3, since IME support in GLFW will not be a thing for the foreseeable future and it is the only windowing library that works on mobile, as well as on desktop. It is a bit bloated though.
SDL3 and the framework share some similarities in the way they handle modules, so while live builds of SDL3 that you can find in most distributions will be quite bloated, since all the options will be enabled, it is not like you have a choice with the distribution builds of the framework.
My though it that, maybe we can switch to SDL3, minify and remove parts of it that we don't need, such as APIs that duplicate ones that are available in the C++ standard library, and then for the rest, we can include them in the modules system, since we have no choice over this either way.
Another solution is to implement an adapter that uses a plugin-like interface to dynamically load a backend. This way we can have an SDL and GLFW backend that can be loaded at runtime. I expect that this will be a disaster when it comes to maintaining it to be honest.
Better renderer
Currently we have a basic renderer that can only renderer dear imgui UI and nothing more. However, in the future we want to allow people to design their own custom graphics pipelines so that applications with more complex rendering needs can still be made with the framework.
We can either:
I think point 2 is the way to go, though point 1 would be great in the future when we an really only roll with Vulkan and WebGPU, or even with just WebGPU when support is universal across both desktop, mobile and web platforms.
Conclusion
What are your opinions? The current questions are:
The text was updated successfully, but these errors were encountered: