Type-Driven Renderer Fallback

[hecrj]

This PR sets the foundations for supporting custom renderers with the built-in APIs by implementing a composable, type-driven renderer fallback strategy and properly abstracting our geometry APIs.

In general, none of these changes break user code.

Type-Driven Renderer Fallback

The iced_renderer crate implemented a fallback strategy for iced_wgpu and iced_tiny_skia with a simple enum:

iced/renderer/src/lib.rs

Lines 37 to 41 in 3013463

	pub enum Renderer {
	TinySkia(iced_tiny_skia::Renderer),
	#[cfg(feature = "wgpu")]
	Wgpu(iced_wgpu::Renderer),
	}

The changes here abstract this pattern and make it composable:

iced/renderer/src/fallback.rs

Lines 11 to 14 in 4f5b63f

	pub enum Renderer<L, R> {
	Left(L),
	Right(R),
	}

Effectively, this means that we can build fallback strategies at the type level. For instance, here are the Renderer and Compositor types exposed by iced_renderer:

iced/renderer/src/lib.rs

Lines 25 to 54 in 4f5b63f

	#[cfg(all(feature = "wgpu", feature = "tiny-skia"))]
	mod renderer {
	pub type Renderer = crate::fallback::Renderer<
	iced_wgpu::Renderer,
	iced_tiny_skia::Renderer,
	>;
	pub type Compositor = crate::fallback::Compositor<
	iced_wgpu::window::Compositor,
	iced_tiny_skia::window::Compositor,
	>;
	}
	#[cfg(all(feature = "wgpu", not(feature = "tiny-skia")))]
	mod renderer {
	pub type Renderer = iced_wgpu::Renderer;
	pub type Compositor = iced_wgpu::window::Compositor;
	}
	#[cfg(all(not(feature = "wgpu"), feature = "tiny-skia"))]
	mod renderer {
	pub type Renderer = iced_tiny_skia::Renderer;
	pub type Compositor = iced_tiny_skia::window::Compositor;
	}
	#[cfg(not(any(feature = "wgpu", feature = "tiny-skia")))]
	mod renderer {
	pub type Renderer = ();
	pub type Compositor = ();
	}

So, let's say you build a custom renderer: MyRenderer. You can easily plug it in front of the official ones:

type MyFallbackRenderer = iced_renderer::fallback::Renderer<
    MyRenderer,
    iced_renderer::Renderer,
>;

Compositors can be composed analogously!

Custom Renderers in Program and Application

Both the Program API and the Application trait support views with any proper Renderer that has a compositor::Default implementation.

Optional Backends

These changes also allow us to make the tiny-skia backend optional behind a feature gate.

In fact, it is now possible to compile an iced application without a renderer whatsoever; which may be useful for testing and reducing compilation times. The runtime will simply create an empty window in this case.

The null (unit) renderer is only available with debug_assertions enabled, so release builds should fail by default if users disable the default features and forget to explicitly enable a renderer.

Generic geometry API

I have abstracted the geometry API and moved it from iced_renderer to iced_graphics.

Both Frame and Cache types should work with any Renderer that implements the geometry::Renderer trait. A new Cached trait has been introduced in iced_graphics that abstracts the idea of primitive caching (i.e. loading a cache).

Better Graphics Errors

I have also improved the errors reported by a Compositor when initialization fails—whether it is because of a surface error, incompatible limits, or simply a backend preference mismatch.