heartbeats
heartbeats copied to clipboard
slows down if you switch to another browser tab
Just curious if this is expected behavior. I stumbled upon it with a very basic example in an Aurelia pp when I simply clicked over to another Chrome browser tab on my Macbook. I was running a heart that beat every 250 ms and an event that ran every beat. In the event's code there was a boolean reversal and a console statement printing out the count and the current value of the boolean. It seemed to accurately run 4 times per second until I clicked over to another browser tab to look at this GitHub repo, and then I noticed my Chrome console was spitting out another console statement about every second, meaning it had slowed down to a quarter of the pace. I can imagine this is to be expected if Chrome just doesn't run that tab as much when it's not active, but I wanted to see if you thought this should happen.
@stephenhuey this is worthwhile to keep as a trackable issue. It is not expected behavior, obviously but I'm not sure exactly what the best take on resolution should be.
Have a look at this StackOverflow question about the root issue.
In our case I think the only thing we could do would be to spawn a web worker.
Aurelia could spawn a web worker and instantiate heartbeats there, or heartbeats could bake that in.
Not sure if it should be a responsibility of heartbeats or the program using it. Open to hearing opinions!
Ah, interesting. I played around with setInterval and see how it's the same with that as well. This isn't something I absolutely need right now, but I did just try to play around with getting it to work with a web worker. You can only pass certain types of objects to the postMessage method of a web worker, so I couldn't pass moment.js to it. The constructor for a web worker wants a JS file (you can't pass it a class or other object), so in that JS file I'm not sure how to import/require heartbeats or momentjs or anything like that since the way the web worker loads that file it's outside of Aurelia land and it seems I can only give it URLs to load more files. I know this isn't a problem specific to heartbeats, but I am curious how this should work. Sometimes when I use heartbeats I really don't care about timing accuracy, but if I did, I'm not sure how to get the web worker to load heartbeats. Do you know? If it's not very intuitive for the end user, perhaps it would make sense for heartbeats to have an option to run in a web worker, and you simply pass that option to a createHeart or createEvent function.
@stephenhuey I'll see if there's a reasonable possible solution this evening. Might take some time to get this implemented though!
@stephenhuey Looks like this may be possible, but it would require at least a couple things:
- Splitting the method of timing depending on environment: having some isomorphic components, but using webworkers in the browser. This would probably require adding an extra entrypoint to the package.json (ie. a
"browser"
field) and structuring the code to respect environment. - Actually writing and testing webworker timers (
setInterval
) to work in the browser. This involves breaking down webworkers when hearts are no longer beating, etc. Lots of technical edge cases that would need to be considered. - Writing tests for a real or simulated browser environment, or at least simulate the webworker -> main thread messaging.
I'm going to keep this open as I think it is a worthwhile thing to eventually come around to or dig deeper into, but it's a chunk of work I might not be able to get to for a while.
Totally understandable!