Opened 9 years ago
Closed 9 years ago
#14634 closed bug (notabug)
step and progress callbacks should fire for the last frame, before complete
Reported by: | Owned by: | gnarf | |
---|---|---|---|
Priority: | low | Milestone: | 1.11.1/2.1.1 |
Component: | effects | Version: | 1.8.0 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Consider the following:
$('#target').animate({
height: 200
}, {
duration: 150, easing: 'easeInOutSine', /*queue: false,*/ step: function () {
$('#console').append('step: ' + $('#target').height() + "\n");
}, complete: function () {
$('#console').append('complete: ' + $('#target').height() + "\n");
}
});
I expect step to be called back on every value change, however this often isn't true for the final callback, especially when the duration is short. Sometimes it does work.
Change History (14)
comment:1 Changed 9 years ago by
Owner: | set to [email protected]… |
---|---|
Status: | new → pending |
comment:2 Changed 9 years ago by
When I run the jsfiddle above, I see the following output: step: 0 step: 0 step: 12 step: 27 step: 41 step: 57 step: 83 step: 190 step: 199 complete: 200
I'd expect to see the same value in the last call of step as in the complete callback. There should be one last call of step right before complete, to ensure that the final animation value is ever set in the steps.
comment:3 Changed 9 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
comment:4 Changed 9 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
comment:5 Changed 9 years ago by
Component: | unfiled → effects |
---|---|
Priority: | undecided → low |
Status: | reopened → open |
Closed because "anonymous" answered it in the pending state.
Seems reasonable to have the step function reliably get the final value, we should be able to do that by calling it from the complete function perhaps?
comment:6 Changed 9 years ago by
I still haven't heard any use cases provided, just "I thought this would happen and it didn't." I'm not sure why we'd change our semantics without a valid use case.
comment:7 Changed 9 years ago by
Maybe because our "semantics" isn't valid? Whatever it means… Saying this as a question I'd ask myself if someone sent me a ticket.
Use case: You run main animation and something else depends on it's progress. Maybe it fires another animation every 10% of it's progresses. Maybe it does something else.
When that progress is not working as expected it's becomes difficult to depend on it and you'd start using extra functionality and writing extra code making everything bigger and more complex.
comment:8 Changed 9 years ago by
I'm really not sure what you're talking about. Surely you want to know when the animation is fully complete, that's what the complete callback is for. You can't rely on any portion of the animation being captured in the step callback. It's entirely possible that your duration is too small or the window loses focus, or some extremely intensive blocking operation occurs and you get a single step callback and then the animation completes. Or the animation could be stopped. You need to account for this.
Use case: You run main animation and something else depends on it's progress. Maybe it fires another animation every 10% of it's progresses. Maybe it does something else.
These don't sound like use cases. Firing another animation every 10% is going to fail in some scenarios, so you'd need to provide details of an actual example for us to understand why you'd be starting those animations and how you'd handle the various "hiccups."
"Maybe it does something else" is certainly not a use case.
comment:9 Changed 9 years ago by
Scott. I'm not going to argue with your points, they are valid, nor explain how to make use of progress in certain situations, because your imagination is short on that.
It makes sense to notify that the progress has hit 100% when animation is complete to avoid using another listener just for that separately (if you are already using the other one for something else).
comment:10 Changed 9 years ago by
Owner: | changed from [email protected]… to gnarf |
---|---|
Status: | open → assigned |
Summary: | Animations sometimes don't fire the last step event → step and progress callbacks should fire for the last frame, before complete |
Version: | 1.10.2 → 1.8.0 |
This is definitely legit, and here is the use case:
http://jsbin.com/odocid/2222/edit
This demo I've used in a few talks is actually not painting the last "frame" of each animation. However since everything is random, and it immediately starts the next animation, I've never noticed it.
I'll see if I can tackle this.
comment:11 Changed 9 years ago by
Thanks for providing an actual use case where this would make a difference and not require an explicit check for completeness inside the step callback.
comment:12 Changed 9 years ago by
Sorry for answering late. I often use it for something like this: http://jsfiddle.net/f8S3B/2/
comment:13 Changed 9 years ago by
Milestone: | None → 1.11.1/2.1.1 |
---|
comment:14 Changed 9 years ago by
Resolution: | → notabug |
---|---|
Status: | assigned → closed |
This is actually working as intended.
The "step" callback happens >before< the value is set, where the "progress" callback happens >after< the value is set.
Also, the first argument to the step function is the value that will be set: http://jsfiddle.net/N5DYg/5/
Closing this as notabug
Can you be more specific about what you expect and what you actually see? What do you mean by the "final callback"? The complete callback seems to fire reliably, and the demo seems to work as I would expect.