Re:Chrome will aggressively throttle background tabs
by artursapek on Tuesday January 24, 2017 @02:09PM
(#13474459)
But if you do this, isn't it possible that you'll queue up tons of re-renders that all go off when the tab comes back in focus? I'm thinking of React for example, where you might re-render a component with updated props several times per second. In my case, I've settled on just not re-rendering at all, and then doing so once with the latest props when "visibility" fires again with document.hidden === true.
[ Parent
| on HN ]
Re:Chrome will aggressively throttle background tabs
by STRML on Tuesday January 24, 2017 @02:47PM
(#13474803)
This is where batched rendering really comes in handy. For example:
https://gist.github.com/STRML/cc368c46c2d7de8679196e69ddbcae...
The key is, even in your case (with price alerts), you'll still want to tick occasionally, thus the `FORCE_TICK_INTERVAL`.
React's own batching is smart enough to merge the work. For example, before the next tick, one component calls setState() 20 times, another calls it once. Only one rerender will actually be done.
Some more discussion on rAF batching here: https://github.com/petehunt/react-raf-batching/issues/8
Re:Chrome will aggressively throttle background tabs
by SapphireSun on Tuesday January 24, 2017 @03:08PM
(#13474986)
I'm not a graphics expert, but one really easy change to make is a pattern like this:
_needsrender = false;
function render () {
_needsrender = true;
}
requestAnimationFrame(function hardrender () {
if (_needsrender) {
.... do stuff ....
_needsrender = false;
}
requestAnimationFrame(hardrender);
});
Re:Chrome will aggressively throttle background tabs
by just2n on Tuesday January 24, 2017 @02:49PM
(#13474819)
Why not limit it to a single render queued with the latest information?
I see this done via debouncing for render operations that happen on repeated events, for instance typing (send query to server, then show matching results in a render of some list).
Re:Chrome will aggressively throttle background tabs
by Kiro on Wednesday January 25, 2017 @10:28AM
(#13482130)
Yes, this happens in my browser games. When the user clicks back to the tab it fires off all the frames that have been queued up, moving everything in hyperspeed until it's up to date. I don't really mind though, since it's multiplayer it's supposed to catch up but doesn't need to render when unfocused.