Question
Chart.js API and HTML5 Canvas: State Synchronization During Concurrent Updates
Rin Moss
0 reputation · 05 Jun 2020, 23:40 UTC
83.6K views1
Loading…
0 reputation · 05 Jun 2020, 23:40 UTC
Chart.js utilizes a reference-based system to manage datasets, where modifications to the data array are committed to the HTML5 Canvas via the update() method. To optimize performance, the library employs a requestAnimationFrame loop to batch these changes before the next render cycle.
A design uncertainty arises when the update() method is invoked while a previous animation transition is still active. Because the library must synchronize the internal state of the chart with the visual representation on the canvas, the behavior of overlapping updates can lead to unpredictable transition paths or state inconsistencies.
requestAnimationFrame cycle completes?33775 reputation · 06 Jun 2020, 01:16 UTC
Chart.js cancels any in‑progress animation when update() is called again and starts a fresh transition from the current internal values to the new target values. It does not interpolate from a mid‑animation visual state. Frequent update() calls before the previous requestAnimationFrame cycle completes force the renderer to restart repeatedly, which consumes extra CPU/GPU cycles and can cause dropped frames, though the visual result is usually a stutter rather than a crash.
chartjsupdate() sets a dirty flag and cancels any previously scheduled animation frame. The next render begins from the chart’s current internal data state, not from the intermediate visual frame.options.animation.duration = 0 disables animations entirely, making update() immediate and eliminating overlapping‑transition concerns.Calling update() faster than the browser’s requestAnimationFrame rate (typically 60 Hz) causes the render loop to restart on every call. This reduces the average frame‑time budget, increases JavaScript and GPU workload, and can lead to dropped frames or jank. The chart will still render the final state correctly, but the user may perceive stuttering. Batching data changes into a single update() per frame (or using requestAnimationFrame yourself) mitigates this.
onProgress callback that logs performance.now() and the animation progress value.setInterval to call chart.update() every 10 ms with new random data.update() should reset the progress callback to 0, confirming the previous animation was cancelled.requestAnimationFrame loop; frequent updates will show reduced frame‑time headroom and occasional gaps.options.animation.duration = 0; the progress callback should not fire, and renders should be immediate.The behavior described applies to Chart.js v3.x and later, which use a requestAnimationFrame-based renderer. Chart.js v2 used a different animation loop and may behave differently. Please confirm which major version you are using; if you are on v2, the cancellation semantics could vary and the recommendation to batch updates remains valid but the internal mechanics differ.
Use comments to ask for clarification. Post a solution as an answer.
5,940 reputation · 06 Jun 2020, 08:16 UTC
When update() is executed while an animation is running, Chart.js does not keep the previous animation’s elapsed time. Instead, the internal Animator resets its _animationStart timestamp to the current time and treats the chart’s current model data as the animation’s origin. The visual output therefore restarts from the already‑applied data values, not from the intermediate rendered frame.
Because the renderer is driven by a single requestAnimationFrame loop, multiple update() calls that occur within the same frame are collapsed into one dirty‑flag check. The extra work comes from resetting the animation timer and recomputing the animation progress, not from re‑executing the full data‑binding pipeline.