Two weeks ago, a question was posted (to comp.sys.be) asking about the proper way to animate a large number of pixels inside a window. It seems that FillRect() isn't as fast as the application writer wants.

You ask for it—you get it; I figured it might be fun to spend a Sunday evening looking at ways to draw quixels pickly. I took my favorite guinea pig program—HelloWorld—and changed the Draw() function to benchmark different techniques.

First I tried FillRect(). The code looks something like this:

void HelloView::Draw(BRect)
{
  double  start;
  double  end;
  long  i;
  BRect r;

  r.Set(10,10,10,10);

  start = system_time();

  for (i = 0; i < 10000; i++) {
    FillRect(r);
  }

  Flush();
  end = system_time();
  printf("t = %f\n", (end-start)/10000.0);
}

On my beloved 66 MHz BeBox, a single FillRect() takes about 75 microseconds. At 15 frames per second, you would be able to animate an area of about 888 pixels (isn't BC a great toy...). Not too bad, but how much faster can we go?

Next test was to use MovePenTo() and StrokeLine(). I changed the loop to look like this:

for (i = 0; i < 10000; i++) {
  MovePenTo(BPoint(10,10));
  StrokeLine(BPoint(10,10));
}

This time, 73 microseconds. 2.666% better than FillRect(). My jaw it was undropped. Perhaps we're getting into the overhead of the general protocol? Disabling the window discipline decreased the overhead somewhat —down to 66 microseconds. We're headed in the right direction, but...

Let's try something that naturally has a much faster protocol: LineArray(). Now the function looks like this:

void HelloView::Draw(BRect)
{
  double start;
  double  end;
  long i,j;
  rgb_color  c;

  c.red = 0;
  c.green = 0;
  c.blue = 0;

  start = system_time();

  for (i = 0; i < 10000/32; i++) {
    BeginLineArray(32);
    for (j = 0; j < 32; j++) {
      AddLine(BPoint(10,10), BPoint(10,10),c);
      EndLineArray();
    }
  }
  Flush();
  end = system_time();
  printf("t = %f\n", (end-start)/10000.0);
}

16 microseconds per pixel! Disable discipline and we get down to 11 microseconds. That's an area of 4100 pixels at 15 frames per second.

Can we do even better? Yes—but not without cheating. Try this:

void HelloView::Draw(BRect)
{
  double  start;
  double  end;
  long  i;
  BRect  r;
  BBitmap  *b;
  rgb_color  c;
  long  x;
  long  y;
  char  *p;

  r.Set(0,0,255,255);
  b = new BBitmap(r, B_COLOR_8_BIT);

  start = system_time();

  x = 10;
  y = 10;

  for (i = 0; i < 10000; i++) {
    p = (char *)b->Bits() + b->BytesPerRow()*y + x;
    *p = 20;
  }
  DrawBitmap(b, BPoint(0,0));
  end = system_time();
  delete b;

  printf("t = %f\n", (end-start)/10000.0);
}

Since we're simply blitting a bitmap, this isn't a general solution. But it is fast—0.82 usec per pixel, enough to animate 81300 pixels at 15 fps. Of course, the bitmap that we're creating in the loop is, shall we say, restrained: We really are just poking the same pixel over and over. But the point of this experiment is to get a feel for our absolute best time. The key to approaching this time is to keep the pixel position computation at a minimum.

A few weeks ago, I wrote about the enhanced performance of DrawBitmapAsync() (vs DrawBitmap()). In the example above, we only draw once, so DrawBitmapAsync() doesn't really apply. But what happens if we put the draw call into the loop? First we try DrawBitmap():

void HelloView::Draw(BRect)
{
  double  start;
  double  end;
  long  i;
  BRect  r;
  BBitmap  *b;

  r.Set(0,0,7,7);
  b = new BBitmap(r, B_COLOR_8_BIT);

  start = system_time();

  for (i = 0; i < 10000; i++) {
    DrawBitmap(b, BPoint(10,10));
  }
  Sync();
  end = system_time();
  delete b;
  printf("t = %f\n", (end-start)/10000.0);
}

This produces a horrendous 875 usec per bitmap! That's the price you pay for synchronous operations and context switches! By using DrawBitmapAsync() instead of DrawBitmap(), we get down to 160 usec per bitmap. That's fast enough to draw 416 little icons at 15 fps.

Of course, you can always mix the two techniques: Try using custom code to (repeatedly) blit a small bitmap into a bigger bitmap. When it comes to animation, nothing will beat a clean custom piece of code.

By the way, I did a quick test on a 133 MHz BeBox. In most cases the performance is close to 3x better... J'aime ces caches L1 !

The crowd followed the leader's every movement, banging their sticks in zombie-like unison. Thousands of sticks, hollow and of different lengths, produced a pseudo-musical sound that pulsed a communal heartbeat. The followers were rapt, staring at the stage as their leader jumped and shouted commands left and right.

I was witnessing a company picnic. And it wasn't Be's.

"Am I safe?" I shouted to my roommate as we entered the throng at Shoreline Amphitheater.

"Sure, just stay close to me!" He shouted in reply. "And don't make any sudden movements!"

My roommate had coaxed me into coming to his company's picnic by assuring me that the music, food, people, and lip sync competition would be "a ton of fun." He hadn't mentioned mass hypnosis and ritual sacrifice.

After the banging, during which the leader shouted group hug mottos about "adapting to change" and "meeting new challenges," they did indeed have a lip sync competition. The competition included a distressingly large number of male engineers duped into sliding on nylons and into drag queen acts. Don't get me wrong; I had a fine time during the show, but I was glad I wouldn't be going to work with these folks on Monday.

Still, I couldn't help wonder whether Be would evolve into this sort of monstrosity. Will Be become a zillion-dollar company with representatives in every country on the planet and division acronyms that are totally unrecognizable to the engineering staff? Will Be wheel out a gray-haired Erich Ringewald to judge lip sync competitions? I had a hard time imagining Steve Horowitz up on stage at Shoreline, giving the Mother of All Demos to a thousands-strong mass of employees and leading them in chants of "The System is Still Responsive! The System is Still Responsive!"

Right now, Be could barely fill the first row of Shoreline. The company is small, and I love it. I know everybody in the company. I get to respond to Webmaster e-mail personally (webmaster@be.com), and make the web site seem a little more human. Being the Webmaster, I also get excited about Be's potential for using the web. Every time I read one of Jean- Louis' future-of-the-web articles, I get pumped up. Before coming to work for Be, I figured they'd always just send it to their "Internet Division" or something. But now, the "Internet Division" is me. Gulp.

The web site has made some great strides recently, namely the new look, designed by Mark Gonzales, which coincided with the MacWorld announcements. But even more improvements are in the works. On my whiteboard there's a list of planned web site improvements as long as my arm, waiting to be tackled. On-line ordering is up and running, but the capability to do secure transactions still needs to be added. Developers have a Registered Developer Area of the web site, which requires a password to enter, allowing us to distribute information in a more targeted manner.

In the Registered Developer Area, developers can now modify the contact information we keep for them on-line. They can keep us up to date about their latest projects. And soon, they'll be able to add their own projects to BeWare™. Personally, I'm excited about this. It will give all developers an opportunity to alert end users (as well as other developers) to the presence of their applications. Freeware, shareware, and commercial applications can sit alongside each other, with web, ftp, and e-mail links guiding the web surfer.

I think the BeWare section of the web site has a lot of potential. At NASA, I used to use a graphing program for the Mac called "Igor Pro" (by Wavemetrics). It had a novel way of displaying data (as "waves"), was extremely powerful, and you could even script it. It was great—and I never would have heard of it had one of my co-workers not sworn by it as the best graphing program he'd ever seen. After all, how do applications usually gain notoriety? Magazine reviews, software catalogs, and word of mouth, apparently. And those are only commercial applications -- shareware applications are doomed to skulk in the shadows, hoping that enough users tell their friends, in a "chain letter" approach to advertising.

BeWare should help change that: One-stop shopping for freeware, shareware, and commercial Be applications. And searchable, too. I can't wait to be able to run a search on "Game" and "3D" in order to check out the latest 3D games for the BeOS™. (For testing purposes only, of course.)

We have more improvements for the web site in the works: A better search engine, a Reseller Area styled after the ID & Password Registered Developer Area, searchable archives of BeDevTalk posts, a number of list-server upgrades, better ftp site integration with the web site, and on-line mailing list subscription capabilities. Over time, these functions will be integrated.

The Internet Division is hard at work on it.

I've been writing software since 1985, when I got my Commodore 64. I replaced it with an Atari 1040ST in 1986; it was over ten years old when I finally put it in storage—it had to go to make room for my BeBox.

By day, I'm an R&D technical writer for QNX Software Systems Ltd. (http://www.qnx.com/), a small, privately owned high- tech company in Kanata, Ontario, who develops QNX, the leading real-time OS for PCs. Working for QNX is great. In addition to writing, I get to make use of my hacker talents. I implemented our SGML documentation process and programmed all the support tools.

Day job aside, I've always had a goal in the back of my mind: To develop role-playing games based on a programmable engine that could (in theory) handle any game in any genre. I've got some pretty high-end demands for this thing: 32-bit alpha channel graphics (so you can see fish swimming in the stream); separate threads for every actor, as well as for the animation and audio; a built-in programming language for designing the game. To support these ideals, I need a system with some decent horsepower. And to feed my own desires, I need a system that's interesting, one that's not flooded with shovelware.

The BeBox announcement excited me the way the Amiga and Atari ST excited me in 1986. Fresh, new systems, uncharted territory, and a groovy feeling that accountants and lawyers would never use this box in their day jobs. A complete lack of software is annoying yet very exciting... the possibility of an incredible set of new applications is fantastic, since we're not burdened with bloated apps and the Microsoft monopoly. The fact that the BeOS supports everything in my wish-list of OS features (something no other OS has done) and that it was affordable to someone who's still paying for sending himself through university really caught my eye. A clean C++ API is a bonus (even though I prefer dynamically typed languages).

I'm currently developing my dream game engine on the BeBox; the working title is Arcana. To support the engine, I need to create other useful utilities, such as a graphics editor suited to working with small tiles stored in PNG format, and the Arcana WorldBuilder (a sort of BeIDE for creating computer role-playing games), and who knows what else along the way.

After I finish Arcana and the Arcana WorldBuilder, I'm going to start creating top-notch role-playing games. This will be done when it's done; I'm going to start updating my web pages (http://www.qnx.com/~chrish) soon, and will have a log of what's finished, what I'm working on, and what I plan on doing.

While I'm designing Arcana, I've got loads of other interesting ideas floating around in my head... games, utilities, applications, silly hacks, who knows what. I've already ported an EMACS-like editor (jove), Info-ZIP's archiving utilities (zip and unzip), and a bunch of other goodies. When I get a spare week or two, I'm planning on porting STonX, an Atari ST emulator for UNIX systems. These things get posted on my web pages and sent to ftp.be.com as I finish them.

One other very exciting thing that I'm working on is a port of id Software's DOOM. Yes folks, we'll have a nice version of DOOM (running in a window or running full-screen via the Game Kit—your choice). Progress on this isn't as fast as I'd like—I do have to go to work -- but it's coming along nicely. After the id guys check it out, I'll be unleashing a beta test version; it'll work with existing WAD files, do UDP networking, stereo sound, MIDI (maybe, if I can borrow a MIDI device of some sort), everything. If you want to speed things up, send me money so I can take time off work. Or a cloning machine to hook to the GeekPort™. But PLEASE don't e-mail me to ask about DOOM; check my web pages instead. I'll be posting development logs soon.

I also plan on doing a port of Dr. Cat's DragonSpires client. DragonSpires (http://www.eden.com/~cat/) is a graphical MUD on the Internet, featuring an Ultima-like display. And did I mention that I was writing a few Be programming tutorials? You should expect to see them in a new Be e-zine soon. But that's a secret. I'd love to write a book or two about programming the BeBox at some point, too.

Obviously, I'm pretty busy in my spare time.

Be's developer support has been top-notch. Much better than any other tech support group that I've ever dealt with (well, QNX's tech support people are great, but I usually don't deal with them). Of course, there's always room for improvement: Getting a searchable database of bug reports and feature requests up on their web pages would be a great start.

The documentation in "The Be Book" could be better. More example code for common uses (such as how to get all the file references out of BApplication's RefsReceived() argument) would be nice. The Be developer community helps a lot here. Posting a question to BeDevTalk is a great way to get answers. You can tell we love the system because of the number of religious wars that go on in BeDevTalk. Jake Hamby's experimental news server (at muppet.jpl.nasa.gov) is also good (and doesn't get so noisy).

In the newsletter, I'd like to see some information from the developers at Be about what they plan on implementing, sort of a "crystal ball" column. Even if it's full of "plans change" and "we might do it another way" and "we might never get around to this" comments, I'd still love to have some idea of where the BeOS is heading. It can be frustrating (and lead to a zillion feature requests) not knowing what'll be in the next OS revision until it actually ships.

This morning I met with a reporter. He asked me to respond to a statement by one of the people I admire in our industry, Tim Gill, the founder of Quark. With all the caveats about second-hand information well stipulated, Tim said something to the effect he wouldn't port Quark Xpress to the BeOS. Quark was more interested, and busy as hell, in moving their product forward on the Mac and Windows than in making a "lateral" move to an unproven platform such as Be's.

A very logical position, one that is shared by many of the established developers. They have a lot invested in their franchise, why would they risk it on a new platform?

I'm not sure I can give an unequivocal "Yes, you should" retort. Are we better off with new developers, unproven but unencumbered by their pasts —just like us? Or do we need the name, the marketing power, and the "code base" of a proven leader? There's no simple answer. Some companies have fared well in lateral moves, porting their product from Mac to Windows, or vice versa. Others have wasted their time—and their shareholders' resources. Sometimes the problem is the famous "code base." A successful product doesn't mean what went in the sausage was pristine. The port, even with the latest tools, can take a long time and perform poorly. Other times, the problem is management or marketing. The culture, the habits, the metrics of Mac and Windows users are more different than either group realizes, and the product or its marketing misses the mark. Excel works well across platforms, but even mighty Microsoft couldn't avoid a dud like the latest revision of Word on the Mac. I could mention other so-so examples, but I'd rather point out Photoshop as an example of a product successfully "lateraled" from the Macintosh to Windows and various flavors of UNIX, probably the result of the combined virtues of management and code base.

New developers have much in their favor. They tend to think more innovatively, and they will write fresh code targeted to our platform rather than attempt to "repurpose" their "code base." The difference in function and performance could be as striking as the one we see between the mature MacOS and the BeOS when they both run on the same hardware. And, on the BeOS, new developers, unlike established ones, do not have to fear alienating software distributors; therefore they can market and distribute their software on the web.

Does this mean we have no interest in proven, successful developers? Of course not. Some people even suggest I should go and sleep on John Warnock's doorstep until he decides to port Photoshop to the BeOS. We first have to complete our port of the BeOS on PowerMacs, thus ensuring a much larger installed base for BeOS applications. Then, we might have to provide tools that facilitate the adaptation of some, not all, well-designed applications to the BeOS. In this context, the opposite of well-designed are applications written in such a way that only a total rewrite will allow them to fully use the competitive features of the BeOS. In this case, a "straight" port will probably feel lame—not recommended.

When we have the migration tools and the PowerMac port on a CD, I'll give Tim Gill a call.