Speeding Up Frame Rates For DHTML Animation in Win98 - DHTML Lab | 7

Speeding Up Frame Rates For DHTML Animation in Win98
A Case Study

Multithreading In Different Rendering Contexts

IE performed well in the previous example, but as the number of animated elements increases, so does the jerkiness. I doubled and quadrupled the number of images, in my example, to four and eight and the bi-threaded techniques just didn't handle the movements as smoothly, possibly because the browser can't update that many images at 27 Hz but can at 18 Hz. With NN, animations degrade more quickly and do worse than IE in all these cases, single or double threaded. This is especially so with the bi-thread techniques which also nearly locked out the browser when four or more images are being moved.

Using setTimeout():  

Using setInterval():

Using Scaled Images

This next context looks at image scaling as a different type of increase in rendering complexity. The three images used in the previous animations could have originated as larger images, say 888 by 600 pixels for the Windows 98 background and 888 by 888 pixels for each of the moving NN and IE logos, which the browsers would then have to scale for display on the page. The two browsers handle this workload differently. The animation with two moving images will be used to illustrate what happens. 

In IE, using standard methods, the scaling causes the image within the positioned element box to wobble and element motion to degrade, but NN has no such problems and it's performance remains consistent with it's previous non-scaled examples. Runs in either the bi-threaded-speedup or using a two-pixel-increment have less apparent wobble than in the single threaded one-pixel-increment movements and could possibly be used as alternatives to help stabilize a wobbly IE animation.

This example may seem bit contrived and unrealistic but it's not. First of all, Web applications are scaled to viewer requirements. Office 2000's PowerPoint was designed to be Web-friendly, its files can be saved as DHTML and this involves scaling of image presentations. Secondly, the effects on animation in these scaling examples do not only occur in these cases, but are representative of many other types of real world situations which degrade IE's abilities when certain page complexities increase. In these same situations NN's performance remains fairly constant. According to DHTML Lab's editor, Peter Belesis, in applications that he works on at his company, "the Netscape version has about 4000 layers on one page, with no degradation in performance. IE degrades with 50, so I have had to break up the page and use workarounds. NS DHTML was created for animations. IE DHTML is more suited for intranet data management and component development. IE's animation performance on the Macintosh is better than on Windows, but we will probably see Windows improvements with IE5.5+ and the finalization of the HTML+TIME specification." [12]

Forgetting any multithreading for the moment, and looking just at the different DOM's of these two browsers will give reasons for their varying performance in different contexts. When IE re-renders, it does this to the entire page but NN does not need to. To have the ability to modify any element in the page, IE's very fast rendering engine re-calculates the entire page every time a change is made. In the image resize example, IE re-renders the entire page with every image movement, rescales all images including those that have already been scaled. This extra workload shows up as wobble. NN has a simpler DOM with a "layered" architecture, modifications cannot be made to any element, but elements can be positioned outside the normal flow of the page. NN doesn't need to re-calculate the entire page to move an independent layer and it happens to be the case that image resize occurs only once outside of layer movement. During layer movement, NN isn't burdened with extra tasks like IE and movement quality remains more consistent.

Now in the previous situation, no scaling was required with any of the images and any extra work occurred only as more and more images were added to the movement. The tasking conditions were essentially the same and the increases in complexity were essentially the same on both browsers. They only had to move more and more images around and IE just happened to perform this a little better.

These examples illustrate not only faster animations with bi-threading but also some smoothing with these techniques in different contexts as well. Unfortunately, this doesn't hold as rendering complexity increases. In investigating for further benefits to multithreading one could extend these bi-threaded speedups by simply creating more threads. To make elements move faster, and being aware of the possible limitations on the software system and display hardware, I began by only using three threads with my simplest two moving images example. This did speed up the animations but all the runs were quite jerky on IE and very erratic on NN and therefore there was no apparent reason to explore further. 

The factors looked at here that affect the smoothness of animations are specific to problems with either the degree of threading, the browser used or the complexities of the web page. Mainly the Windows 98 operating system and to some extent the JavaScript engine present the more fundamental problems to smooth DHTML animations.

Produced by Mark Szlazak and

All Rights Reserved. Legal Notices.
Created: July 11, 2000
Revised: July 11, 2000

URL: https://www.webreference.com/dhtml/column34/7.html