Render loop in live examples in the documentation wastes energy
See original GitHub issueMany pages in the documentation contain live examples, which are really useful initially to understand the concepts behind the described classes.
But even after I’m finished playing with them, they continue to continuously re-render (sometimes even the same still frame) and waste energy by hogging the CPU and GPU. This is especially noticeable on a laptop, where the used energy raises the temperature and reduces battery life. Even more critical, this will sooner or later trigger CPU throttling, which interferes with estimating the performance of my own code while leaving the documentation open in another browser window.
The simplest solution would be to add a button to pause the render loop of the examples.
A more elegant solution would be to render on-demand, when the user changes one of the controls. The render loop would only run free when one of the controls explicitly enabled an animation. This is less likely to be copy-paste-able into every example, like a generic pause button.
My ideal solution would have the documentation available as documents, as opposed to being locked up in a SPA. The problem would then not even arise unless I enable JavaScript for the threejs.org domain. Unfortunately, I don’t know how much effort this is. This could be as trivial as replacing the #
in the URLs with /
. Or it could require changing the entire concept of how the documentation is presented.
Issue Analytics
- State:
- Created 3 years ago
- Comments:12 (6 by maintainers)
Top GitHub Comments
A quick test in Firefox (79.0 64-bit) seems to indicate that the scene being not visible in the viewport had no impact on this. The Performance tab of Dev Tools showed
requestAnimationFrame
being called while it was both on and off screen.In contrast, the same test in Chrome (84.0.4147.135 64-bit) showed no frames being rendered while the iframe was out of the viewport (performance test tab is not the same between these two, but enough to see what was going on under the hood).
In short, browser behavior is a factor here. I didn’t check to see if Firefox has an option to change this behavior.
Sorry, but I don’t think we should complicate things and instead keep the documentation simple. Additional controls that allow to start/stop the animation seem over-engineering to me. The fact that animated demos are more expensive to render than on-demand rendering is an acceptable tradeoff.
Support the documentation with disabled JS is another topic and unrelated to the issue’s title. This request can only be solved by developing a new documentation from scratch. And I doubt it’s worth doing so.