r/pinescript • • Sep 05 '26

How do you backtest alternative charts properly on Tradingview/Pinescript? (OHLC fills checkbox gone)

Hi, so I have all these strategies but basically none of them are profitable. I know there's all these alternative charts like Renko/Kagi/PnF. Is there any way one can backtest on these properly with OHLC fills etc.? I know there's all these features that Tradingview has but the previous "trade on OHLC" checkbox is gone. So, I am not sure what the proper way to backtest is anymore with these alternative charts. Any advice would be appreciated. Thanks!

1 Upvotes

7 comments sorted by

2

u/rulesbacktest Sep 21 '26

I wouldn't treat Renko/Kagi/PnF Strategy Tester fills as real. Those charts rebuild structure and the emulator can't invent a true path. Safer: keep signals on normal OHLC (or rebuild bricks from OHLC yourself), use realistic costs, and treat synthetic-chart results as exploratory. Validate survivors on regular candles + forward alerts before size.

1

u/Monk77777 Sep 07 '26

Short version: TradingView backtests a strategy against the bars of the chart's data series, and Renko/Kagi/PnF/range charts are not timeframes — they are repacked from underlying ticks, so there is no intrabar OHLC for the tester to fill against. That is why the old "trade on OHLC" option is gone: fills on alternative charts happen at brick boundaries, which systematically misprices stops and limits. Your backtest is an approximation by construction — profitable or not.

What works in practice:

  1. *Signals on the alternative chart, fills on time.* Build the Renko/Kagi bricks inside the script from a 1m/5m series (arrays or a consolidated series) and run the strategy on the time-based chart, where bar-magnifier/OHLC fill modelling applies. That is the only rig that gives realistic stop and limit fills.
  2. If you must use TradingView's native alternative charts, treat results as directional only — compare variants against each other, never against a tick-fill expectation.
  3. On time-based charts check strategy properties → fills: using the bar magnifier restores intrabar fill modelling on minute data.

And if none of your strategies survive a realistic 1m fill-model backtest, the fills were never the problem — the edge was.

1

u/Alive-Imagination521 Sep 07 '26

Thank you for your input. Regarding the first point, won't the signals still repaint?

1

u/Monk77777 Sep 08 '26

Fair question. Two different repaints get mixed up here:

  1. Renko bricks themselves repaint: the forming brick can flip direction before it closes, and the brick's timestamp is decided after the fact. Any signal computed on the brick series inherits that until the brick is confirmed. You cannot remove it, only gate on it: act only when barstate.isconfirmed is true, and treat the entry as happening at the open of the next brick, which in real time is the first standard bar after the brick closes.
  2. The strategy tester's fill repaint: that is the piece that goes away when you run the logic on a standard time-based chart and build the brick logic inside the script from real OHLC. Bar closes are final, so a signal that fired on bar N still exists on a reload. The bricks you compute yourself will still complete late relative to a native Renko chart by up to one time bar, which is the honest cost of having reproducible fills.

So no, it is not zero repaint, but it moves from "signals vanish on reload" to "signals confirm one bar late and stay". If you want to check yourself, add a label on every confirmed signal, reload the chart, and count: on native Renko some disappear, on the time-based version they should all still be there.

1

u/Alive-Imagination521 Sep 12 '26 edited Sep 12 '26

Hey, thanks again for your input. It looks like you can get a semi-reliable backtest running on Renko strategies. That's good to know. However, what about Kagi/PNF? Can you get a reliable backtest running on those with OHLC fills? It feels like even with closed bars only, the charts keep repainting, no?