'Using library that calls requestAnimationFrame in Angular

I'm using a library (https://echarts.apache.org/v4/en/api.html#echarts) inside Angular that internally calls requestAnimationFrame. When I have chart in idle state - I see stable 4-5% CPU usage and RAM keeps growing (leading to GC) and I see these requestAnimationFrame scheduled functions being called, which are hijacked by Angular.

I think I could reduce CPU usage if library could call native requestAnimationFrame, but is there any way to do it without changing the library? Even if I can do initial call inside this.ngZone.runOutsideAngular - requestAnimationFrame callback calls requestAnimationFrame and this time it's not inside runOutsideAngular, so we're back to Angular.

So the questions are 1) can I use native requestAnimationFrame there and 2) will I win some perf this way?



Solution 1:[1]

I just stumbled across this exact issue. I'm working with ECharts 5, so perhaps it's different from 4, but I had the same expectations about runOutsideAngular not working with requestAnimationFrame, but this GitHub discussion convinced me to try it, and it worked. I'm not using ngx-echarts, but it's the same issue, and the same solution.

I haven't gotten much time to actually dig in and figure out exactly what the minimum is, but I just went crazy and wrapped every call to ECharts with NgZone.runOutsideAngular: the initial init one, all event subscriptions, every and every call to setOptions and resize.

After doing that, the Angular Dev Tools Profiler no longer showed hundreds of requestAnimationFrame-sourced change detections. So I'm quite convinced that fixed it.

As I say, I'm not sure if ECharts 5 is the key (or that I'm using the SVG renderer in ECharts), but I'd definitely give that a try if you haven't yet.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Matthew Haugen