saveGif issue when used with translucent background

[meiamsome]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

p5.js version

1.5.0

Web browser and version

Firefox 108.0

Operating System

Linux, Mac

Steps to reproduce this

Steps:

1. Create a sketch that uses a translucent background and then use saveGif
2. The call to saveGif reuslts in the canvas being cleared due to pixelDensity call here:

   p5.js/src/image/loading_displaying.js

   Line 286 in 1246fc2

   this.pixelDensity(1);

3. The resulting GIF starts without the faded past frames, resulting in a jump:
   
   Compared to how the GIF should look:
   

Snippet:

Example sketch that saves two gifs, one with the bug (test.gif) and one using the workaround of overriding pixelDensity (testFix.gif)

p5.js Web Editor link

function setup() {
  createCanvas(100, 100);
  angleMode(DEGREES);
  background(0, 0, 0, 255);
  pixelDensity(1);
}

function draw() {
  background(0, 0, 0, 25);
  
  color(255, 255, 255);
  const angle = 10 * frameCount % 360;
  circle(50 + 25 * sin(angle), 50 + 25 * cos(angle), 10);
  
  // Wait for a full rotation before saving a gif:
  if (frameCount === 36) {
    setTimeout(
      () => saveGif(
        'test.gif', 
        36,
        {
          delay: 0,
          units: 'frames',
        },
      ),
      0,
    );
  }
  if (frameCount === 108) {
    // Override pixelDensity to prevent the canvas being cleared
    p5.instance.pixelDensity = () => {};
    setTimeout(
      () => saveGif(
        'testFix.gif', 
        36,
        {
          delay: 0,
          units: 'frames',
        },
      ),
      0,
    )
  }
}

Suggestions

1. It might be worth changing saveGif to not override the pixelDensity of the current sketch, which would require more complicated maths for the buffers but prevents the change
2. It might be worth having an option on saveGif to render n frames before starting the recording. This option might be useful anyway, as you'd be able to rewrite the sketch above to something like:

function setup() {
  createCanvas(100, 100);
  angleMode(DEGREES);
  background(0, 0, 0, 255);
  pixelDensity(1);
  noLoop();
  setTimeout(
    () => saveGif(
      'test.gif', 
      36,
      {
        delay: 0,
        // Wait for a full rotation before saving a gif:
        preamble: 36,
        units: 'frames',
      },
    ),
    0,
  );
}

function draw() {
  background(0, 0, 0, 25);
  
  color(255, 255, 255);
  const angle = 10 * frameCount % 360;
  circle(50 + 25 * sin(angle), 50 + 25 * cos(angle), 10);
}

[davepagurek]

Both of your suggestions are good! I think which one we pick will depend on whether we think it's best for saveGif to try to restart the animation, or for it to try to pick up from whenever you call it.

I think I'm slightly in favour of not trying to restart the animation as the more futureproof option:

• currently, we just reset the main canvas, but if one is also doing a cumulative animation on a createGraphics canvas, that won't currently get reset, which might leave an animation only partially reset
• sketches that update state each frame and draw based on that (e.g. a physics simulation) also don't get reset, and I'm not sure we'll ever be able to correctly reset arbitrary pieces of users' code

If we decide to make saveGif not restart the animation, we'll have to also make the following changes:

• Like you noted, we'll have to resize the saved frames down to 1x pixel density before encoding it into a gif
• There is a known issue right now where saveGif can't be called inside of setup. We'd have to address that to provide an easy way to record from the first frame if we no longer try to reset the animation.

That said, making it render a few frames before recording would probably be a smaller change. We already have a delay paremeter, so maybe we could add an option specifying whether or not to actually draw those delayed frames or not.

[thecodermaniac]

is the issue fixed ? if not i will work on it

[Qianqianye]

Hi @thecodermaniac, thanks for your interest in working on it. This issue is still open, and I will assign you.
Please share some thoughts in this issue on how you'd like to fix this bug before opening a pull request, thanks!

[ffd8]

Was experimenting with saveGif() and ran into perhaps the same issue as above, the canvas being reset. Tried making a little ajax style loader, which required already having one cycle iteration, then capturing it at one moment in the flow for x frames. would be oh so nice if the function could just capture frames from the moment it's activated (one could call a clear() or background() if they wanted really from scratch? It was similar within processing for the Video Export library, where one just marked when to start and stop recording within a sketch.

Here's how quicktime captures (turned into a gif, fps is off...):

Here's how the saveGif() captured it:

(unfortunately noSmooth() didn't keep edges crisp (nearest neighbor) as hoped for)

Based on this code:

let frames = 60, counter = 0

function setup() {
	createCanvas(100, 100)
	background(128)
	noSmooth()
	noFill()
	stroke(255)
}

function draw() {
	background(0, 5)
	let osc = (counter%frames)/frames*TWO_PI
	let x = sin(osc)*width/4
	let y = cos(osc)*width/4
	translate(width/2+x, height/2+y)
	circle(0, 0, width*.5)
	counter++
}

function keyPressed(){
	if(key == 'R'){
		// counter = 0
		// clear()
		saveGif('P5LIVE', frames, {units:'frames'})
	}
}

[al6862]

Hi, is this issue still available? If @thecodermaniac is okay with it, I could take over!