Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.0 architecture discussion #1462

Open
Madman10K opened this issue Feb 8, 2025 · 0 comments
Open

2.0 architecture discussion #1462

Madman10K opened this issue Feb 8, 2025 · 0 comments
Assignees

Comments

@Madman10K
Copy link
Member

Madman10K commented Feb 8, 2025

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:

  1. Improved OS integration
  2. Cross-platform IME support
  3. 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:

  1. 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)
  2. 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:

  1. Do we modularise the platform-dependent parts of the framework?
  2. Opinions on switching to SDL3? How should the integration be handled?
  3. Do we modularise the renderer?
@Madman10K Madman10K self-assigned this Feb 8, 2025
@Madman10K Madman10K linked a pull request Feb 8, 2025 that will close this issue
@Madman10K Madman10K removed a link to a pull request Feb 8, 2025
@Madman10K Madman10K pinned this issue Feb 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant