Closed davepagurek closed 4 months ago
Tagging the core/environment/rendering stewards. Let me know what you think! @limzykenneth, @ChihYungChang, @teragramgius, @tuminzee, @Zarkv, @robin-haxx, @Gaurav-1306
I thought of this before and the main thing I'm unsure about is how it behaves when the framerate is not 60 (or whatever the default framerate is) since they way we achieve that is through skipping frame being processed.
Here's a version of the test sketch that sets 23fps (try toggling the script tags in index.html to test 1.9.0, or changing the target frame rate in setup
): https://editor.p5js.org/davepagurek/sketches/MC1mAZrba
The average fps looks the same to me, and I think that's because the timestamp we were previously using is kind of the same as this one, just with a few ms/μs offset, since previously it was recording when the callback gets run rather than when the browser starts queuing up the callbacks to run. I think since this offset is relatively consistent, but just with extra noise due to scheduling, which you can see in the reduced variance between deltaTime
values while the average fps is still the same.
Ok, it seems the value roughly matches existing behaviour so I'm fine with this. The only thing left is the detail around rounding, with our current implementation we are getting whole numbers from deltaTime
but with the requestAnimationFrame
based value, we are getting more precise floats. Should we round this value to match existing behaviour?
Do you think anything relies on it being a whole number? My initial inclination is to say that it probably doesn't matter (unlike frameCount
, I doubt anyone uses ===
to compare with deltaTime
because of the noisiness) but I haven't thought through yet whether or not there would be other cases where it would make a difference. Maybe just if people print it directly for debugging?
It's probably a bit hard to say. For people printing or drawing the value on canvas, this will likely be a bit of a problem but should be solveable easily. For people relying on its value for animation, it can possibly cause subpixel drawing to happen more often and may be undesirerable but I'm not sure if it really is an issue.
I think for subpixel drawing, users probably already need to be calling round()
manually when converting the values into coordinates, unless they are using the deltaTime
values directly without multiplying or dividing, which seems like a fairly small use case. So in that case, this change would likely not affect many users.
Related to https://github.com/processing/p5.js/issues/5354 (but does not fully solve it)
Changes
This uses the timestamp passed into
requestAnimationFrame
callbacks instead ofwindow.performance.now()
if it's available.This refers to the time when the browser starts calling callbacks, as opposed to the time the callback gets run. The rate between frames should be the same on average: this basically just offsets in time the point at which we measure, but not the time between samples.
The main difference is just that there's less noise in when the browser starts running RAF callbacks compared to when the browser actually runs each. This means that the variance in
deltaTime
goes down, anddeltaTime
values fluctuate less around their average. Previously, I was seeing a variance of around ~0.3, and after, I see a variance of around ~0.1.Some implications:
deltaTime
, your step size will be more consistent each frame.deltaTime
may become slightly less accurate in measuring exactly how much time has elapsed since the last timedraw
was called, but more accurate in measuring the time between scheduled frame updatesSo whether or not this is useful essentially boils down to whether or not we want frames to look like they're taking even steps even though they may not actually be drawn at quite so even steps. I think my gut feeling is that this actually produces perceptually smoother motion: at least personally, I perceive the time discrepancy less than the space discrepancy.
To compare:
Does this make sense to you all too?
PR Checklist
npm run lint
passes