[ Be Logo ] [ Home ][ Site Map ][ Search ][ Contact ][ Be Europe ][ Developers Banner ]
About Be, Inc.Be ProductsThe World of BeDeveloper ServicesJobs @ Be[Bottom]

Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

|

  The BMessage
Issue 18    February 7, 2001

News

Be in the News

January 29, 2001
Be Rocks at CES 2001 Show, Byte.com

Be Press Releases

February 6, 2001
Be Inc. Licenses Beatnik Technology for Use in Its BeIA Client Platform

January 30, 2001
FOCUS Enhancements and Be Team to Incorporate TV-out Technology in BeIA

January 24, 2001
Be Incorporated Reports Fourth Quarter Results

January 23, 2001
Be Utilizes Bitstream Asian Font Technology in the BeIA Client Platform

return to top

JLG

The Web Device of Choice at Home
by Jean-Louis Gassée, CEO and Chairman

This is not exactly a new topic -- discussion of it began even before the Internet of researchers and students became the Web. Personal computers, with their protean capabilities, were used as tools to connect to sources of information, entertainment, and transactions. They were also important to building bulletin-board systems, BBS, and, now Web servers. As with any tool, though, the PC's general-purpose nature exacts penalties in cost, complexity, and reliability. This led to debate over generality vs. fitting a particular purpose.

In a way, the discussion of non-PC devices, started with Dr. Nicholas Negroponte's idea of digital convergence. That is, with a modicum of oversimplification, a) everything will be digital and, b) everything will converge in the TV set. "Everything digital" means information and entertainment will be digitized, packetized, and compressed; therefore, it will be storable and transportable. The TV set of the future was seen as sporting oodles of processing power and storage. Ergo, all forms of knowledge, art, commerce, and mud wrestling must converge towards the TV set in the family room.

We know what happened to that idea. Parts of it were and still are profoundly true. We haven't found a way to digitize wisdom, yet, but we see how "everything" has gone digital and how "everything" is on the Web. If not literally true, the previous statements make practical sense, they sound right, and they have practical consequences of a large magnitude.

As for the TV set, that part hasn't fared too well. Yes, we have interactive TV, WebTV, and set-top boxes. But none of that resonates in the way the first part, the "everything digital and on the Web" part does. The TV screen wasn't meant for things other than TV content, and we haven't found ways to make either one fit the other, because that's hard to do when Web content and the VGA screen, dimensions, resolution, and phosphors have such an intimate relationship. There's also the psychology of the TV set experience, what some call the lean-back vs. lean-forward state of mind. Others ask whether e-mail is meant to be read in the privacy of your family room.

More recently, the game console has been seen as the best candidate for on-line access in the home. I disagree -- for some of the same reasons that apply to the TV tube and Web content. But other technical factors are involved as well. Web content is a little too easy a phrase. The "everything digital" notion tempts one to think that everything can be easily translated back into a form humans can understand or experience. This is an easy thought, but a complicated reality. In fact, Web content takes many bizarre shapes and formats, and each requires a decoding engine -- Real, Flash, PDF, QuickTime, Windows Media, to name but very few. These exist for the most part in the x86 realm and would have to be rewritten and painfully optimized again for other processors in order to provide meaningful rendition of Web content. Come to think of it, this might be the reason why Microsoft chose an x86 processor for its very own "Pay Station," -- sorry, xBox. Even with their resources, rewriting or coercing others into rewriting these decoders for another processor wasn't an option.

That's why, for the time being, for our Home Audio Reference Platform, for wireless Web tablets, for the eVilla and similar devices, for a genuine Web experience on something nimbler and friendlier than a PC, we like the x86 architecture and the PC clone organ bank, software organs included.

return to top

The Be Line

Vision for the Future
By Lee M. Williams, Director, Product Development and Delivery

The secret to developing a successful electronics product is being at the right place at the right time. The goal is to hit that sweet spot between consumer demand and a lack of alternatives on the market. Manufacturers typically try to do this by being first to market with a technology or concept. This is not a guaranteed way to success, however.

The first to introduce a unique feature or function to the market is not always the company with the vision or foresight to know exactly how to leverage it. True, there's a window of opportunity where the attention given to a new technology -- and its availability -- can carve a foothold. And the chance that the product initiative might be a springboard to something larger and more lucrative helps. But with no vision of how to leverage innovative features, initiative alone might become a costly road to a failure.

This is what we may be seeing now in the IA space. There are companies that have already brought products called Internet Appliances to market. But do these firms have a vision of what the Internet is or can be, let alone an understanding of how a connected appliance can operate within the context of the medium? For example, some manufacturers promote the IA as just a tentacle of the PC -- or a dedicated way to distribute a "killer app."

Debate rages around the question of whether the PC market is already saturated. I have at least anecdotal evidence that it is -- based on talking to friends, family, and associates. We all know that there are a lot of PCs out there -- in businesses, homes, and many public venues. I'm also struck regularly, when using one of my many PCs, that they are primarily tools -- for writing, image editing, information browsing, video editing, communication, and so on.

It seems to me that possibilities for further PC saturation are limited. There's no need for PCs to morph in order to infiltrate areas of personal activity like gardening, cooking, or face-to-face conversation. While the PC will remain a valuable item in the toolbox of the digital and information age, it's unlikely to become an indispensable element of my clothing or dinnertime conversation at a restaurant.

What distinguishes an Internet Appliance is that it is first and foremost an Information Appliance. Just as money, for Adam Smith, was a medium of exchange, information, as broadcast and indexed by the Internet, is also a medium of exchange. Content, commerce, and communication are both the seeds and vehicles for exchanging one of the essentials of our everyday lives -- information. An appliance that makes the medium of the Internet ubiquitous -- and that we can use simultaneously while engaged in other activities -- is not the same as a personal computer. An appliance commands the immediate interaction of the user because its computing capability is seamless, pervasive, and hidden from the user interface.

Being first to market with a small device that connects to the Internet has so far fallen short of realizing the benefits of a successful product. Marketing a device that does no more than accentuate the power of the most capable PCs also looks like a dead end. Replicating the concept of a magazine or notepad and cramming it into a digital tablet is unlikely to be a big hit either. No, success in the IA space lies in a vision for the future that can be made real by tickling consumers' imaginations into realizing the true power of the Internet -- a medium more pervasive and capable than any previously known.

The demand for a device that offers innovative technology, proliferates information, and takes communication to new levels will be huge. When the device emerges that appears to be a harbinger of the future, it will create the kind of demand that is rarely seen. I believe the concept of an IA as a distributor of services, intellectual property, and content is beginning to take hold. Now throw in the use of an IA as a digital library for music, movies, and communications. Leverage the device's ability to connect these pieces in near real time, with little or no user interaction, and you begin to achieve something truly unique.

I said "begin to achieve" because it doesn't stop there. First, many other ingredients are needed to realize the benefits of a true change in product direction -- or market convergence. It's possible that new forms of entertainment will follow. It's likely that communication will be forever altered. Even the concept of what a digital tool or device is may change.

The company that realizes and accepts the task of undertaking this journey toward a future that is full of environments that leverage this unique product will be successful in this market. The company that looks to rest comfortably on conservative ideas of what innovation means or tries to grab this new opportunity by being first to market but last to understand the magnitude of this change will not succeed. An IA is a product that requires vision and the ability to execute against a long-term view with the tenacity, insight, and wherewithal of a relentless leader. Mark my words, it is this vision for the future that will drive and sustain success in the Internet Appliance space.

return to top

Engineering Insights

What is Bitflinger?
By R. Jason Sams, Software Engineer, Graphics

Recent builds of OpenGL include a small shared library called libbitflinger.so. Anyone who's written a program that must deal with multiple pixel formats knows what a pain it can be to write code that converts from one format to another. Bitflinger was created to provide this functionality in a shared library.

OpenGL 1.2 (Note: Be currently supports only 1.1) provides more than 900 combinations of in and out translations. Nobody (including me) wants to write optimized code for all of those, so we do the next best thing: write a code generator that generates optimized code for any specified in and out format. That's a good description of Bitflinger. It contains routines for setting up an input and output format and then generates the asm code to do the conversion.

For those interested in the code generation, see: http://www-classic.be.com/aboutbe/benewsletter/volume_III/Issue38.html#Insight

Bitflinger was originally written to deal with all the pixel formats supported by OpenGL 1.2, so the constants for defining input and output just happen to match those used by OpenGL. A quick example of converting a 32-bit RGBA image to 15-bit RGB is in order.

cvSetType( 
    context,          // The context created during initialization
    B_BIT_IN,         // We are setting the input format
    GL_UNSIGNED_BYTE, // 8Bits per component
    GL_RGBA,          // RGBA format
    0,                // Don’t need to reverse endian
    0 );              // Don’t need to swap bits in each byte.

cvSetType( 
    context,          // The context created during initialization
    B_BIT_OUT,        // We are setting the output format
    GL_UNSIGNED_SHORT_5_5_5, // 15 Bits packed into a 16bit short
    GL_RGBA,          // RGB format
    0,                // Don’t need to reverse endian
    0 );              // Don’t need to swap bits in each byte.

The above code sets up the translation. Once it is set you need to actually do the conversion.
cvConvert(
    context,          // The context created during initialization
    100, 100,         // Height and width
    0,                // Skip 0 pixels at the beginning of each source line
    0,                // Skip 0 lines at the top of the source image
    0,                // Use the default source line length (width*Bpp)
    source,           // The source data
    0,                // Skip 0 pixels at the beginning of each dest line
    0,                // Skip 0 lines at the top of the dest image
    0,                // Use the default dest line length (width*Bpp)
    dest );           // The destination data

The above code would convert a 100x100 32-bpp bitmap into a 100x100 15 bpp one. The extra values in cvConvert can be used to convert a partial bitmap by setting the source offsets and line length. The destination offsets can be used to insert a smaller bitmap into a larger one. It may not always be necessary or desirable to convert an entire bitmap at once. Another mechanism is provided for this. If, for example, you were writing a rendering package to support a wide range of texture formats but you wanted to use your own rendering engine, you could do the following:
cvSetType( context, B_BIT_IN, GL_UNSIGNED_SHORT_5_5_5, GL_RGB, 0, 0); 
cvSetType( context, B_BIT_OUT, GL_FLOAT, GL_RGB, 0, 0); 

myExtractor = cvPickExtractor( context, 
    100,              // The width of the source bitmap
    100,              // The height of the source bitmap
    0,                // Skip 0 pixels at the beginning of each source line
    0,                // Skip 0 lines at the top of the source image
    0);               // Use the default source line length (width*Bpp)
If this looks similar to the cvConvert function, it should: the majority of the fields are the same. The difference is that it doesn't take any destination information and doesn't process any pixels. Instead, it writes the assembly code and returns a function pointer that can be used in the following way:
float pixelData[3];

...

(*myExtractor) ( context,
    x, y,             // The X & Y coordinate of the pixel you want
                      // relative to any offsets set in cvPixkExtractor.
    &pixelData[0],    // The pointer to a buffer to hold the extracted pixel.
    source );         // The source texture.
...

While I suspect many will consider this a slow mechanism I think you'll be surprised. While no general purpose library can compete with application-specific tuned code, I suspect the results would be better than writing the same code in C.

At some point, other engineers saw this as a good idea "if" it only also did A or B. As a result, many additional features have been added to Bitflinger. The good news is that the code to support them is only generated when it's needed, so the extra functionality does not impact the performance of the simple cases.

The added features include:

  • Color modulation of source data
  • Color map table lookups (index & per-component)
  • Blending with destination
  • Destination Logic ops
For those who are interested, here are some uses of the above features. Color modulation can be used to render AA text in any color from a luminance map. Table lookups can be used for gamma correcting and de-correcting bitmaps. Blending is also used in AA rendering and other transparency operations.

The updated Bitflinger should appear with the new OpenGL kit.

return to top


Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission.

The BMessage
Copyright (c) 2001 by Be, Inc.
All rights reserved.

Be, Inc.
800 El Camino Real, Suite 400
Menlo Park, CA 94025
Tel: (650) 462-4100
Fax: (650) 462-4129
Web: http://www.be.com/

Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved.

The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.



.
About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors
.
Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!