DHTML Lab - dhtmlab.com - Smooth animation using DHTML | 6 | WebReference

DHTML Lab - dhtmlab.com - Smooth animation using DHTML | 6

Logo

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 systemRun  #1Run  #2Run  #3Run  #4Run  #5
Netscape Communicator 4.7, Windows NT, P3/400300301310301310
Microsoft Internet Explorer 5, Windows NT, P3/40010219411021  
Netscape Communicator 4.7, Linux 2.2.12, P3/400210215221  
Netscape Communicator 4.61, Windows 98, P2/350270280270  

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:

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 systemRun  #1Run  #2Run  #3Run  #4Run  #5
Netscape Communicator 4.7, Windows 98, P3/4508074080690808508074080790
Netscape Communicator 4.61, Windows 98, P3/4508074080850806308063080680
Microsoft Internet Explorer 4 (Compatibility mode), Windows 98, P3/4507865078490784307866078980
Microsoft Internet Explorer 5, Windows 98, P3/4508031080300803008052080350
Mozilla Milestone 10, Windows 98, P3/450830008300083000
Netscape Communicator 4.7, Windows 98, P2/350825608255082550
Netscape Communicator 4.6, Mac G3/266500974993549945
Microsoft Internet Explorer 4.5, Mac G3/266320793051330477
Netscape Communicator 4.7, Windows NT, P3/400150421506115051
Microsoft Internet Explorer 5, Windows NT, P3/400150311502215022
Netscape Communicator 4.7, Linux 2.2.12, P3/400936193769366

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 systemRun  #1Run  #2Run  #3
Netscape Communicator 4.7, Windows 98, P3/450826608244082610
Netscape Communicator 4.61, Windows 98, P3/450826708239082610
Microsoft Internet Explorer 4 (Compatibility mode), Windows 98, P3/450814608097081180
Microsoft Internet Explorer 5, Windows 98, P3/450823308233082390
Netscape Communicator 4.61, Windows 98, P2/350826108255082550
Netscape Communicator 4.6, Mac G3/266499324989249919
Microsoft Internet Explorer 4.5, Mac G3/266367873621936264
Netscape Communicator 4.7, Windows NT, P3/400150521504215052
Microsoft Internet Explorer 5, Windows NT, P3/400150421502215022
Netscape Communicator 4.7, Linux 2.2.12, P3/400250372502125021

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 systemRun  #1Run  #2Run  #3
Netscape Communicator 4.7, Windows 98, P3/450827208266082660
Netscape Communicator 4.61, Windows 98, P3/450826108277082670
Microsoft Internet Explorer 4 (Compatibility mode), Windows 98, P3/450828308261082500
Microsoft Internet Explorer 5, Windows 98, P3/450825008249082560
Netscape Communicator 4.61, Windows 98, P2/350826608266082660
Netscape Communicator 4.6, Mac G3/2661000059988799882
Microsoft Internet Explorer 4.5, Mac G3/266814538152981314
Netscape Communicator 4.7, Windows NT, P3/400601776017760177
Microsoft Internet Explorer 5, Windows NT, P3/400600976008660087
Netscape Communicator 4.7, Linux 2.2.12, P3/400750907508375090

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: http://www.webreference.com/dhtml/column28/part-3.html