Skip to main content

CanvasLowerer

CanvasLowerer is the low-level helper that powers the higher-level canvas(...) function.

Most app authors should not start here. If your goal is "draw a custom visual surface," use canvas(...) first. Reach for CanvasLowerer only when you are building a reusable custom helper or you need direct control over the lowering closure that emits node ids into the intermediate representation.

This type exists because some custom drawing paths are easier to express as direct lowering code than as ordinary widget composition. That is an advanced escape hatch, not the default way to build app user interface.

Example​

The example below shows the shape of the type, but in most app code you would wrap this in your own helper rather than constructing it at call sites.

use std::sync::Arc;

use fission::core::ui::{CustomNode, Node};
use fission::prelude::*;

let sparkline = Node::Custom(CustomNode {
    debug_tag: "Sparkline".into(),
    lowerer: Some(Arc::new(CanvasLowerer {
        width: Some(120.0),
        height: Some(32.0),
        painter: Arc::new(|cx| {
            // Emit paint or layout nodes and return their ids.
            Vec::new()
        }),
    })),
    render_object: None,
});

Field table​

FieldTypeMeaningNotes / default behavior
widthOption<f32>Fixed width for the root box.None leaves width to parent constraints.
heightOption<f32>Fixed height for the root box.None leaves height to parent constraints.
painterArc<dyn Fn(&mut LoweringContext) -> Vec<NodeId> + Send + Sync>Closure that emits child node ids directly into the lowering context.Required. This is the advanced part of the public contract.

Behavior and escape-hatch guidance​

CanvasLowerer lowers its emitted node ids into a structural group and wraps that group in a fixed-size box. It does not add semantics, input handling, or a custom render object on its own.

That means it is best for lightweight custom drawing helpers. If the surface also needs pointer handling, text input, or custom hit testing, you are usually in CustomNode territory rather than plain CanvasLowerer territory.

Another important limit is maintainability. Direct lowering code is powerful, but it is easier to misuse than ordinary widgets. If a layout can be expressed with Container, Row, Column, or Composite, prefer those first.

canvas(...), CustomNode, and Node.