Visual Authoring Overview
How to pick the right visual layer and keep build_visuals render-only — static declarations, ctx object namespaces, and the ATK bridge.
How to Pick the Right Visual Layer and Keep It Stage-Correct#
This handbook explains the mental model behind ATK PyneScript visuals: when to stay with static declarations,
when to move into object namespaces, when to use the ATK bridge, and how to keep build_visuals(...)
render-only instead of turning it into a second compute stage.
| First decision | Static vs object vs bridge |
|---|---|
| Main risk | Compute leaking into render stage |
| Best guardrail | Prepared frame, render-only visuals |
| Companion pages | Cookbook plus copybook |
Choose a Visual Layer Before Writing Code#
Do you have one value or marker per row?
|- Yes -> use static declarations: plot, hline, plotshape, plotchar, plotarrow, fill, linefill.new
|- No -> use an object-like visual path
|- Simple chart object? -> ctx.line, ctx.label, ctx.box, ctx.polyline, ctx.table
|- ATK-native grouped or composite renderer? -> ctx.atk.plot_line, ctx.atk.fill_between, ctx.atk.table, ctx.atk.rectangles, ctx.atk.volume_profile
Already drawing your lines with ctx.atk.plot_line?
|- Yes -> ctx.atk.fill_between
|- No -> fill or linefill.newStatic declarations#
Best when the visual can be described by columns already present in the frame. This is the cleanest path for most indicators.
ctx object namespaces#
Best when the visual is an object with coordinates, text, geometry, or mutating endpoints rather than a simple row-aligned series.
ATK bridge#
Best when the visual is richer than one object or when the repo already exposes a higher-level helper such as profiles, rectangle batches, tables, or bridge line fills.