|
Be Newsletter
Issue 43, October 2, 1996
Table of Contents
BE ENGINEERING INSIGHTS: Fast Pixel Animation
By Benoît Schillings
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 !
BE ENGINEERING INSIGHTS: BeWare, All Ye Who Check the Web Site
By Ron Theis
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(TM).
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(TM). (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.
BE DEVELOPER TALK: Chris Herborth, QNX Software Systems Ltd.
E-mail: chrish@qnx.com
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(TM). 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.
Who Should Develop on the BeOS?
By Jean-Louis Gassée
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.
|
