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

Support choosing a Renderer at runtime #1199

Closed
hecrj opened this issue Jan 18, 2022 · 0 comments · Fixed by #1830
Closed

Support choosing a Renderer at runtime #1199

hecrj opened this issue Jan 18, 2022 · 0 comments · Fixed by #1830

Comments

@hecrj
Copy link
Member

hecrj commented Jan 18, 2022

Currently, iced forces users to pick a Renderer implementation at compilation time via feature flags (iced_wgpu, iced_glow, etc.).

However, each renderer has its tradeoffs and GUI applications may want to ship different renderers in the same binary to improve compatibility, performance, and correctness.

iced should allow users to enable renderers via feature flags in a non-exclusive way. Then, users could set the priority for each renderer in the Settings of an Application. For instance:

Application::run(Settings {
    renderers: [Renderer::Wgpu, Renderer::Glow],
    ..Settings::default()
})

I believe that in order to achieve this we will need to create a couple of new subcrates:

  • iced_renderer on top of iced_wgpu and iced_glow and implementing a Renderer that picks its internal backend at runtime.
  • iced_shell on top of iced_winit andiced_glutin implementing a generic shell that spawns and manages windows for the chosen renderer.

Once we have these, it should be relatively straightforward to change the root crate and extend the Settings struct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant