michaelmob
commented
6 years ago I believe the capture was moved into the async because I thought that capture was too expensive to be on the main thread, only later did I find out that the capture wasn't the bottleneck at all
Looks good. Thanks for contributing!
Cause for issue #62:
When the computer is unable to process at the desired framerate the Task.Run() exceeds the avaliable threads in the threadpool, which generates a giant task queue. This queue keeps running after stop have been requested and the images have been collected for the frame edit screen.
Fix:
Leaving the Capture() outside the Task.Run(), caps frame generation to the computer's performance which would solve this problem, but the capture was moved inside the Task.Run in the "Stutter reducer" (04cf3a15c254f8bbdfbb6b3b6509adaee8abb43f) commit (which is weird, maybe it was related to the frame skipping issue?). Anyway, another solution is to ignore tasks running after que stop have been requested to prevent unwanted frames from rendering.
Frame Skipping:
Using Interlocked.Increment on the frame count prevents race condition from multiple parallel tasks running, therefore preventing frames from being overwritten or skipped.