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