Yeah, super good news, it's only an issue with chrome.
Testing the capx in Firefox, there are a few variations but not as marked as in Chrome.
Easy solution, stop using Chrome, yeah ! ^^
I can get it to happen in FireFox too, but it seems Firefox takes more load to get the FPS down. Here's my firefox test with more sprites:
<img src="https://dl.dropbox.com/u/20830426/firefoxTest.png" border="0" />
Also, I'm not sure this test is valid anyway, as you're unlikely to have such a logic in a "true" game. I'm not understanding how spawning 10k sprite is a good way to "lock" the FPS, as the loop only happens when the character is out of the screen, and the layout is supposedly restarted at this moment anyway.
Perhaps I didn't describe the original post properly. The problem isn't so much that if you just happen to have 300000 sprites on screen C2 starts to go wonky, it's that lower frame rates seem to have an affect on the jump arc of the platform behaviour. The purpose of spawning all the sprites and keeping them on screen was simply a way bog the browser down to lower frame rates. I wanted to see how performing the exact same action at different frame rates changed the jump path the player took.
The locking the frame rate post was separate from spawning all these sprites - That second post was what happens to the jump path when the frame rate is locked at 60. At that point, the gravity or whatever seems to be causing the variation, works out fine. It's when fps fluctuations occur that the course of the player changes. The second post was more of a real world example, the first post is what seems to be the same problem taken much more extreme (ie. forcing the game to run at around 30fps instead of 58fps).
I'm no expert at this though <img src="smileys/smiley1.gif" border="0" align="middle" />