Should deltaTime account for throttling of unfocused tab?

Hi! This came up while fixing a problem with duplicate GIF timing (see discussion in #4824 ). Wanted to ask a larger question about timing and deltaTime here before throwing a workaround into the GIF timing.

My question is: Should a coder expect there to be unpredictable spikes in deltaTime when coming back to a sketch after switching tabs?

This sketch illustrates this. If you click into the sketch, switch tabs, and come back after a few seconds, you will probably see a number that is nowhere near 1000 next to 'deltaTime' in the console (depends on how 'busy' your CPU currently is)

I know this mostly comes down to a combination of window.performance.now and browser throttling behavior with unfocused tab animation callbacks.

This is less of a problem with millis() where a coder would expect the value to correlate to the time since the sketch started. But with deltaTime, the animation frame throttling makes the difference in 'real-time' between frames very unexpected even if it is true to the space between frames.

Should we account for this in deltaTime in some way? My instinct is no, but this isn't clearcut for me because sketches that rely on deltaTime will be very fragile to tab switching.

For me, this brings up larger questions about whether we should manually throttle unfocused sketches in a controlled way by default to make behavior predictable and consistent across browsers/hardware? What do others think? @limzykenneth @montoyamoraga @outofambit @akshay-99 @owenbmcc

Most appropriate sub-area of p5.js?

• Timing

Start with the linked sketch and the discussion in #4824, then trace how deltaTime, millis(), window.performance.now, and unfocused-tab animation callbacks relate. Compare the observed values after switching tabs and review the unanswered design questions about throttling. Done requires a decided, documented behavior or an agreed implementation scope.