'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 |