I had both a PG and a locally-run scene playing. Both of these projects have a particle emitter in it, and I was using this as the passive visual confirmation of time scale shifting. Over time, as I left the browser open (while not necessarily leaving the scene open, so 99% of the time this scene was a background tab), over the course of a couple of days, the behavior of moving items within the scene seems to globally speed up for the playground, while remaining the same for the local repo. This seems to affect all PG projects that I open, at any point. This also affects user input. The arrow keys for moving around a default scene were also notably more sensitive, with a simple tap of the forward key darting me clear through the default PG scene.
The only way to get this time scale to resynchronize was to restart the browser. Then, the PG projects were running at the same speed as the local project. Any idea what’s happening here?
This seems to be a hard bug to reproduce on demand, because it requires leaving a browser open for a few days, potentially with at least one PG scene on a tab somewhere, background or foreground, with an identically-composed scene that’s run in another tab for comparing the playground behavior.
Additional information: Using google chrome on an M1 macbook pro. An initial guess I have is that, when the macbook’s battery drops below 20%, the refresh rate of chrome halves instead of retaining the ProMotion native refresh rate. After a recharge, the frame rate goes back up. I’m wondering whether this frame rate shift has something to do with the time scale shifting.
Thanks for that link. I understand the concept of framerate independence, though not necessarily half an hour’s worth of detail of it. I’d have to watch that whole video to confirm. Indeed, that is the thing I am wondering about: Are particle emitters in BJS framerate-dependent? Because particle emitters as well as all of my keyboard inputs gradually get faster and faster the longer my browser stays open. If emitters are not framerate-dependent, then this is a bug.
[EDIT] Actually, this is a bug, regardless of whether emitters are framerate-dependent. Leaving BJS playground tabs open for too long, even in the background, seems to cause them to universally speed up.
I think this can happen if you dont use date.now as an anchor against potential js timer drift. I remember having to fix this a long time ago, not babylon or game related though.
Hello! This is a good question, honestly. I used to think “a few hours” but I refreshed a scene recently, only a few minutes after restarting chrome, and it resulted in super fast playback, with a lot of CPU load when it happened. That scene has proprietary information in it, though. I’ll try to port it in another playground with the relevant data obscured.
how long should i leave the tab openn im background ?