blockworx_canvas2d/lib.rs
1//! The web backend: the only crate that knows both the paint vocabulary and
2//! the DOM.
3//!
4//! Everything a drawing is made *of* — the [`Renderer`](blockworx_paint::Renderer)
5//! and [`Canvas`](blockworx_paint::Canvas) traits, the palette, the theme, the
6//! ground and its grid rule, the recorder that turns a frame into
7//! [`DrawOp`](blockworx_paint::DrawOp)s — lives in [`blockworx_paint`] over the
8//! coordinates in [`blockworx_geom`], and the text engine that lays a run out
9//! lives in [`blockworx_text`]. Here those become `Canvas2D` calls:
10//! [`replay()`] draws a display list onto a `CanvasRenderingContext2d`,
11//! [`paint_ground()`] rules what lies under it, [`Glyphs`] is the text engine
12//! the kernel is called with *and* the ink its glyphs are filled from,
13//! [`Images`] holds the artwork a hand-off delivered, [`input`] turns DOM
14//! events into the kernel's own, and [`download`]/[`clipboard_write`] are the
15//! two hand-offs a backend can perform without a shell around it.
16//!
17//! The dependency goes one way, as it does for the egui backend. This crate
18//! names the document (for an [`Asset`](blockworx_doc::block_model::Asset)),
19//! the geometry, the paint vocabulary and the text engine, and nothing above
20//! them: a backend knows how to paint, not what a block is. It names no
21//! component framework either — the Dioxus shell above it is components,
22//! signals and effects over what is here.
23
24pub mod fit;
25pub mod glyphs;
26pub mod ground;
27pub mod handoff;
28pub mod images;
29pub mod input;
30pub mod replay;
31
32mod color;
33mod cursor;
34
35pub use color::css_color;
36pub use cursor::css_cursor;
37pub use fit::{DevicePixelRatio, fit};
38pub use glyphs::Glyphs;
39pub use ground::paint_ground;
40pub use handoff::{clipboard_write, download};
41pub use images::Images;
42pub use input::{Reader, Sample};
43pub use replay::{Repaint, replay};