Reject non-positive duration in saveGif to avoid empty-frames crash

[Chessing234]

Bug

saveGif('test', 0) (or any non-positive duration) crashes with TypeError: Cannot read properties of undefined (reading 'length') instead of a friendly error. Reported in #8710.

Root cause

In src/image/loading_displaying.js, saveGif validates that duration is a number but not its range. When duration <= 0:

• nFrames = duration * _frameRate is <= 0
• the while (frameIterator < totalNumberOfFrames) loop never executes
• frames stays []
• _generateGlobalPalette(frames) then reads frames[0].length on line 597 and throws.

Fix

Add a 3-line range check directly after the existing typeof duration check, in the same style as the surrounding validators:

if (duration <= 0) {
  throw new Error('Duration parameter must be a positive number');
}

Why this is correct

• A non-positive duration can never produce a valid GIF, so rejecting it up front is semantically correct and matches the issue reporter's suggested behavior ("saveGif() should reject invalid duration early").
• Preserves the existing validator style (type + range checks at the top of the function).
• No behavioral change for any duration > 0; existing tests in test/unit/image/downloading.js continue to pass unchanged.

Fixes #8710

[perminder-17]

Hi, thanks for your work on this.

Adding an explicit duration check feels fine, but I'm not sure it's strictly necessary. The API already documents duration clearly as recording time in seconds, so the intent is fairly self-evident. If a user accidentally passes 0 or a negative value, I'd lean toward a silent no-op rather than throwing, that feels more in line with how p5.js generally handles unexpected input. That said, I'm equally happy to leave it as-is if preferred.

Also, one small hesitation is also around consistency: saveGif already has 7 validation throws, which is a bit heavier than most of the codebase tends to be. Adding an 8th would push it a little further in that direction.

CC: @davepagurek @ksen0