[xav-ie]

Summary

• Capture wall-clock timestamps during recording so SVG animation duration matches real elapsed time, even when CanvasToImage runs slower than the target framerate
• Derive the actual capture rate (totalFrames / wallDuration) and pass it to ffmpeg as the input framerate so MP4 duration matches too

Context

When CanvasToImage is slower than the target frame interval, fewer frames are captured than framerate × duration predicts. Previously the SVG used frame-index-based timing, causing animations to play back too fast. This fix uses real wall-clock timestamps instead.

Test plan

• Existing tests pass (go test ./...)
• Added TestSVGGenerator_SlowCaptureTimestamp to verify non-uniform timestamps produce correct animation timing
• Each commit compiles individually (bisectable)

[jackspirou]

Closing as superseded by the merged timing implementation.
Main preserves visible elapsed time across SVG, GIF, MP4, and WebM output.
It includes the final visible hold, excludes Hide intervals, and repeats raster states at their recorded timestamps.
This also handles raster-only recordings, without an SVG-dependent average frame rate.

The reviewed PR head rendered a 2.5-second visible hold as a 1-second SVG.
The replacement rendered that hold as 2.5 seconds.
The merged implementation includes regression tests for hidden spans, slow capture, raster timing, and capture failures.

[jackspirou]

Thank you, @xav-ie, for identifying the recording-clock problem and adding a regression test. Your proposal established the user benefit we must preserve: SVG and video playback must follow visible elapsed recording time, including slow capture. The current implementation uses visible frame timestamps and raster repetition. I am auditing those contracts against your original proposal, including hidden intervals and capture failures, rather than treating PR closure as proof that the problem is solved. I will post the final coverage evidence here.

[jackspirou]

The timing benefit audit is complete. The current implementation preserves visible elapsed time rather than nominal capture count. The slow-capture regression and nonuniform raster-state regression pass with the race detector. Hidden spans, the final visible hold, SVG-only capture, and capture/encoder failures also have passing coverage.

A fresh native capture with 2.5 seconds visible and 1.5 seconds hidden produced a 2.50-second SVG and 2.52-second MP4, GIF, and WebM outputs. A second raster-only capture with PlaybackSpeed 2 and LoopOffset 25 produced 1.28-second outputs in all three formats, against a 1.25-second target. The small differences are encoder frame quantization. Chrome and real ffmpeg were used.

This covers the original slow-capture and video timing value. No timing benefit was discarded when this PR closed. Thank you again for identifying the issue and supplying its first regression test.