Automatically adjust wait timeout in fader - #42
Open
ohinckel wants to merge 2 commits into
Open
Conversation
Owner
|
This topic has to wait as well... |
Author
|
Thanks for you feedback. If I can do anything, let me know. |
…he last set duration to calculate the new one
18 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was trying to use the
item.fade()function with a short interval (something like ~0.02) and noticed that the execution of the complete fade process took longer than expected by the amount of steps required to fade to the target color.Example: Current value is 100, target value is 200 and should be incremented by 1 each 0.02 seconds. The total execution time should be 100 * 0.02 = 2 seconds. But since the execution time of one single step is not taken into account, the total execution time was a little bit larger (guessed ~2.2 seconds), which makes problems when you want to synchronize things.
The following patch adjusts the timeout dynamically by checking the execution time of each step with the time expected. If it's larger than expected than the timeout is decreased, if it's shorter the timeout will be increased. This way the total execution will nearly be the expected execution time.
One thing came into my mind: what, if the fade execution time for each step is longer than the given delta? E.g. the processing of one fade step will take 0.01 seconds, but the delta is 0.005. Maybe this border case should be checked. But while testing a little bit around I never came into this situation. A possible solution would also be to check if the specified delta is not shorter that the possible one (maybe 0.01 or 0.02 - don't know how fast a machine can be) - but this will only be a guessed limit.