DHTML Lab - dhtmlab.com - Smooth animation using DHTML | 6
Smooth animation using DHTML
part 3 - first tests
You've seen the code for the first test. Let's discuss how well it performs. I'll start out by looking at how quickly the browsers move the layer when no delay is present. In other words the aforementioned for()-loop setup. This test has been run on three of the systems in the test. On every occasion the for()-loop test showed that it took an insignificant amount of time to execute.
for()-loop test
Test setup
The code was taken from the setTimeout() test, but altered to use a for()-loop. The setTimeout() call had been commented out, and the begin_test() function altered slightly. The test has been run on 3 systems: Windows NT, Linux 2.2.12 and Windows 98. All systems were tested with Netscape Communicator 4.61 or 4.7. The Windows NT system was also tested with MSIE 5.
All tests were run with a canvas size of 520x362, and the 69x62 pixel image as content of the layer. The test itself is found in the test section.
Test results
| Browser and system | Run #1 | Run #2 | Run #3 | Run #4 | Run #5 |
| Netscape Communicator 4.7, Windows NT, P3/400 | 300 | 301 | 310 | 301 | 310 |
| Microsoft Internet Explorer 5, Windows NT, P3/400 | 1021 | 941 | 1021 | ||
| Netscape Communicator 4.7, Linux 2.2.12, P3/400 | 210 | 215 | 221 | ||
| Netscape Communicator 4.61, Windows 98, P2/350 | 270 | 280 | 270 |
With a canvas size of 520x362 the test has a total of 1500/1502 steps. The test took from 210ms to 1021ms from start to finish. This means that the actual movement of the layer takes from 0.14ms to 0.68ms. From before we know that the longest delay we can live with that still gives smooth animation is 40ms. This test gives us a clear view of how much time is left to do other things once the actual layer movement is done. In all cases the actual time spent moving the layer was less than 1ms, which means that we have 39ms to do other things. In this kind of an application 39ms is an eternity.
Why not use the for()-loop?
There are two reasons. First of all it doesn't create visible layer movement in MSIE. MSIE actually moves the object around in the browser window, but the display is never updated. This is because MSIE does not update the screen unless the browser is in an idle state, which it never reaches when you use a for()-loop. Therefore you can't actually see that the layer is moving.
The second reason is that you have no control over how fast the animation runs. You're not controlling the delay here, it simply runs as fast as it can. Therefore you'll see different speeds across different platforms/browsers. When you do animations like this you'd like to control the speed, so the for()-loop solution is therefore discarded as useless. I'll come back to the for()-loop later though.
setTimeout() animation test
The first test I'll look at that uses a delay is the one that uses setTimeout(). You've already seen the code behind it, so I won't go into details. Instead, lets look at the test setup:
Test setup
The setTimeout() test is the one that has been run on the most systems and browsers. That is, four operating systems and seven browsers:
- Netscape Communicator 4.6
- Netscape Communicator 4.61
- Netscape Communicator 4.7
- Mozilla Milestone 10
- Microsoft Internet Explorer 4 (Compatibility mode)
- Microsoft Internet Explorer 4.5
- Microsoft Internet Explorer 5
The tests have also been run with 3 different delay settings: 1ms, 10ms and 40ms. Again, the canvas size has been set to 520x362 and the 69x62 pixel image is used. In Mozilla, I didn't spend time working on getting the canvas size written to the form, so I set the canvas size to approximately the right value using a correctly set Navigator 4.7 as a guide. I believe that since I got the approximately same result in Mozilla as Navigator 4.7 the test was correctly set up. This test is of course also found in the test section.
Test results
1ms delay
| Browser and system | Run #1 | Run #2 | Run #3 | Run #4 | Run #5 |
| Netscape Communicator 4.7, Windows 98, P3/450 | 80740 | 80690 | 80850 | 80740 | 80790 |
| Netscape Communicator 4.61, Windows 98, P3/450 | 80740 | 80850 | 80630 | 80630 | 80680 |
| Microsoft Internet Explorer 4 (Compatibility mode), Windows 98, P3/450 | 78650 | 78490 | 78430 | 78660 | 78980 |
| Microsoft Internet Explorer 5, Windows 98, P3/450 | 80310 | 80300 | 80300 | 80520 | 80350 |
| Mozilla Milestone 10, Windows 98, P3/450 | 83000 | 83000 | 83000 | ||
| Netscape Communicator 4.7, Windows 98, P2/350 | 82560 | 82550 | 82550 | ||
| Netscape Communicator 4.6, Mac G3/266 | 50097 | 49935 | 49945 | ||
| Microsoft Internet Explorer 4.5, Mac G3/266 | 32079 | 30513 | 30477 | ||
| Netscape Communicator 4.7, Windows NT, P3/400 | 15042 | 15061 | 15051 | ||
| Microsoft Internet Explorer 5, Windows NT, P3/400 | 15031 | 15022 | 15022 | ||
| Netscape Communicator 4.7, Linux 2.2.12, P3/400 | 9361 | 9376 | 9366 |
Before I list more results, lets do some quick math. From the for()-loop test we know that the browser spends less than 1ms moving the layer. Lets round that up to 1ms. We've also got a 1ms delay in the setTimeout()-call. Combine those two and you get 2ms. There are 1500 steps, so the whole test shouldn't take more than 3000ms, right? Maybe 4500ms or 6000ms on a really bad hair day.
That's not what's happening here at all though. No system comes even close to that, particularly not the Windows 98 system. It's the only system that doesn't perform at 25 frames per second or above. This is, of course, rather disappointing.
10ms delay
| Browser and system | Run #1 | Run #2 | Run #3 |
| Netscape Communicator 4.7, Windows 98, P3/450 | 82660 | 82440 | 82610 |
| Netscape Communicator 4.61, Windows 98, P3/450 | 82670 | 82390 | 82610 |
| Microsoft Internet Explorer 4 (Compatibility mode), Windows 98, P3/450 | 81460 | 80970 | 81180 |
| Microsoft Internet Explorer 5, Windows 98, P3/450 | 82330 | 82330 | 82390 |
| Netscape Communicator 4.61, Windows 98, P2/350 | 82610 | 82550 | 82550 |
| Netscape Communicator 4.6, Mac G3/266 | 49932 | 49892 | 49919 |
| Microsoft Internet Explorer 4.5, Mac G3/266 | 36787 | 36219 | 36264 |
| Netscape Communicator 4.7, Windows NT, P3/400 | 15052 | 15042 | 15052 |
| Microsoft Internet Explorer 5, Windows NT, P3/400 | 15042 | 15022 | 15022 |
| Netscape Communicator 4.7, Linux 2.2.12, P3/400 | 25037 | 25021 | 25021 |
Again do the quick math. Moving the layer takes 1ms. There's a 10ms delay. 11ms multiplied by 1500 steps should be 16500ms. The results aren't exactly what you'd expect.
40ms delay
| Browser and system | Run #1 | Run #2 | Run #3 |
| Netscape Communicator 4.7, Windows 98, P3/450 | 82720 | 82660 | 82660 |
| Netscape Communicator 4.61, Windows 98, P3/450 | 82610 | 82770 | 82670 |
| Microsoft Internet Explorer 4 (Compatibility mode), Windows 98, P3/450 | 82830 | 82610 | 82500 |
| Microsoft Internet Explorer 5, Windows 98, P3/450 | 82500 | 82490 | 82560 |
| Netscape Communicator 4.61, Windows 98, P2/350 | 82660 | 82660 | 82660 |
| Netscape Communicator 4.6, Mac G3/266 | 100005 | 99887 | 99882 |
| Microsoft Internet Explorer 4.5, Mac G3/266 | 81453 | 81529 | 81314 |
| Netscape Communicator 4.7, Windows NT, P3/400 | 60177 | 60177 | 60177 |
| Microsoft Internet Explorer 5, Windows NT, P3/400 | 60097 | 60086 | 60087 |
| Netscape Communicator 4.7, Linux 2.2.12, P3/400 | 75090 | 75083 | 75090 |
As you can see now, the performance varies greatly between platforms. Suddenly the Mac system spends as much or more time than the Windows system to run. The Linux computer also performs very differently from what you'd expect. Target time for this test is around 60000ms.
Comments
The first time I ran this test on the Windows 98, P3/450 computer I wasn't sure I believed what I saw. I had my delay setting at a low value, but it still refused to finish in less than 82 seconds. Swapping browsers so it ran in MSIE didn't help either. After going through my code a couple of times I optimized it slightly (removed some DOM lookups), but saw no positive impact on performance.
I then ran the same tests on my Mac, and immediately noticed that it performed a lot better. This gave me reason to believe that on other systems there would be enough performance available to do smooth animation with DHTML. When I ran the same test on Windows NT and Linux later I also saw that they performed well. Even though the performance under Windows 98 is appalling, it's the only system that doesn't perform as you want.
Let's do some math again, and calculate the actual delay when the script runs on Windows 98. As you see from the first test results the script finishes just around 80 seconds with 1ms delay. 80 seconds is 80,000ms. From before we know that there are 1500 steps around the canvas. Divide 80,000ms by 1500, and you'll get 53.33ms. At the other delay settings the end time is even greater. End result is that regardless of the delay setting the delay won't get below 53.3ms. That equals just around 18-19 frames per second. As I've mentioned earlier we need 25 or more frames per second to get smooth animation.
As we can see from the test result, the performance varies greatly from platform to platform when we change the delay settings. One of the arguments for not using the for()-loop is that we cannot control the speed of the script. Therefore we insert a timed delay using setTimeout() which in turn controls the speed. But, as we can see here, that isn't the case at all. The speed varies greatly between platforms, and it seems that the best setting is a low setting, which on the fastest platforms means greater speed. In other words, we're back to square one.
JavaScript doesn't have only setTimeout() to control execution speed, there's also setInterval(). Naturally I needed to test this too, so let's have a look at what setInterval() is, and how the test was done.
Produced by Morten Wang and
All Rights Reserved. Legal Notices.Created: Jan 03, 2000
Revised: Jan 03, 2000
URL: https://www.webreference.com/dhtml/column28/part-3.html
Find a programming school near you