Skip to content

Conversation

@geeksville
Copy link
Contributor

On my app I noticed that each time I called setTargetFPS the transitions
would become faster and faster, until finally they don't even take one
frame.  The problem was that the FP math for calculating changeRatio
would (because of rounding err) keep shrinking the number of ticksPerFrame.

This change instead computs ticksPerFrame/perTransition based on the
requested display time, so error can't accumulate from a series of calls.

(In my app I only bump up target FPS before each transition but then
I lower it down again afterwards to save CPU)

    On my app I noticed that each time I called setTargetFPS the transitions
    would become faster and faster, until finally they don't even take one
    frame.  The problem was that the FP math for calculating changeRatio
    would (because of rounding err) keep shrinking the number of ticksPerFrame.

    This change instead computs ticksPerFrame/perTransition based on the
    requested display time, so error can't accumulate from a series of calls.

    (In my app I only bump up target FPS before each transition but then
    I lower it down again afterwards to save CPU)
@marcelstoer marcelstoer merged commit 3398c97 into ThingPulse:master Feb 21, 2020
bratoff pushed a commit to bratoff/esp8266-oled-ssd1306 that referenced this pull request Jun 7, 2020
…FPS (ThingPulse#275)

Signed-off-by: Bruce Ratoff <bratoff@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants