Skip to main content

Crate leaf_raster

Crate leaf_raster 

Source
Expand description

CPU rasterization shared by leaf frontends — the pieces of pixel rendering that are the same whatever the pixels end up painted with.

Each leaf frontend has its own paint path (terminal cells, a gpui scene, Core Text, the DOM), but several of them also need actual pixels: the terminal ships graphics-protocol images for block media and oversized headings, and a headless consumer wants a frame with no toolkit at all. What those uses share lives here, in backend-neutral units:

  • resolve_image_path — which image destinations a synchronous local loader handles, and where a relative one anchors. One policy, because two frontends disagreeing about what loads is a bug report.
  • load_image / load_svg — file bytes to a decoded image raster, vector pictures included.
  • fit_within — aspect-preserving containment in pixels, so frontends with different display units (cells, points) share the sizing policy and only round differently.
  • Rasterizer — shape and rasterize oversized heading text to an RGBA frame, with the editing UI — caret and selection — painted into the pixels. That last part is the reason this is a crate and not a helper: a terminal cannot composite cells over a graphics-protocol image, so the only way a rasterized heading stays editable is for the raster itself to carry the caret. Rasterizer::heading_hit is the reverse mapping, so a click on the raster lands on the glyph it visually hit.

Everything here is CPU-side (cosmic-text, resvg, image): the consumers are terminals reading escape sequences and headless frames, none of which are latency-bound enough to want a GPU pipeline — and the one leaf backend that is (gpui) has its own. The contract is “hand me RGBA”, so a GPU implementation could slot in behind it without callers changing.

Re-exports§

pub use image;

Structs§

EditingUi
The editing UI to paint into a raster. Offsets are bytes into the spec’s text, on char boundaries; anything out of range or misaligned is dropped rather than panicking, since a stale frontend offset is not worth refusing to draw the heading over.
HeadingSpec
Everything a heading’s geometry depends on: the text, the level (which picks the type scale), and the pixel box the raster fills. Deliberately free of colors and caret state so the same spec drives rasterization, hit-testing, and the fits check — a click must be answered by exactly the layout that was drawn.
Rasterizer
The shaping and glyph-raster state — a font database, a glyph cache, and the per-heading layout cache — shared across every raster so fonts load once per session and a heading shapes once per edit, not once per frame.

Functions§

fit_within
The pixel box an image fits into: as wide as max_w allows but never upscaled past the source’s own pixels, and as tall as that width makes it, capped at max_h (shrinking the width back to keep the aspect ratio).
load_image
Decode an image file to a DynamicImage, or None on any failure (missing, unreadable, or a format no decoder covers). SVG is rasterized with resvg (load_svg); every raster format goes through the image codec crate.
load_svg
Rasterize an SVG’s bytes to a DynamicImage, or None if it won’t parse.
resolve_image_path
Resolve an image destination to a readable local path, or None when it’s not one a synchronous loader handles: a remote URL, a data: URI, a protocol-relative //host/…, or a relative path with no document directory to anchor it. The one policy every frontend that decodes local files eagerly shares — the rest stay a placeholder.