There are two ways to do animation on the BeBox: Animate directly to the screen or animate to an off-screen bitmap and render the results to the screen.

The "direct-to-screen" approach may seem easier at first, and may even be acceptable for rastered images, but for vectored images or images made up of multiple rastered images, it usually results in flickery animation.

The "off-screen" approach is easy to implement and results in very smooth animation, since the user only sees new frames when they're completed -- not the steps required to draw each new frame. Of course there's no free lunch: The off-screen approach does involve writing about 10 more lines of code and there's a memory requirement for each off-screen bitmap.

The purpose of this article is to show how easy it is to use the off-screen approach, using example code for creating a slider that's made up of two parts: A background and a knob. The example draws the background from scratch each time, since it's a simple object. The knob is a canned graphic that we've created elsewhere (see Steve Horowitz's excellent article in last week's newsletter, "Be Engineering Insights: craw, shex, and script: Excuse Me?").

(Of course we could draw the slider directly to the screen, but every time the knob moved, the user would see the background redraw over the knob and then see the knob drawn onto the new background—not very pretty.)

The first step is to create the on-screen view that we'll render into in the window that we've already created:

BRect r.Set(SLIDER_L,
            SLIDER_T,
            SLIDER_L + SLIDER_WIDTH,
            SLIDER_T + SLIDER_HEIGHT);

TSliderView slider_view = new TSliderView(r, "slider");
AddChild(slider_view);

Since we're using a canned graphic for the knob, we might as well create a bitmap for it in the constructor for TSliderView:

BRect r.Set(0, 0, KNOB_WIDTH, KNOB_HEIGHT);
unsigned char* knob = new BBitmap(r, B_COLOR_8_BIT);

knob->SetBits(slider_bits,
              knob->BitsLength(), 0,
              B_COLOR_8_BIT);

(If the original graphic is a 24-bit bitmap, replace B_COLOR_8_BIT with B_RGB_32_BIT.)

The next step is to create the off-screen bitmap that has the same dimensions as our on-screen view, and an off-screen view that we'll draw into:

r = Bounds();
unsigned char* offscreen = new BBitmap(r,
                                       B_COLOR_8_BIT,
                                       true);

BView offview = new BView(r,
                          "off",
                          B_FOLLOW_ALL,
                          B_WILL_DRAW);

offscreen->AddChild(offview);

Note: When you're creating a bitmap that you intend to attach a view to, the left and top values for the bounds must be 0.0.

That's it for creating an off-screen drawing environment. Now we need to draw into it. First we lock the view's parent to prevent anyone else from accessing it:

offscreen->Lock();

Next, start drawing:

r = offview->Bounds(); // get view's bounds
offview->SetHighColor(R, G, B); // set view's high color
// same as on screen
offview->FillRect(r); // fill bitmap with color

// draw the slider background...
offview->SetHighColor(0, 0, 0); // set pen to black
offview->StrokeLine(BPoint(x, y), BPoint(x1, y1));
.
.
.

// copy the knob
r.Set(knob_x,
knob_y,
knob_x + KNOB_WIDTH,
knob_y + KNOB_HEIGHT);
offview->DrawBitmap(knob, knob->Bounds(), r);

The last step is to render the result to the screen and unlock the view's parent:

offview->Sync(); // make sure rendering is done
DrawBitmap(offscreen, BPoint(0, 0));
offscreen->Unlock();

That's all there is to it. Of course, don't forget to delete the bitmaps that were created in the SliderView's destructor. Look for the full source example of this slider on our FTP site: ftp.be.com/pub/Samples/Slider.tar.Z (the file is also available in .zip and .sea.hqx formats).

Last week, Peter N. Lewis of Stairways Software Pty. Ltd. voyaged all the way to the U.S. from Perth, Australia, just to visit us at Be. Well, OK, so he also came to spend some time with our friends at Metrowerks in Texas, but we're pretty sure hitting up Jean-Louis for another BeBox was his real mission.

Peter N. Lewis may be a familiar name to many of you. A well-respected, long-time Macintosh developer, he's a thriving shareware and freeware developer with a long list of Internet applications to his credit. Among them: Anarchie, an FTP and Archie client, which you can use to browse FTP sites and upload and download files, and NetPresenz (previously called FTPd), which you can use to turn your system into an FTP, WWW, or Gopher server.

As a communications developer running up against the proverbial performance walls of traditional PC architectures, Lewis believes "The BeBox has a lot of potential for the future. It's a simple, clean system —something lots of developers would like to get back to. With its multiprocessor design, it's also Internet-capable and fast!"

The modern Be OS™ is also a big draw with its preemptive multitasking and memory protection. "I write mostly Macintosh communication programs, and not having preemptive multitasking is a real problem." In addition, one of the most attractive aspects from a technology adoption viewpoint is that "the framework is built right into the box, so you don't have to wait for the framework to catch up in order to take advantage of new capabilities."

As a shareware developer, Lewis admits that the BeBox isn't a financially viable platform for him yet. Typically, he finds that only 2 to 20 percent of shareware users take the time to send in shareware fees (he thinks "about the price of a paperback book"—or $10—is reasonable). This means a platform needs a large installed base before a shareware developer like him begins to see black on the bottom line. Even so, he believes in the BeBox's potential so much that he's already written a web server for it. And he's feeling "a little guilty" that he can't be doing more for the BeBox right now, as he embarks on a few-months break from his work in Australia.

"I hope the BeBox picks up enough users so that I can start to develop seriously for it. It's certainly a lot easier to program for than the Macintosh, despite using C++," he says. "And if we get some good languages on the BeBox, then it will be even more pleasant. I wonder how hard it would be to build a Java interpreter straight into the OS?"

Why would he recommend other developers consider the BeBox? "Because it gives you an opportunity to get in on the ground floor. Because it's much easier than developing for other machines. Because there's no competition. And because it's fun!"

"As a Macintosh developer, I've heard all the reasons why I should develop for the PC, but I'm still writing for the Macintosh."

And now, the BeBox.

For more information on Stairways Software Pty. Ltd.'s Internet solutions, visit their web site at: http://www.share.com/share/peterlewis/.

"All right," they say, "your OS offers some advantages, we'll concede that. But just you wait, the moment The Big Guys wake up and realize you have some interesting advantage, they'll unleash their immense technical and marketing resources. In no time, they'll catch up with you, meet or beat all your differentiating features. Add their marketing might and you'll be reduced to a footnote." Thank you, may we go quietly now?

Fortunately for all of us having one kind of stake or another in Be's future, it's not quite like that. On the contrary, even if it appears a little counter intuitive, we're more likely to increase our technical lead than to see our noble and worthy elders catch up with us. This, of course, makes all sorts of assumptions about us staying focused, vigilant, hungry, and mindful of our station in life. We have a lot to prove. With this cautious frame of mind, let's turn to life inside the sausage factories, to building system software. Call it entropy, call it politics, but any piece of software inevitably reflects the age, the mores, the size of the organization that built it. Your coefficients may vary, but the formula stays the same. And it will apply to us, eventually. For The Big Guys, large incremental projects need more and more time between major releases.

Even the best-run company in the business, Microsoft, needed about five years between Windows 3.0 and Windows 4.0 (as your hard disk knows it -- Windows 95 for us humans). Apple will need a similar amount of time to move from System 7 to System 8 (a/k/a Copland). For the previous iteration, the time interval was 2 to 3 years. The same phenomenon applied to major releases of mini and mainframe operating system software. After an exuberant youth, software settles down and the interval between major releases increases. Put another way, the more mature PC operating systems are entering a phase of diminishing returns, while we're still on the early, ascending part of the curve.

Invoking "Skunk Works" might sound both pretentious and overused. Still, Ben Rich's and Leo Janos' book (now in paperback at $14.95, unfortunately defaced by a Tom Clancy quote...) is a wonderful read—a rich source of inspiration and analogies. They offer good models when contemplating what a small, focused organization of engineering demigods can accomplish: The U-2, the SR-71, the Stealth fighter no less. They also offer sad models, such as when the immune system built by the founding father, Kelly Johnson, and carefully maintained by his successor, Ben Rich, was finally overwhelmed by the corporate and Pentagon lymphocytes. Warehouses filled with government paperwork for a single project.

Lesser mortals such as ourselves can still enjoy the advantages of a small organization, happily focused on a product in the early part of its life cycle—at a time when we can make bigger and faster strides than our elders. Our developer software release 1.1d7, shipping next month, will be a test of this statement.

Still, what about Windows catching up with the Macintosh? Doesn't this destroy our thesis? Au contraire, Microsoft was the smaller company in those days, while Apple was the big rich target. Admittedly, Microsoft enjoyed an unfair advantage: Stable management, the same leader for 20 years. This continuity is reflected in the product strategy: Continuous improvements from QDOS to Windows 95. Apple, on the other hand, had discontinuous leadership. This wasn't always bad. Jumping from the Apple II to the Macintosh, while unpopular with some, started what has become a $12 billion company. But today, Apple is in the uncomfortable position of playing the continuity game against the best player in the field.

Meanwhile, having sinned and learned in another life, we're committed to making the best of our discontinuity, of our lack of organizational and architectural past and baggage.