I was reminded the other day of a programming technique I first encountered in the early nineties (yep – that’s twenty years ago. How scary is that?). The technique was used in programming animations with java applets, and it involved constructing each frame of the animation off-screen before drawing it on-screen. This simple technique eliminated an irritating flicker that plagued many applet animations. Now this technique is commonly used in graphics applications, but is not very useful for website programming, because javascript is just too slow, and javascript doesn’t require us to actually draw on a canvas, but rather manipulate items in an object model, which the browser then draws on the canvas (probably using the off-screen preparation technique to eliminate flicker).
Java Applets
The poor java applet has pretty much been relegated to history. It burst on the internet scene with such promise, but when Flash came into being, Java applets were pretty much dropped. The applet had much more versatility, if you knew the java programming language well, but Flash allowed their developers to do most of the common, cool stuff, like animation, using a simply GUI interface. Which just goes to show how important usability is. Java is still alive and well – it is used in more advanced financial and technical systems, and a number of mobile phones, DVD players and other electronic devices run on Java programming. The Java applet, however, has been pretty much lost to us. I don’t think I’ve seen one this century.
But nostalgia aside, my trip down memory lane has in turn reminded me of two techniques we definitely do use in web programming today:
Animation Preparation
We no longer need to build each frame before we display it, but JavaScript animation is extremely slow, when compared to ordinary programs, because it needs to run through the browser, which adds a whole extra layer of processing. It is therefore extremely important to prepare the animation before it begins. Instead of calculating at each step where the step should go, for example, we prepare an array of pre-calculated values before the animation starts, then simply fetch the required values as each step processes. This may add a small delay before the animation starts, but will save each step that crucial few milliseconds that are the difference between a smooth and a jumpy animation.
Off-screen Measuring
One of the biggest problems we have with browsers, especially with Internet Explorer, is trying to measure how big a container needs to be to contain text or code. We often need to know this in order to create space for it. Unfortunately, we cannot find this information until we’ve added the text, which is often too late.
The solution is to create a measuring container off-screen, and add the text or code to that. The container is set positioned absolute, with a left position of something like -1600px. This value should be as small as possible, but should ensure that the container doesn’t ever encroach onto the visible screen. This is important, because the container must be displayed and visible, or the browser won’t calculate its actual size.
The off-screen container must be given exactly the same style attributes as the destination container, to ensure that the fonts and sizes will be the same. It must also be given the same sizing constraints as the destination container. So, for example, if we’re trying to calculate how high a caption block needs to be (a surprisingly common task these days), we set up an off-screen container with the same width and padding as the destination container, and apply all the same styles to it. We then add the text or code to that container, and get its offsetHeight property. This is the exact height we need to set our destination container (taking padding into account).
It may be necessary to perform the measurement asynchronously for Internet Explorer, but we’ll deal with that issue in a future post.
