setTimeout is that your animations must be time-based instead of frame-based, i.e. requestAnimationFrame causes the browser to redraw and call your function before that frame gets to the screen. Assuming you are running in an arbitrary browsing session, you can never really know how long the browser will take to draw a particular frame. When you are animating content, or when your DOM animations absolutely must synchronize with canvas content animations, do make sure to use window.requestAnimationFrame, and not older methods such as setTimeout(). If you are setting a transform on something that would overlap its container's bounds, you may want to set overflow: hidden on that container for the duration of the animation. Something to be careful of is that overflow may end up causing re-layout, or other expensive calculations. Though some browsers make some effort for other properties to be animated quickly, these are pretty much the only ones semi-guaranteed to be fast across all browsers. In this vein, it is worth trying to stick to animating only transform and opacity properties.
Speaking of the assumptions that the browser can make, you should avoid causing it to have to re-layout during animations.
There are signals at the beginning and end of animations that allow you to attach JavaScript callbacks and form a rudimentary form of synchronization (though there are no guarantees on how promptly these callbacks will happen). When you animate position with JavaScript, the browser cannot easily make that same assumption, and so you might end up causing it to draw only the newly-exposed region of content, which may introduce slow-down. To take a concrete example, if you start a CSS transition to move something from off-screen so that it is fully visible on-screen, the browser knows that the related content will end up completely visible to the user and can then pre-render that content. Because of this, the browser can make some assumptions that it can't easily make when you're manually tweaking values in JavaScript. The reason for this is that CSS transitions/animations are much higher level than JavaScript, and express a very specific intent. Though JavaScript animations can be easier to express at times, unless you have a great need to synchronize UI animation state with game animation state, you're unlikely to be able to do a better job than the browser. If you are using DOM for your UI, which I would certainly recommend, you really ought to use CSS transitions and/or CSS animations, rather than JavaScript-powered animations.
0 kommentar(er)
