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
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:
Currently,
iced
forces users to pick aRenderer
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 theSettings
of anApplication
. For instance:I believe that in order to achieve this we will need to create a couple of new subcrates:
iced_renderer
on top oficed_wgpu
andiced_glow
and implementing aRenderer
that picks its internal backend at runtime.iced_shell
on top oficed_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.The text was updated successfully, but these errors were encountered: