Skip to main content
ATK Pine Script®

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 decisionStatic vs object vs bridge
Main riskCompute leaking into render stage
Best guardrailPrepared frame, render-only visuals
Companion pagesCookbook 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.new

Static 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.