In a previous newsletter, I described ways to improve drawing performance by avoiding synchronous calls. In Developer Release 8 of the BeOS™, we implement our own advice with BView's new DrawBitmapAsync() function.

As the name implies, DrawBitmapAsync() issues an order to draw (it sends the request to the app server) and then immediately returns—it doesn't wait for the drawing to finish the way the regular DrawBitmap() function does. The advantage of the asynchronous call is obvious: Your thread can do something useful instead of waiting around for the server to get done. However, with the advantage comes a responsibility: After calling DrawBitmapSync(), you have to make sure that the drawing is completed before you modify or delete the bitmap.

How can you do that?

The most obvious way would be to (explicitly) call BView's Sync() function after calling DrawBitmapAsync(). This approach only makes sense, of course, if you perform some other operations between the draw and the sync—otherwise you lose your no-waiting advantage. In other words, calling Sync() immediately after calling DrawBitmapAsync() is essentially the same as calling DrawBitmap()—which is exactly what we're trying to avoid.

One situation in which Sync() can be of use is if you want to draw a number of bitmaps. You call DrawBitmapAsync() for each bitmap placement, and THEN you call Sync():

/* Issue some drawing commands. */
DrawBitmapAsync(bmapA, BPoint(0,0));
DrawBitmapAsync(bmapB, BPoint(50,0));
DrawBitmapAsync(bmapC, BPoint(100,0));
DrawBitmapAsync(bmapB, BPoint(150,0));

/* Now wait for ALL of them to complete... */
Sync();

/* ...before changing one of the bitmaps and redrawing. */
ChangeBitmap(bmapA):
DrawBitmapAsync(bmapA, BPoint(200,0));

How much faster is the asynchronous method? It depends on the size of the bitmap. For small, icon-sized bitmaps, you'll find that your bitmap drawing can be as much as 4 times faster! The Minesweeper application makes good use of asynchronous drawing; so does the Browser (which plays a fun game of knowing which bitmap has been drawn out of its icon cache).

One last thing...

I've noticed that many applications make heavy use of the Bounds() call. I ran some benchmarks on my 66 MHz machine that show how expensive that kind of synchronous request can be: A single, round-trip ticket to Bounds() costs 480 microseconds, whereas a single, asynchronous gallop through MovePenTo() costs only 12 microseconds!

The moral: If you know that the bounds haven't changed, don't call Bounds().

One more last thing...

If you know that your application's window and view code is carefully Lock()'ed and thoroughly re-entrant, try disabling the window discipline (through window->Discipline(FALSE)). For simple operations, you might see a 50 percent speedup. As an example, calling SetHighColor() with discipline enabled takes 19 microseconds; it's only 10 microseconds with the discipline turned off.

And if you REALLY want to fly:

I've never seen a cop on the stretch of Interstate 280 between Alpine Road and Page Mill after 2 AM. Disable your discipline and don't call Bounds().

Deep in the bowels of San Francisco (City Motto: Parking? Who needs parking?) sulks a less fashionable block of Multimedia Gulch where the MSNBC/ZDTV studio makes its home. There, on August 7, 1996, I made a public appearance on behalf of Be, Inc.

The timing of the request for an on-camera demo was interesting: Be had just announced the demonstration of the BeOS on PowerMac hardware, so suddenly a story about Be, the BeOS, and the BeBox was an urgent topical news priority. ...Yes, it has to happen TOMORROW... Yes, we know that all of the company principals are at Macworld in Boston... Yes, we know that Macworld is a big event, but no, we didn't send a crew there. Yes, we still want something for tonight, and no, next week when everyone is back won't do... Because by then the emergence of a new OS and hardware platform just won't be news.

Sigh.

So, the next morning I drove off to the city with a BeBox and a full demo kit of speakers, a MIDI synthesizer, 17" monitor, keyboard, mouse, cables, power strips... all scrounged from home because the Be demo kits were busy 3000 miles away in Boston (City Motto: Parking? Try San Francisco).

I arrived to find the studio well-appointed with sound systems, and monitors, and curious three-legged tables. So most of the stuff I brought wasn't really needed anyway. After several layers of pancake to cover the sweat of jogging three blocks from the nearest open parking spot (oh never mind, I've beat that joke into the ground), the ZDTV talking head and I talked about the demo:

Me: We've got symmetric multiprocessing... virtual memory...protected memory...C++...the GeekPort™...

T. Head: Umm, what we're looking for is something a bit less technical...

Me: Oh. OK. Something my mother might understand, right?

T. Head: Exactly! That's it.

Me: (Sigh.)

We wrapped the demo in two continuous takes, using ultra- hip, low-altitude, hand-held camera angles, over-the- shoulder boom shots, and cock-eyed, off-center roving pans. They did a fine job of intercutting the two takes, leaving in the really important points, while leaving out some flawed (yet colorful) metaphors.

The distortions of analog video distribution mercifully softened the picture like an episode of Moonlighting, so my recently acquired gray hairs weren't that evident. But not even 10 mm of Vaseline smeared on the lens could have covered up the look I gave the talking head after a severely misguided opening question. It's a look I usually reserve for computer salespeople who make uninformed claims that imply that _this_ product is _not_ bound by the same laws of physics as the rest of the universe.

Overall, I think it was a very positive exposure for Be, and it was, for me, a great experience.

Other thoughts:

As you all know, Be has achieved a level of newsworthiness due the announcement of the PowerMac port. As the hardware guy at Be, there was some parental sadness at seeing our OS take its first steps outside the hardware home I've made for it, but that feeling is overcome by parental pride in the potential this child has shown. Be assured there will always be a place at home for the BeOS, but I'm afraid that I won't promise that I will keep your room just the way you left it.

DR8 is out, and so is the new and improved CodeWarrior IDE. A lot of things changed about the way you build Be applications, and although we tried to document all the needed changes, there are still some questions that we see over and over again. To try and calm the flood, here's a DR8/BeIDE FAQ:

You may wish to do the settings changes mentioned above not only for each of your projects, but for the "New Projects" target as well, so your defaults for new projects are correct.

Following these easy steps will ensure that your transition from DR7 to DR8 is as effortless as possible. Of course, you still have to update all those places in the API that changed, but we can't help you there.

Good luck!

My web page, which is unlikely to appeal to anyone but me for a while: http://www.nwlink.com/~jrashmun

After fourteen years at Industrial Systems, Inc. (now part of the Manufacturing Systems Division of Aspen Tech), I took a year-long leave of absence, bought a Macintosh, began surfing the Internet, looked up CodeWarrior (on John Norstad's recommendation), and thereby discovered the existence of Be. Now I work (almost) full time getting to know the BeOS, and developing a CORBA-style Object Request Broker (ORB) implementation.

My favorite computer had been my Amiga 1000. I always regretted that I couldn't afford to spend what it would have required to be a full-time Amiga developer. The BeBox gives me a second chance at designing software for a platform that supports the type of development that I find gratifying: I like working on the layers of software that help higher- level applications get their job done. In the two years before my leave, I developed a multithreaded server in C++ on UNIX—and enjoyed every moment of it. I love making some little thing work, and then using it to make some bigger thing work. I love anticipating unexpected uses, so that when someone says, "It's great... but could you please make it do <XXX> next time?" I can say, "It's already in there!"

The BeBox is the right platform at the right time. It's fun because it uses some of the best software ideas in the industry, but isn't burdened by not-so-good subsystems. Of course, it's not perfect: The OS needs to have a few more things implemented, and the BeBox crashes fairly often. Also, it's hard to get the attention of Be's developer support -- although it's always rewarding when they do respond. Please, Be, hire more developer support people. And, while we're at it, make the bug list available for review.

I plan to produce an implementation of the C++ mapping for CORBA by the end of January, 1997, and add support for other languages as they become available. For distribution, I plan to make the product available on a web site as Kagi shareware.

I have a such a license plate in my office. But before I go any further, a few words of apology.

First, to our readers whose mother tongue isn't English. I used the expression "church key" at the end of my last column and received e-mail from overseas readers wondering about the meaning and origin of the trope. Of course, as a late and not completely debugged English speaker, I find the metaphor pregnant. Just picture one of these large, old, ornate wrought iron keys. It's the end of the day, hear the hiss when the church beadle takes the key to the beer bottle...

Second, I'd like to apologize to developers who have suffered while we switched ISPs and installed a T1 line to support the growing traffic on our web and ftp servers. This happened at the time when we experienced increased activity as a result of the PowerMac port demonstrated at Macworld. By now, we're on our way to catching up with our backlog and I'd like to express my appreciation to those who contacted me to express their concern, thus giving me an opportunity to look into the problem and monitor corrective actions.

Now, to the Amiga. A recent MSNBC broadcast showed the AMIGA96 license plate given to me by European developers. Some viewers were curious. What did the license plate mean? This is probably a good opportunity to acknowledge our spiritual affiliation with the Amiga. In many respects, it guided our thinking and efforts as we formed the company and developed our product. In the first place, the Amiga provided an existence proof. As the millions of Amigas sold attested, you did not have to be compatible with the Mac or Windows to create a platform and to attract developers and customers all over the world. With its cousin the Atari ST, the Amiga proved the existence of an A/V market. The Video Toaster became the tractor for the Amiga in multimedia content creation.

I was at Apple in 1986 when David Needle and his colleagues introduced the Amiga, soon acquired by Commodore. We were concerned. We didn't have a 68020 machine yet, and we didn't have multitasking or any of the audio, video, graphics, and animation features offered by the Amiga. By the end of 1988, Bob Kottick and Howard Marks, both Commodore developers, approached me. Howard had been an intern at Apple France. Investors wanted to buy Commodore from Irving Gould, its chairman, an avid consumer of cigars and CEOs. Paul Rainwater, who, if memory serves, managed money for the Bass family, and Mort Meyerson, Ross Perot ex-number-two at EDS, showed up at my house in Portola Valley.

Allan Loren, one of my colleagues at Apple, once told me that Ross Perot had chided him at a job interview for wearing loafers, very proper ones perhaps, "but at EDS we wear proper shoes with shoelaces, you understand?" I thought Allan was exaggerating a little. I asked Mort about his very elegant loafers. He didn't miss a beat and replied, “I don't work for Ross anymore.” These well-heeled investors wanted a CEO for their acquisition. In the end it went nowhere, Irwin wouldn't sell. Perhaps he remembered my name, though. When I left Apple, he tried to convince me to run Commodore's R&D. I, in turn, tried to convince him to let me run the company for 2 or 3 years and to compensate me with 20 percent of the increase in valuation, no salary. That conversation didn't go anywhere either, but my interest was piqued and, with Steve Sakoman, we started a company with one goal: Make a 1990s Amiga. We don't know yet if we've succeeded, but we're happy to acknowledge our debt to a product that continues to inspire us in many ways.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail. To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.