Skip to content
GetProfitable
Search

Repainting, explained and avoided

Lesson 15 · about 12 min

"Repainting" is the word for a script whose past looks different from its present: a signal that was there at 10:03 and gone by 10:05, a higher-timeframe line that shifts once the day ends, an arrow that appears five bars after the bar it points at. Every one of these has a specific cause in the execution model, and every one has a fix or an honest label. This lesson names them so you can recognise which one you are looking at.

Cause 1: the live bar is not finished

On historical bars the script sees final values. On the live bar it re-runs on every tick, and close is whatever the last trade was. A condition like ta.crossover(close, ema) can be true at one tick and false at the next. The shape flickers, the alert fires, then the bar closes below the EMA and history shows no signal at all.

The fix is to require confirmation:

//@version=6
indicator("Repaint-safe signal", overlay=true)
rsi = ta.rsi(close, 14)
raw = ta.crossover(rsi, 30)
confirmed = raw and barstate.isconfirmed
plotshape(raw, "Raw", style=shape.circle, location=location.belowbar, color=color.gray, size=size.tiny)
plotshape(confirmed, "Confirmed", style=shape.triangleup, location=location.belowbar, color=color.green, size=size.small)
alertcondition(raw, "RSI cross 30", "RSI crossed above 30 on {{ticker}}")

On history both shapes coincide, because historical bars are always confirmed. Live, the gray circle can appear and vanish; the green triangle appears only at the close and stays. For alerts, the dialog setting "Once per bar close" does the same job for alertcondition(), and alert.freq_once_per_bar_close does it for alert(). Choose one of those unless you have a specific reason to want intrabar notifications, and if you do, understand that history will not show them.

The cost is latency: you learn about the cross when the bar ends, not when it happens. On a daily chart that is the close; on a 5-minute chart it is at most five minutes. That is the price of a signal you can backtest.

Cause 2: higher-timeframe lookahead

Module 3 covered this. request.security() with lookahead_on and no offset shows historical bars a value from the future; with lookahead_off the live bar shows a developing value that history never showed. Both make a backtest untrustworthy. The expr[1] plus lookahead_on idiom returns only completed higher-timeframe values and is the fix.

Cause 3: lag drawn in the past

ta.pivothigh(high, 5, 5) confirms a pivot five bars after it happened, and a label placed at bar_index - 5 sits on the pivot bar. Scrolling history, every pivot label looks like it was there in time to trade. It was not; it appeared five bars later. This is not the script lying about values, it is the drawing placing a late fact at an early location. The same applies to zigzags, some divergence detectors, and any offset less than zero.

The honest version either draws at the confirmation bar, or draws at the pivot bar and says "confirmed n bars later" in the description. If you use such a signal in a strategy, enter on the confirmation bar, never on the pivot bar.

Cause 4: varip and intrabar state

varip keeps values across ticks within the live bar, which lets a script count ticks or accumulate up-volume in real time. Historical bars have one tick each, so anything built on varip cannot be reproduced on history. Scripts that use it are live-only tools; do not backtest them.

Cause 5: strategy settings

calc_on_every_tick=true makes a strategy evaluate on every live tick, so orders can be submitted from unconfirmed bars while the backtest only ever saw confirmed bars. calc_on_order_fills=true recalculates after each fill, which can chain entries within a bar in ways history handles differently. Leave both at their defaults unless you are deliberately modelling intrabar execution and understand the mismatch.

Repainting that is not a problem

Some things change and should. A moving average's last point moves with the live bar. A VWAP updates all session. A developing daily candle changes shape. None of those are dishonest; the values are current and history shows the final versions. "Repainting" is only a problem when a signal, something you act on, is shown on history where it could not have been acted on.

Non-repainting does not mean profitable, either. A confirmed, lookahead-free signal can still have zero edge. It only means the backtest is at least measuring the same thing you would trade.

Key idea: A signal repaints when history shows something that was not knowable at that moment. Guard live signals with barstate.isconfirmed or once-per-bar-close alerts, use [1] with lookahead_on for higher timeframes, and enter on the bar where lagging signals confirm.

A checklist before trusting a signal

  1. Does it use request.security? If so, is the expression offset by [1]?
  2. Does the alert fire once per bar close?
  3. Are any shapes or labels placed with a negative offset or at a past bar_index?
  4. Does the script use varip, calc_on_every_tick or calc_on_order_fills?
  5. Have you watched it on a live bar for an hour and compared with the same bars afterwards?

Try it: Take any signal script you have written and add a plotshape with barstate.isconfirmed next to the raw one. Watch a live 1-minute chart for fifteen minutes and count how many gray circles appear and then vanish. Then set an alert on the raw condition with "Once per bar" and another with "Once per bar close", and compare the notifications.

Recap

  • Live bars recalculate every tick; guard signals with barstate.isconfirmed and use once-per-bar-close alert frequencies.
  • Higher-timeframe data needs the [1] plus lookahead_on idiom to match history and real time.
  • Pivots and other lagging signals confirm late; draw or act on the confirmation bar.
  • varip, calc_on_every_tick and calc_on_order_fills create live behaviour that history cannot reproduce.
  • Changing current values are fine; signals shown where they were not knowable are not, and a clean signal still needs an edge.

See it drawn

Original diagrams for the ideas on this page. Illustrative, not real market data.

One daily candle broken into four six-hour candlesA tall daily candle on the left and the four six-hour candles that make it up on the right, with dashed lines linking the day's open to the first candle and the day's close to the last.ONE DAILY CANDLEFOUR 6-HOUR CANDLEScloseopenhighlow=00:0006:0012:0018:00one dayThe same trading, summed up in one bar or spelled out in four.
How timeframes stack up. A daily candle is not different data, only coarser data: it opens where the first six-hour candle opened, closes where the last one closed, and its wicks reach the highest and lowest prices any of the four touched.
A fast and a slow moving average crossingA jagged price line with two smoother average lines through it; the fast average dips below the slow one on the left and cuts back above it in the middle, where a circle marks the crossing.pricefast averageslow averagefast crosses belowfast crosses abovethe slow averageAverages of recent closes; the fast one reacts sooner than the slow one.
Fast and slow moving averages crossing. A moving average is the average of the last few closing prices, redrawn each period. An average over fewer periods turns sooner than one over many, so the two lines cross whenever the recent pace of the market changes.
The spread of outcomes behind an expectancyA histogram of forty trades: a tall block of small losses on the left, a low spread of larger wins on the right, and a line marking the average outcome.NUMBER OF TRADES051024 LOSSES, AVG −$20016 WINS, AVG +$600EXPECTANCY +$120−$400−$200$0+$200+$400+$600+$800PROFIT OR LOSS PER TRADEexpectancy = (40% × $600) − (60% × $200) = +$120 per trade
Expectancy: the average trade. Forty trades sorted by outcome: 24 small losses and 16 larger wins. Weighting each side by how often it happens gives the average result per trade, marked here by the dashed line at +$120.

Finished this module? Take the module quiz.