Support Board

- With SC timers, SC freezes or can't be interacted with if you have the chart update interval set very fast such as 10ms

The unresponsiveness with Sierra Chart custom timers (vs. OS timers) occurs because chart updates — even with OpenGL enabled — still involve significant work (study calculations, invalidation, OpenGL prep/uploads, and any remaining CPU-bound steps) that executes on or synchronizes to the main UI thread.The custom timer thread triggers updates more strictly and frequently (no OS throttling/coalescing), bombarding the UI thread with redraw requests. When per-update processing time approaches or exceeds the tight interval between triggers, the UI thread runs in long, uninterrupted bursts. This starves the Windows message pump, preventing timely processing of input, paint, and other messages — resulting in high cumulative UI delays. OS timers (message-based, e.g., WM_TIMER) are naturally throttled and coalesced by Windows, providing built-in breathing room for the message loop and better perceived responsiveness, even if updates are slightly less "faithful."This issue is noticeably worse on Windows 8+ (especially 10/11) compared to Windows 7 due to several timer-related changes Microsoft introduced for power efficiency and isolation:More aggressive timer coalescing → Starting in Windows 7/8, but refined in later versions, the OS groups nearby timer events to reduce wake-ups.
Per-process timer resolution limits → Since Windows 10 version 2004 (2020), calls to timeBeginPeriod (or equivalent multimedia/high-resolution APIs likely used in custom timers) are largely isolated to the calling process and have minimal global effect. This prevents reliable high-precision timing across the system and makes custom loops/Sleeps less consistent without extra overhead.
Stricter power throttling → On Win11 (and minimized/occluded windows), high-resolution timers are downgraded unless explicitly opted out, further restricting strict custom timer behavior.

On Windows 7, timer APIs were less restricted (more global impact from timeBeginPeriod, less coalescing/power management), allowing custom timers to achieve stricter intervals with lower risk of UI overload in GDI/OpenGL apps.WPA evidence (high UI delays + long UI thread running stacks during updates) confirms this on modern Windows. Many users report smoother feel with OS timers enabled on Win10/11.

Why SC Timers Overload/Block the Main UI Thread
Sierra Chart is a traditional Windows desktop app (likely using raw Win32/GDI for chart drawing, not modern frameworks like Direct2D fully).Chart updates require UI thread access: Actual drawing (redrawing bars, studies, volumes, lines) must happen on the main thread that owns the window/device context (HDC). GDI operations are not thread-safe without heavy locking, and Windows enforces this for stability — you can't safely draw to a window from a background thread.
How SC timers work: The dedicated thread fires timers more precisely/strictly (no OS throttling). When it triggers an update, it signals/posts the heavy work (calculations + full chart redraw) to the main UI thread.
Result: With stricter/more frequent triggers (especially at low intervals), the UI thread gets bombarded with redraw requests. Each redraw takes time (GDI is CPU-intensive and single-threaded in practice), leaving no slices for processing Windows messages (mouse, keyboard, repaint requests, etc.). → Cumulative UI delays skyrocket.
Why worse on Win10/11: Modern Windows has stricter timer resolution limits, power management, and scheduler changes that make custom high-precision timers less "free" — plus GDI performance hasn't improved (it's legacy). OS timers naturally coalesce/throttle, giving the UI thread breathing room.

This is a classic single-threaded UI bottleneck in GDI-based apps when pushing frequent updates. Your WPA data (high UI delays + long UI thread running stacks) is solid evidence. The core issue is architectural: Strict custom timers + GDI-bound redraws on single UI thread = blocking on fast triggers. OS timers mask it via throttling, which feels better in practice for most.


A few potential solutions:
1. Prioritize UI Messages During Updates. In the chart calculation/drawing code on the main UI thread, insert calls to PeekMessage + TranslateMessage + DispatchMessage (or MsgWaitForMultipleObjects) every few milliseconds or after processing chunks of data (e.g., per study or per 100 bars). This allows input, painting, and other Windows messages to be handled mid-update without completing the full redraw/calculation first. It keeps updates frequent and faithful but prevents long blocks that cause UI delays/freezes. Many legacy Win32 apps use this technique successfully.

2. Break full chart redraws into smaller invalidations: Calculate all studies fully (fast, often parallelizable), but invalidate and repaint only changed regions (e.g., new bar, modified studies) using InvalidateRect or partial updates.
Combine with double-buffering (already partial in SC) to avoid flicker. This reduces time per update on the UI thread without skipping data, maintaining speed while giving message pump breathing room. This allows input/repaints to interleave, reducing delays without throttling timers.

3. Offload More Work from the UI Thread. Move non-UI calculations (e.g., study computations on historical data) to background threads or worker pools — many modern studies already support this, but core chart updates could expand it.
Cache more aggressively: Avoid recalculating unchanged bars/studies on every tick.

4. Offload Non-UI Calculations More Aggressively
Move additional study/graphical object calculations to background threads or worker pools (some studies already support this). Post only minimal data (e.g., updated values) to the UI thread for drawing.
Core bar data processing could be parallelized further. This shortens UI thread work per update without dropping any ticks.

5. Hybrid Timer Approach
Use custom timers for strict triggering but post update work as lower-priority messages (e.g., via PostMessage with custom WM_USER) or queue to a secondary thread that signals back lightly. Combine with message pumping to ensure UI events take precedence.
Avoids OS throttling while preventing high-priority blocking.

On Windows 7, timer APIs were less restricted (more global impact from timeBeginPeriod, less coalescing/power management), allowing custom timers to achieve stricter intervals with lower risk of UI overload in GDI/OpenGL apps.WPA evidence (high UI delays + long UI thread running stacks during updates) confirms this on modern Windows. Many users report smoother feel with OS timers enabled on Win10/11.