The implementation here is a proof of concept, but doesn't quite fit with how the fallback compositor is designed. So it's not suitable to be merged as is.

Anyway: the issue here is that if the wgpu renderer successfully initializes, but uses a software renderer like llvmpipe on Linux (for instance on a VM with no accelerated graphics, or for some reason I'm seeing wgpu fail to initialize an accelerated EGL context on the Pinebook Pro), this will be used for renderering, even though the tiny_skia renderer should perform better.

So we probably want to fallback to tiny Skia if wgpu selects a wgpu::Adapter with DeviceType::Cpu.

Questions with this:

• It should probably be possible to force use of the wgpu backend, even if it ends up using a cpu renderer, using ICED_BACKEND?
  • Maybe this logic to not use wgpu if it produces a CPU renderer should only apply if ICED_BACKEND is not set?
  • Or perhaps it should still apply, but fallback::Compositor should recognize this is a non-preferred CPU renderer, and continue iterating and see if there is a better backend to use
• fallback::Compositor is designed to be very generic. We should probably handle the possibility that the primary Compositor backend produces a software renderer, but the secondary backend fails.
• For those two things, would it make sense to add an is_cpu() method to the graphics::Compositor trait so fallback::Compositor can prioritize this way? Or some other indication of preference.