Fix ImageAnimator to render the correct frames

[jeffhandley]

Fixes #52144 with an update to how the animation timing is handled. Also fixes #39405 by using the same implementation across both Windows and Unix.

This PR will remain a draft until #51981 is merged, as the animation assets used by the tests in this PR should flow through runtime-assets instead of being merged into runtime.

Here's what I found from the current implementation:

1. The animation is relying on Thread.Sleep(50) to be very accurate; it's not
2. Once a frame's time has elapsed, the animation very naively progresses 1 frame and sets the next frame's timer to 0
   • This does not account for the scenario of the thread having slept longer than a frame's duration
   • It also causes any leftover elapsed time to be lost
3. When animation begins, it immediately progresses instead of initially sleeping
   • This results in the initial frame being skipped if its duration is less than 50ms

The new implementation converts frame delay times into frame "end times" so that we know at what time each frame's time is up. Then, as animation progresses, we can accurately determine which frame should be rendered at that time, preventing drift.

This PR also adds a manual test for image animator that captures the frames of the animation for visual verification. From those tests, I was able to discover that animation on Linux (Ubuntu 20.04) is corrupting the rendered images in a couple of ways. Those seem to be issues down at the libgdiplus level though, so I didn't want to block this PR on those.

ImageAnimator wasn't respecting a GIF's animation repeat count either, but I decided to also consider that out of scope for this PR. I'll file an issue for that too, but I imagine we will close it until we receive customer reports of it.

[ghost]

Tagging subscribers to this area: @safern, @tarekgh
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #52144 with an update to how the animation timing is handled. Also fixes #39405 by using the same implementation across both Windows and Unix.

This PR will remain a draft until #51981 is merged, as the animation assets used by the tests in this PR should flow through runtime-assets instead of being merged into runtime.

Here's what I found from the current implementation:

1. The animation is relying on Thread.Sleep(50) to be very accurate; it's not
2. Once a frame's time has elapsed, the animation very naively progresses 1 frame and sets the next frame's timer to 0
   • This does not account for the scenario of the thread having slept longer than a frame's duration
   • It also causes any leftover elapsed time to be lost
3. When animation begins, it immediately progresses instead of initially sleeping
   • This results in the initial frame being skipped if its duration is less than 50ms

The new implementation converts frame delay times into frame "end times" so that we know at what time each frame's time is up. Then, as animation progresses, we can accurately determine which frame should be rendered at that time, preventing drift.

This PR also adds a manual test for image animator that captures the frames of the animation for visual verification. From those tests, I was able to discover that animation on Linux (Ubuntu 20.04) is corrupting the rendered images in a couple of ways. Those seem to be issues down at the libgdiplus level though, so I didn't want to block this PR on those.

ImageAnimator wasn't respecting a GIF's animation repeat count either, but I decided to also consider that out of scope for this PR. I'll file an issue for that too, but I imagine we will close it until we receive customer reports of it.

Author:	jeffhandley
Assignees:	-
Labels:	area-System.Drawing
Milestone:	-

[jeffhandley]

I couldn't resist the urge to respect the animation loop limit too; it's straightforward enough. Another commit will be soon pushed with that added in.

[safern]

LGTM! Thanks 🎉

[stephentoub]

Nit:

Stopwatch stopwatch = Stopwatch.StartNew();