In JS development, timers are often used, especially for animation effects and games.
To make the animation run smoothly, we often use a high update rate, such as 60fps. Since the interval between each frame is very short, it is hard to see the specific running status of each frame.
Sometimes it seems that everything works well on the whole, but if you slow down the timer speed, you will find that some of the frames orCodeIs not shown as we think. These potential minor issues are hidden due to the fast playback speed.
To facilitate the observation and debugging of animation scripts, we try to use js to simulate a classic application similar to Windows.Program: Variable Speed Gear, which can instantly modify the operating frequency of the system clock! It sounds amazing ~ In fact, the principle is not complex.
Like the traditional Variable Speed Gear operation mechanism, we use the hook program to hook up the default timer-related APIs --SetTimeout,Setinterval,Cleartimeout,Clearinterval. Of course, the so-called hook program is simply to save the original api reference in advance and then overwrite them with your own program. In this way, we can intercept the timer call and maintain the callback queue based on the rate of the virtual clock, so the timer speed change effect is generated. If the synchronization is more rigorous, you can even overwrite the date object, so that the passage of time will change!
Of course, there are still many problems that are hard to solve.
After the clock frequency is accelerated, the interval between each frame is greatly shortened, or even less than 1 ms. The JS timer frequency is well known and far below this precision. Therefore, we can only use frame skipping to solve this problem. For example, a 2 ms timer should be triggered every 2 ms in theory, but a browser only supports a minimum 16 ms interval, so each time the timer triggers an internal loop call of 16/2 = 8 callbacks, to make up for the lack of frequency. However, since the eight callbacks were executed in one breath in the same event, the first seven interface operations were not rendered immediately, and only 8th operations performed, so there is a feeling of "jumping.
However, this method can only solve the setinterval timer, because its time interval and callback are fixed. For setTimeout, the latency is uncertain each time, and even the next frame cannot be determined whether or not it will continue to run, so the frame-jumping mechanism will not be able to crash.
However, it is easier to implement only one basic function:
JsgearThe javascript Variable Speed Gear plug-in implemented based on this idea strictly encapsulates time-related APIs. Because it is completely made using JS/CSS, it can be used by introducing pages without relying on any plug-ins.
To make it easier to use, we changed the operating interface of the new concept over the past two days and supported the IE6 +, Firefox, chrome, Safari, operabrowser, and quirks modes.
Test Demo: http://www.etherdream.com/JSGear/demo.html
Testing on your own page is simple. You can just insert jsgear. js into all the scripts. Upload a copy to the blog attachment and copy the following code to your own page to use it:
<Scrpt src = "http://files.cnblogs.com/jsapp/jsgear.js"> </SCRIPT>
Of course, it is only a demo version that implements basic functions, and there are still many minor issues. If you have many ideas and suggestions, you are welcome to discuss them.