-
Notifications
You must be signed in to change notification settings - Fork 501
Commit
…lot easier internally, and makes sure that even pause / resume operations are completely in sync. - the frames are calculated with the duration passed as an option, so it works as usual. - added a "frames" option, so that Fx can now work without a pre-determined duration. - rearranged some internal methods and properties. - added a "stop" method, that basically pauses the animation and fires the stop event. - added the "isRunning" method. - every method and option works as before.
- Loading branch information
There are no files selected for viewing
13 comments
on commit 6b4feb3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think I like this. The benefit of time based animations is that they can catch up if the animation runs slow. It also goes against the future best practice of only updating the DOM during "beforepaint" events. Allowing frames to be ignored as required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also don't like this. If you tell the animation to run for 600ms, you would have 36 frames, and you're relying heavily on each frame executing at an average of one every 16.67 ms. In actuality, you might find those frames run an average of every 18ms, which would cause your animation to take 648ms long! For meticulously timed animations, this could be very bad!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, however this way, even on slower computers, the animations will be fully visible without jumping. Also, with frames, it is much easier to handle perfect syncing for start / pause / resume.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could still handle perfect syncing by treating time as a global frame counter.
time = Math.floor(Date.now() / fps);
Then you're sure to have perfect frame integers, and it still allows skipping of frames, if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding slower computers (I am assuming netbooks, tablets, etc?): with the browsers moving to hardware accelerated animation & layout, is it still neccessary to do the gruntwork like this? Personally, I'd rather have the animations in a UI done in exactly the time I specified, than having users wait for the animation to (smoothly) finish. If they're running on a slow computer, choppy animations is something they will have to deal with/expect. My thinking is the users would rather have that than unnecessary wait times.
However, I do see the other side of the argument, too. Maybe it's something that could be optional, so neither group (time vs frame based animators) has to deal with results they didn't intend?
(All that assuming I am reading the commit correctly and haven't missed something dealing with my concerns already…)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ for option.
Sometimes it's really important that it's accurat, but in other situation it's more important that its smooth and never jumps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would this be in 1.3.1?
Just dropped this into my apps and some animations run noticeable slow in VM IE. From a user experience, time matters and not the speed of the system. An element should appear in specific time period, no matter which system the user is on … I don't think of many use cases where I would use frames over duration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the universal time that calyptus mentioned. Seems like the middle of the road option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, after some more checking: Several animations run ridiculously slow IE8 in VM, mostly alpha blending for elements or modal dialog background.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed with harald. i dont want to have watch a painfullly slow animation, even if it is complete and I see all frames. I'd rather it skip and be done in a second or half a second or whatever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the status on that, will it stay in 1.3.1? I am stuck more and more on overlay fade ins that take painfully long, showing that this is not a compatible change and maybe not a pattern we should prefer over duration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 for time. Time matters!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually this needs to be reverted since it's not a bug fix. This should go in 1.4wip, no?
Accidental global!