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

Smooth animation using DHTML
summary and conclusions

In my opinion, the tests I've run have shown what thought I saw when my first DHTML animation ran: Users running Windows 95 or Windows 98 won't get a smooth animation. It'll be a bumpy ride, and it'll be slow. To compensate for the slow speed one can move the layer more pixels at a time. The animation will still be rough, but it'll appear to go faster. You can also have multiple setInterval() threads going and that increases speed (tip courtesy of Scott Porter) but there's still a limit to how much speed you'll be able to get and how smooth the animation will run. The key problem is that it's impossible to have totally accurate control over the animation.

What slightly surprised me is that the lack of performance under Windows 98 is consistent across browsers. Both MSIE versions, Netscape 4 and Mozilla Milestone 10 suffer with the same problems. Therefore I believe that the problem isn't in the browsers. The fact that an animation with no delay runs in just around 1 second proves that the browsers have no trouble moving a layer quickly enough. Instead it's the operating system that's the weak link in the chain.

Is developing DHTML animation any use at all?

I believe this is an important question that needs to be asked. According to StatMarket around 54-57% of Web users run Windows 98, and 32-33% run Windows 95. TheCounter.com rates Windows 98 at 53% and Windows 95 at 33%. These stats may or may not actually reflect the operating systems used by your visitors, but it should give a rough idea of how high usage these two OSes have. Total the numbers up and you get around 86%.

Regardless of the actual number for your site, there are a lot of users with Windows 95 or 98. This, in turn, means that a lot of users won't get the DHTML animation you want them to. In my opinion the best solution is to adapt yourself to this worst-case scenario, and develop something that runs fairly well under Windows 95/98. If you set the delay in your animation to around 30-35ms the speed won't be too fast for those on other platforms.

DHTML developer system setup

I've thought about this for a while; what kind of system should a DHTML developer use to create the best work?

In my opinion the developer should run Windows 95 or Windows 98. Not because I'm a sadist, after all I run Windows 98 myself (although one could argue I'm slightly masochistic doing so). Instead, running such a system would make him/her have to push the system to the limit trying to find ways to increase the performance. Take a look at Scott Porter's code and you should be able to find a dozen or so tricks. It is possible to increase performance, it's just not the easiest task in the world.

If the developer can run more than one operating system there's quite a few to choose from though. I'd like to have a Linux/Xfree system since the performance on the setInterval() animation test does give good hopes. It's definitively something I'll be looking into, trying to find out if the performance with several threads running is just as good. If you didn't have a reason for trying out Linux you've got one now.

Having access to a Mac would be nice. There's always some differences between systems, so for quality assurance it would be nice. For performance regarding DHTML the Linux solution seems to be better, but if the option is a Mac or nothing at all it's easy to choose. Running Windows NT would in my opinion be a substitute for running Windows 98. The performance is better so it might not keep you on your toes, but it's absolutely usable. The main reason for running Windows NT is that you have the same fonts and screen setup as Windows 98/95, so you know what your documents will look like to users with those OSes.

Solutions other than DHTML

Maybe the best thing is to move on to other solutions? MacroMedia's Shockwave/Flash could be used. I also thought that Microsoft's "DirectAnimation" (DA) would be usable, until Jim Ley sent over his DA test. You can have a look at the test four yourself in the test section. When I ran the test on my P3/450 it performed just as badly as the other tests. The test calls the same stepLayer() function that the other tests do, but uses DirectAnimation to perform the calls.

If you drop by Microsoft's DirectAnimation site and look at the samples you'll see complicated animation done quickly and nicely. The DA runs in an object though, so it's sort of like a plug-in. As Jim Ley's test shows you can use DirectAnimation to control HTML elements, but since you can't increase the speed there's no use.

You may have seen really good Shockwave/Flash sites, and they are full of smooth animation with nice graphics. I do however feel that neither Shockwave/Flash nor DirectAnimation is any solution I'd actually like to use. Shockwave/Flash is a proprietary product, and you need a plugin to get it to run. The plugin occupies a certain amount of space in the browser window, space which cannot be used by other elements. DHTML on the other hand interacts with regular HTML elements and makes it easy to have overlapping content if need be. Also, you can't get the plugin for all platforms (but they're working on it), so it's not a cross-platform solution. Microsoft's DirectAnimation is only available in MSIE v4 and v5, meaning you lock yourself to one specific browser/vendor. MSIE isn't available for all platforms so again it's not a cross-platform solution (and obviously it's not a cross-browser solution).

I believe that DHTML is a better way of doing things. First of all the content of DHTML is still regular HTML. You don't need to buy software for development, nor teach yourself another language/platform. Secondly, it's available in more than one browser and across several platforms. You don't lock your solution to one vendor or only a few platforms. Lastly, with the creation of the Document Object Model and ECMAScript one can do DHTML using only openly available standards (HTML, CSS, DOM & ECMAScript) which hopefully ensures cross-platform cross-browser solutions.

I believe in the availability of cross-platform cross-browser solutions, mostly because it enables the visitor to choose what he/she likes best. In a way you can say I'm "pro choice." I want my content to be available to the highest number of people, and if I use DHTML I want it to work for as many as possible. That's why I spend time creating cross-browser DHTML library functions so I can easily write scripts. The test results I've found here therefore saddens me, since they tell me that if I choose to do DHTML animation most of my visitors won't see the animation the way it was intended.

The future of DHTML animation

No one knows what the future holds when it comes to DHTML. These tests I've run have told me that trying to develop a large DHTML application is maybe rather pointless right now, since so many users won't see the full-featured result. Therefore it's probably better to do it with Shockwave/Flash, or maybe some other solution. The downside of this in my opinion is that it doesn't focus on the problem area (that either the OS or the browser needs something better), but instead circumvents it. My hope would of course be that Netscape or Microsoft (or someone else) come up with a solution to the problem, making browsers able to get delays well below 40ms under Windows 95/98. That would leave the door open to developers and the result would probably be more usage of large DHTML applications.

While we wait (which may be a long time) DHTML animation is probably best for transitional effects. Small menus that drop down, wipe effects, and other animations with a small duration should be easy to do and work fairly well on all platforms. They're an easy way of making the site more interactive and responsive to user input, while not needing a huge amount of code and testing.

Maybe the future lies in places other than Windows 95/98. There are palmtop PCs (Palm, Visor, etc), set-top boxes, kitchen appliances with browser capabilities are coming, the list is long. With such a large amount of user agents DHTML might be impossible to get to work so focus will naturally end up on other solutions. Hopefully (for me) it won't go that way, and we'll instead see most user agents capable of doing DHTML and do it well, which in turn means that we can develop nice solutions for our visitors.

All the test described in this article are available on the next page.

Produced by Morten Wang and

URL: https://www.webreference.com/dhtml/column28/part-6.html