Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frame rate detection on MotionMark occasionally sees older devices as 90 fps instead of 60 #50

Open
shallawa opened this issue Apr 25, 2024 · 0 comments

Comments

@shallawa
Copy link
Contributor

The incremental frame rate average calculation gives much more weight to the last frame. So sometimes it can be wildly inaccurate. And this makes it pick the wrong predefined frame rate.

shallawa added a commit to shallawa/MotionMark that referenced this issue Apr 25, 2024
… 90 fps instead of 60

WebKit#50
rdar://127012351

To get the target frame rate we sample 300 rAFs and we get the average of their
frame rates. We calculate the average incrementally using some sort of exponential
decay. The average starts very small but keeps increasing until it reaches the
actual target frame rate and it is supposed to stay unchanged much. Then we compare
the final average rate with predefined frame rates and get the closest one.

The purpose of this incremental calculation was to show the target frame rate
being calculated in the detectionProgressElement in the developer page.

In addition to having the incremental average very small for more than 100 frames,
the bigger problem is this incremental average calculation gives more weight to
the last frame. And if it is considerably large for any reason, the final average
will be wildly inaccurate.

The fix is to simplify the calculations:

1. For count == 0: The firstTimeStamp will be recorded and and we won't update
   the detectionProgressElement.

2. For count > 0:
	averageFrameLength = (timestamp - firstTimeStamp) / count;
	averageFrameRate = 1000 / averageFrameLength;
shallawa added a commit to shallawa/MotionMark that referenced this issue Apr 25, 2024
… 90 fps instead of 60

WebKit#50
rdar://127012351

To get the target frame rate we sample 300 rAFs and we get the average of their
frame rates. We calculate the average incrementally using some sort of exponential
decay. The average starts very small but keeps increasing until it reaches the
actual target frame rate and it is supposed to stay unchanged much. Then we compare
the final average rate with predefined frame rates and get the closest one.

The purpose of this incremental calculation was to show the target frame rate
being calculated in the detectionProgressElement in the developer page.

In addition to having the incremental average very small for more than 100 frames,
the bigger problem is this incremental average calculation gives more weight to
the last frame. And if it is considerably large for any reason, the final average
will be wildly inaccurate.

The fix is to simplify the calculations:

1. For count == 0: The firstTimeStamp will be recorded and and we won't update
   the detectionProgressElement.

2. For count > 0:
   averageFrameLength = (timestamp - firstTimeStamp) / count;
   averageFrameRate = 1000 / averageFrameLength;
smfr pushed a commit that referenced this issue Apr 25, 2024
… 90 fps instead of 60

#50
rdar://127012351

To get the target frame rate we sample 300 rAFs and we get the average of their
frame rates. We calculate the average incrementally using some sort of exponential
decay. The average starts very small but keeps increasing until it reaches the
actual target frame rate and it is supposed to stay unchanged much. Then we compare
the final average rate with predefined frame rates and get the closest one.

The purpose of this incremental calculation was to show the target frame rate
being calculated in the detectionProgressElement in the developer page.

In addition to having the incremental average very small for more than 100 frames,
the bigger problem is this incremental average calculation gives more weight to
the last frame. And if it is considerably large for any reason, the final average
will be wildly inaccurate.

The fix is to simplify the calculations:

1. For count == 0: The firstTimeStamp will be recorded and and we won't update
   the detectionProgressElement.

2. For count > 0:
   averageFrameLength = (timestamp - firstTimeStamp) / count;
   averageFrameRate = 1000 / averageFrameLength;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant