[Violation] 'requestAnimationFrame' handler took Xms in timer.js

[mversluys]

I'm utilizing d3js in an electron.js application and when the system is left unattended for a day or so, when it wakes up the application isn't responsive. Initially I thought it was related to the system going to sleep, but in my most recent test the system never went to sleep, it was just locked for a couple of days.

Eventually it becomes responsive again, the application is fine, and the chrome console reports
[Violation] 'requestAnimationFrame' handler took Xms in timer.js:67

In my most recent test it was 24046ms (24s) after leaving it locked for about 60 hours.

The location that it reports is in the wake() function on line 67 of timer.js.

Based looking at what wake() does, the implication is that there's a very large number of time tasks being iterated over when the application is being woken up or it's doing some other operation to "catch up". I'm going to try to add some more instrumentation to see more precisely where the time is going, curious if this is a known issue and if there's a workaround.

[SaschaLeh]

@mversluys did you find a workaround for the issue? It seems that we encountered the same issue in our project. After long debugging I ended up at the same files.

We also have a dashboard with several D3 Charts. Each chart gets fed via a WebSocket connection. When you change tabs for 4-5 minutes you will get a freeze for 30 - 60 seconds. The longer the tab is inactive, the longer the freeze takes.

[mversluys]

I haven't found a workaround yet. My next move was to try adding some logging to verify my hypothesis.