inlinevoid's picture

Inconsistent FrameEventArgs.Time

I'm not sure if this is a bug or just expected behavior and I'm interpreting/handling it the wrong way.

I've got an update method that can sometimes cause high CPU usage (for video processing). I noticed the framerate of the video was wrong, even though the timing to control it should be correct. So I created a stopwatch to output the FrameEventArgs.Time total every second.

        Stopwatch stopwatch;
        double argsTime;
        public void Update(FrameEventArgs args)
        {
            argsTime += args.Time;
            if(stopwatch.Elapsed.TotalSeconds >= 1)
            {
                Console.WriteLine("Stopwatch time: {0}", stopwatch.Elapsed.TotalMilliseconds);
                Console.WriteLine("ArgsTime time: {0}", argsTime * 1000);
                argsTime = 0;
                stopwatch.Restart();
            }
 
            // Do some video processing, this can take around 7ms every time a new frame is loaded
        }

This outputs:
Stopwatch time: 1015.3431
ArgsTime time: 866.5902

By the time the stopwatch hits 1 second, FrameEventArgs is behind by about 200ms.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
winterhell's picture

Hey, you should know that on some machines there is an inconsistency with the Stopwatch.
On my machine for example TimeSpan.TicksPerSecond is = 10,000,000 while
Stopwatch.Frequency is 3,222,705 (probably the actual CPU frequency). Calculating the frametime with stopwatch.ElapsedTicks and Stopwatch.Frequency gives the correct number.
Just for FPS you may want to use a Timer event with 1 second tick.

inlinevoid's picture

That's good to know, I don't think I'm having that issue though. My stopwatch seems accurate. Also, when I cut out the video processing part of my Update(), the FrameEventArgs.Time matches up pretty closely to the Stopwatch.

winterhell's picture

Is it possible that the difference in the times is related to the initialization process?
Can you start the counters after the first few frames?
Also I think you may encounter a difference of 1 frametime but if your frametime is really 7ms then its not the issue here.

inlinevoid's picture

"Is it possible that the difference in the times is related to the initialization process?"

It couldn't be, both timers are reset every time Stopwatch reaches a second.

the Fiddler's picture

OpenTK is also using System.Diagnostics.Stopwatch internally. The relevant code is in the "DispatchUpdateFrame" and "DispatchRenderFrame" functions.

A drift of this size is not right. Can you please make a bug report and attach a small test case that reproduces the problem?

inlinevoid's picture
the Fiddler's picture

Thanks, investigating.

the Fiddler's picture

Commit eacc8966 fixes this issue.

Please test and file a bug report if you can still reproduce this.