Chart: at the deepest zoom the newest ticks run under the order book — the live edge follows the PC clock, ticks carry the core's time

[Alena-Selezneva]

Report (@MrsPickless, MoonTerminal chat, 2026-09-25, Windows, Bybit core): «тики залазят в стакан на макс приближении» — at maximum zoom the ticks crawl into the order book. Said right after confirming the zoom freeze (#716) is gone.

What the code does

• Tick crosses are baked into their own texture and blitted with dst = view.bounds, i.e. the plot only (chartdx/combo.rs blit_combo; Metal draw_cached_combo likewise). On DX11 the order book is composited after the combo inside the base cache, opaque (backend.rs render_base_d3d → orderbook.render, blend None). So a cross is never painted over the book: a tick whose X lands past the plot's right edge disappears under it. That is what "ticks go into the book" looks like on screen.
• The live edge follows the local PC clock: advance_camera(now_unix_ms()) puts now at 1 - right_margin_frac of the plot (chartdx/mod.rs, render_state.rs).
• Tick X comes from the core's trade time (TradeHistoryRow::unix_millis() → Tick.time_ms, moon-core/src/market/source/mod.rs rows_to_ticks). Nothing corrects a seconds-level gap between the two clocks: session::clock_skew corrects order times only and has a 45-minute deadband; core_time_offset is for report time zones (15-minute buckets).
• The room for "future" ticks is a fixed 10% of the window (DEFAULT_RIGHT_MARGIN_FRAC = 0.10, no setting). Plain wheel stops at 30 s → 3 s of room; super zoom (3 s window) → 0.3 s. Plain wheel keeps Live (view.rs zoom: was_follow && XZoom::Plain), so this is the followed live chart, not a paused one.

So if tick times run ahead of the PC clock by more than that margin, the newest ticks sit to the right of the live edge and vanish under the book — and only at deep zoom: at a 5-minute window the same gap is 30 s of room and invisible. That matches "only at max zoom".

Not confirmed that this is the reporter's case: no screenshot, the PC-vs-core clock gap on the reporter's machine is unknown. Asked for a screenshot at max zoom and a check of the PC clock (time.is). If the reporter's clock is in sync and ticks still overlap, the cause is elsewhere and this issue needs rework.

Possible directions (team's call):

• estimate the per-core (or per-market) offset between the newest tick times and the local clock on arrival and shift the live edge by it (the terminal already estimates core clock offsets for other purposes, just not at this resolution);
• or never let the live edge sit left of the newest tick: anchor at max(now, last_tick_time).

Check: set the PC clock a few seconds behind, open a busy coin, wheel-zoom to the floor with Live on — the newest ticks should stay left of the order book.

[Alena-Selezneva]

Root cause confirmed by the reporter. @MrsPickless (MoonTerminal chat, 2026-09-25 17:54): «синхронизация времени решила проблему» — after syncing the PC clock, the newest ticks no longer run under the order book at max zoom. So the "Not confirmed" part of the description is resolved: it was the PC clock lagging behind the core's trade times, exactly the mechanism described above.

Keeping the issue open: the user fixed it on their side, but the terminal still depends on the PC clock being within 3 s (plain wheel floor) / 0.3 s (super zoom) of the core's trade times. A PC that drifts a little makes the symptom come back, and the user has no way to tell from the chart that the clock is the cause. The directions in the description (shift the live edge by the observed tick-vs-local offset, or anchor at max(now, last_tick_time)) still apply.