frus_gpu/lib.rs
1//! `frus-gpu` — the GPU context and the 2D rendering engine.
2//!
3//! This crate depends on no windowing library: it is handed a
4//! [`wgpu::SurfaceTarget`] by the platform layer — `frus-shell`, say — and takes
5//! care of everything else: device, queue, pipeline, presentation.
6//!
7//! What is to be drawn is described in a [`Scene`] — coloured [`Rect`]s and the
8//! rest — which is then handed to [`Renderer::render`].
9
10#![deny(missing_docs)]
11
12// The README's example is compiled and run by `cargo test --doc`, so it cannot rot.
13#[cfg(doctest)]
14#[doc = include_str!("../README.md")]
15pub struct ReadmeDoctests;
16
17// Re-exported so the layers above can handle wgpu types without depending on `wgpu`
18// directly.
19pub use wgpu;
20
21mod batch;
22mod compositor;
23mod filter;
24mod image;
25mod offscreen;
26mod painter;
27mod path;
28mod renderer;
29mod text;
30
31/// How many draw calls a scene's rectangles, images and paths will cost.
32///
33/// The renderer draws them interleaved, in the scene's order wherever they cover one
34/// another, and batched wherever they do not — so this number says how well a screen
35/// batches. A frame of real interface should be a handful; one draw call per widget
36/// means something is breaking every batch, and that is worth noticing before a
37/// device does. Text and layers are not counted: they have passes of their own.
38pub fn draw_calls(scene: &Scene) -> usize {
39 batch::plan(scene).len()
40}
41
42// The data types — geometry, colour, scene — come from the shared foundation.
43pub use frus_core::{Color, Rect, Scene};
44pub use offscreen::{render_offscreen, OffscreenFrame};
45pub use renderer::{RenderOutcome, Renderer};