Animated GIFs freeze after the browser tab is off screen.

[sflanker]

Most appropriate sub-area of p5.js?

• Accessibility (Web Accessibility)
• Build tools and processes
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Friendly error system
• Image
• IO (Input/Output)
• Localization
• Math
• Unit Testing
• Typography
• Utilities
• WebGL
• Other (specify if possible)

Details about the bug:

• p5.js version: 1.4.0
• Web browser and version: Brave Version 1.30.86 Chromium: 94.0.4606.61 (Official Build) (x86_64)
• Operating System: MacOSX 10.15.7

Repro Steps

1. Open a sketch that displays an animated GIF using image() in every call to draw() with all default settings.
2. Make sure the GIF is set to animate forever (no limit on the number of loops).
3. Switch to a different desktop (so that the browser window is off screen), or switch to a different tab within the same browser window.
4. Switch back to the original browser tab.

Expected

The GIF should still be animating

Actual

The GIF is frozen for some period of time (the longer the tab was off screen the longer it is frozen).

Example

https://editor.p5js.org/Kumu-Paul/sketches/T_SbGe-yK

let img;

function preload() {
  img = loadImage("https://www.paulwheeler.us/files/catbus-2.gif");
}

function setup() {
  createCanvas(300, 300);
}

function draw() {
  background(200);

  scale(0.4, 0.4);

  image(img, 10, 10);
}

Cause

p5.Image.js line 227

const curTime = pInst._lastFrameTime + pInst.deltaTime;

This use of deltaTime is incorrect. This line should just be:

const curTime = pInst.millis();

[stalgiag]

Thanks for this. This is a known issue that didn't remain well documented after another problem was fixed.

See the discussion in #4824 & #4839.

If I remember correctly, there were other use cases that will break if plain millis() is used but I could be wrong.

[sflanker]

@stalgiag Interesting. I see from your example in #4824 how the use of millis() or window.performance.now() could be a problem. However there's definitely something wrong with pInst._lastFrameTime + pInst.deltaTime since in my testing it literally goes backward in time and then we have to wait for it to catch up to props.lastChangeTime before another frame is displayed (which I would argue is a lot worse than animations being slightly out of sync).

[frigorific44]

So, what seems to be going on is that since pInst.deltaTime is actually the difference between pInst._lastFrameTime and its previously held value, using pInst._lastFrameTime + pInst.deltaTime as curTime is an estimate. When the focus is moved back to the window after having been un-focused for a while, the time between frames quickly drops, so there is a frame which way over-estimates with a huge deltaTime still based on the un-focused state, and the misjudged curTime ends up getting stored in props.lastChangeTime. Next time around we are then comparing with a props.lastChangeTime which is still a decent way out, and so we have to wait for it to catch up.
I'm not sure how remedy this, however, but I may come back to it at some point.

(This is also basically my first ever contribution—to anything—so hopefully that was useful information.)