Browser Performance

window.requestAnimationFrame() in the Chart

CIQ.ChartEngine.useAnimation=true;

CIQ.ChartEngine.useAnimation is enabled by default.

We now have all browsers using requestAnimationFrame (RAF). RAF automatically throttles to a level that the browser can handle. The maximum request rate depends on the browser implementation, but the most common method is to throttle to the refresh rate of the monitor. So if you are set to 60hz, you will get 60 frames per second (fps) as a max.

A chart will dip below the maximum frame rate when it starts to do more work than the cpu or gpu can process in a given animation frame. You would have to load up a chart pretty significantly to tax the gpu on a modern desktop or laptop, but on older devices and of course on mobile devices, you can get there pretty quickly. For instance, on the older phones in our office (Nexus and Note4) RAF can't get above 30fps, even when doing nothing. The gpu is simply too weak.

Click here for more information about window.requestAnimatinFrame().

Prevent UI freezing on very intense data loops

JavaScript in a browser is a single-threaded environment, so there aren't many options. HTML5 Web Workers are the closest thing to threads, but they can't share anything and talk to the parent page with string messages (objects are permitted, but will be serialized internally by postMessage, according to the same algorithm used by JSON.stringify).

The best way is to use setTimeout with a value of 0 (which means "schedule this to run as soon as the interpreter is idle"). That way, running expensive code as part of an event handler won't block any UI updates also happening in that event handler.

If the code is costly enough that it will still freeze up the UI, presumably you're doing a lot of looping, and that means you can break up the loop into "batches" of X items, such that each batch schedules the next batch when it's done. That way, the work will occasionally stop to defer to the UI, and you won't get the annoying "a script is taking a long time" notice.

This could happen if you are rapidly streaming data from a feed that had backed up and created a large queue of messages.

Here is some sample code illustrating the use of setTimeout:

function loadData(last,volume) {
    stxx.updateChartData(
            {
                Last: last,
                Volume: volume
            }
    );
}
       
// call this inside your data update loop
setTimeout(loadData(last,volume),0);

Next Steps: