abrash-black-book/46-01.md
2013-12-30 20:26:41 +11:00

85 lines
4.7 KiB
Markdown

Chapter 46\
Who Was that Masked Image? {#Heading1}
---------------------------
### Optimizing Dirty-Rectangle Animation {#Heading2}
Programming is, by and large, a linear process. One statement or
instruction follows another, in predictable sequences, with tiny
building blocks strung together to make thinking, which is, of course, A
Good Thing. Still, it's important to keep in mind that there's a large
chunk of the human mind that doesn't work in a linear fashion.
I've written elsewhere about the virtues of
nonlinear/right-brain/lateral/what-have-you thinking in solving tough
programming problems, such as debugging or optimization, but it bears
repeating. The mind can be an awesome pattern-matching and extrapolation
tool, if you let it. For example, the other day was grinding my way
through a particularly difficult bit of debugging. The code had been
written by someone else, and, to my mind, there's nothing worse than
debugging someone else's code; there's always the nasty feeling that you
don't quite know what's going on. The overall operation of this code
wouldn't come clear in my head, no matter how long stared at it, leaving
me with a rising sense of frustration and a determination not to quit
until got this bug.
In the midst of this, a coworker poked his head through the door and
told me he had something had to listen to. Reluctantly, went to his
office, whereupon he played a tape of what is surely one of the most
bizarre 911 calls in history. No doubt some of you have heard this tape,
which will briefly describe as involving a deer destroying the interior
of a car and biting a man in the neck. Perhaps you found it funny,
perhaps not—but as for me, it hit me exactly right. started laughing
helplessly, tears rolling down my face. When went back to
work—presto!—the pieces of the debugging puzzle had come together in my
head, and the work went quickly and easily.
Obviously, my mind needed a break from linear, left-brain, push-it-out
thinking, so it could do the sort of integrating work it does so
well—but that it's rarely willing to do under conscious control. It was
exactly this sort of thinking had in mind when titled my 1989
optimization book of *Zen of Assembly Language.* (Although must admit
that few people seem to have gotten the connection, and I've had to
field a lot of questions about whether I'm a Zen disciple. I'm
not—actually, I'm more of a Dave Barry disciple. If you don't know who
Dave Barry is, you should; he's good for your right brain.) Give your
mind a break once in a while, and I'll bet you'll find you're more
productive.
We're strange thinking machines, but we're the best ones yet invented,
and it's worth learning how to tap our full potential. And with that,
it's back to dirty-rectangle animation.
#### Dirty-Rectangle Animation, Continued {#Heading3}
In the last chapter, Introduced the idea of dirty-rectangle animation.
This technique is an alternative to page flipping that's capable of
producing animation of very high visual quality, without any help at all
from video hardware, and without the need for any extra, nondisplayed
video memory. This makes dirty-rectangle animation more widely usable
than page flipping, because many adapters don't support page flipping.
Dirty-rectangle animation also tends to be simpler to implement than
page flipping, because there's only one bitmap to keep track of. A final
advantage of dirty-rectangle animation is that it's potentially somewhat
faster than page flipping, because display-memory accesses can
theoretically be reduced to exactly one access for each pixel that
changes from one frame to the next.
The speed advantage of dirty-rectangle animation was entirely
theoretical in the previous chapter, because the implementation was
completely in C, and because no attempt was made to minimize display
memory accesses. The visual quality of Chapter 45's animation was also
less than ideal, for reasons we'll explore shortly. The code in Listings
46.1 and 46.2 addresses the shortcomings of Chapter 45's code.
Listing 46.2 implements the low-level drawing routines in assembly
language, which boosts performance a good deal. For maximum performance,
it would be worthwhile to convert more of Listing 46.1 into assembly, so
a call isn't required for each animated image, and overall performance
could be improved by streamlining the C code, but Listing 46.2 goes a
long way toward boosting animation speed. This program now supports
snappy animation of 15 images (as opposed to 10 for the software
presented in the last chapter), and the images are now two pixels wider.
That level of performance is all the more impressive considering that
for this chapter I've converted the code from using rectangular images
to using masked images.