Add WGPU_BACKEND environment variable

[Cupnfish]

Fixes #787. Related to #207.
Inspired by Bevy’s source code.
You can explicitly specify the render backend when you run your app by setting the WGPU_BACKEND environment variable. If this environment variable does not exist, the default is the wgpu::BackendBit::PRIMARY.

If you use cargo with version 1.52 or later, you can easily set your environment variables.

First create a folder called .cargo in your project directory, then create a config.toml file in the .cargo folder:
before:

.
├── Cargo.lock
├── Cargo.toml
└── src
    └── main.rs

after:

.
├── Cargo.lock
├── .cargo
│   └── config.toml
├── Cargo.toml
└── src
    └── main.rs

.cargo/config.toml:

[env]
WGPU_BACKEND = "dx12"

Specific configuration method can be seen here.

[Cupnfish]

Running after setting through .cargo/config.toml requires cargo run -Zconfigurable-env instead of cargo run.If you set the environment variable on your system, rather than through .cargo/config.toml, you do not need to add this -Zconfigurable-env.

[hecrj]

Is an environment variable the proper way to introduce this kind of configuration? Should it always be a user choice?

[Cupnfish]

I think the ideal situation is the compiled iced program, you can choose their own internal rendering back-end, just need to restart the program can switch back-end, but it seems difficult to achieve. Environment variables make it easy for developers to specify which backend should be used for the compiled version, but users have no choice.

[dhardy]

Is an environment variable the proper way to introduce this kind of configuration? Should it always be a user choice?

I would say yes: sometimes because of a driver issue with some backend, sometimes just for testing.

At any rate I did something similar (though WGPU_BACKEND is a better env var name): https://github.com/kas-gui/kas/blob/master/kas-wgpu/src/options.rs#L50

[derezzedex]

Should it always be a user choice?

If by user you mean the end-user of an iced application, I don't think so. I think it should be up to the developer using iced to decide if they want support X backend.
I'd include a new field under iced::Settings which exposes an enum to currently supported Backends.

In doing so, we would allow developers to create a "backend fallback strategy",
where they can request for some backend and fallback if that backend is not supported
(e.g. using Application::runs Error::GraphicsAdapterNotFound to try using other Backend).

This would allow any developer to add a WGPU_BACKEND flag if they wish to do so (we could also add to iceds example if convinient)
and would help me on my current work to add support for previous OpenGl versions on the glow backend 😉 (which would fallback on runtime).
This is certainly requires more work, but in my opinion, would make backend selection more flexible.

pub enum GlowBackend{
    Modern,
    Compatibility,
    Legacy,
}

pub enum Backend{
    #[cfg(feature="wgpu")]
    Wgpu(wgpu::BackendBit),
    #[cfg(feature="glow")]
    Glow(GlowBackend)
}

Maybe we should move this to a discussion?

[hecrj]

I have changed the implementation details a bit, but the result for users should be the same.

Specifically, I have introduced a from_env method to the Settings of our renderers, instead of coupling the environment variable to Compositor::new.

Thanks! I think we can merge this.

[hecrj]

@derezzedex Backend fallback is in the roadmap, but I believe it solves a different kind of use case.