Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

Issue 2    May 17, 2000 Be Press Releases May 9, 2000 Be Goes Platinum with BeOS 5 return to top Look for a new Marketplace article in the next issue. return to top Spreading the Virus by Jean-Louis Gassée After the "Love" virus epidemic, the expression "viral marketing," popular last year, looks... so last year. Examples of viral marketing ranged from the Real Player to WinZip, from Adobe Acrobat to... Internet Explorer, the virus that killed Navigator. The idea was and still is to infect as many PCs as quickly as possible using the Net as the transport mechanism for both the product and the buzz about the product. Calling this "viral," even in the case of a certain HTML interpreter, is a little extreme. Such products, even if they occasionally maim their competition, are not supposed to damage my PC or the files stored on my hard disk -- notwithstanding the therapeutic benefits of periodically reformatting and rebuilding one's system. A true virus is designed to corrupt a system and to replicate itself across the Net. Pursuing the biological simile, observers pointed out another problem caused by Microsoft's monopoly: the lack of genetic diversity in the PC ecosystem. Because PCs and their software are too similar, one noxious automaton can do much more damage than would occur if we had several alternative life forms. This argument deserves closer examination. True, BeOS, MacOS, and Linux users were not infected by the Love virus. Had each system had 25% market share, a single virus could only infect 25% of the population. And, if you assume some degree of precaution or paranoia on the part of users, sys admins, or ISPs, the 25% infection rate would be even lower. We'll quickly dispose of the argument that users should know better than to open an attachment without questioning its provenance. Yes, but no. Computers are supposed to serve us, to make our lives easier and simpler. Computers juggle very complex tasks under the hood, so they should take care of virus-carrying attachments for us. But that's where sloppy technical habits come in. In the name of making things easier (for whom?), Microsoft engineers have made Windows too susceptible to manipulation behind the user's back. No alert asks the user's permission and nothing verifies the origin of a program that modifies a key part of the system such as the registry, or that sends e-mail not created by the user. It reminds us of a certain Chairman, in a video deposition, quibbling that the computer, not he, had sent an incriminating e-mail. We ingrates now realize he was just being prophetic. Seriously, the fixes in preparation for Outlook will address these weaknesses without impeding our ability to download and install software updates from the right sources. Going back to the eco-diversity argument, it might contain a hidden flaw. With the Web, all browsers from all OS's need to adhere to the same set of *ML definitions in order to faithfully render Web content. In other words, all platforms are supposed to interpret *ML tokens in the same way. The unanswered question is whether or not this required conformity is a path to large scale infections by malicious applets. This last word brings up Java and its greater immunity from attacks -- not absolute, just greater. But, can everything required for Web navigation be performed solely within the safer confines of a Java environment? We know the answer: there is no JavaOS. So, we're left with "mixed" solutions and unanswered questions. As Web-enabled devices -- a.k.a, appliances -- proliferate, we'll have to inoculate these life forms against malicious programs on both server and client sides of the connection without placing too many restrictions on the real freedom to innovate. The frightening thing about the Love virus is that it was partially botched. In a way, it was a welcome warning against more efficient plagues, including strains that could do harm on more than one platform. We acknowledge that no OS, ours included, is invulnerable, but it is the degree of vulnerability that matters. return to top The Proliferation of BeOS in Europe by Jean Calmon My American colleagues sometimes ask me how we get so many publications interested in BeOS in Europe and what we do to service that interest. It's a fact that as of today 53 European magazines, representing a total of over 5 million copies in 20 different countries have signed an agreement with Be to distribute BeOS PE on either a monthly regular CD or a special one which includes some freeware. Our European PR manager Marie-Francoise, who has been at the forefront of this effort since the announcement of BeOS 5, says we have many people to thank. First, a large group of journalists have followed our progress regularly since the earliest version of BeOS. About half of the magazines they write for have published regular articles about our products in the last three or four years. This is also true of some German publications such as Chip, PC Intern, and C'T; British magazines such as PC Plus and PC Pro; and French ones like Login and PC Expert. You immediately notice that a large variety of magazines that could be called a PC user press, but which are distinguished by their style, size, and target audience, report on BeOS. Also a significant number of highly specialized magazines with smaller readerships cover BeOS: Linux Users, Net Surfers, Amiga Users (yes, yes...they die hard...there are still a surprising number of Amiga-related publications in Europe), Programmers, Gamers and Musicians. I expected to get more support from Northern Europe--and got it. New technologies historically are more successful there earlier on. In fact, BeOS coverage by country corresponds pretty well to geography and population: 11 magazines in Germany; 3 to 6 in the UK, Italy, Spain, France; dropping off to only one publication in countries like Lithuania, Roumania, Bulgaria. You can find a detailed list of publications offering the CD insert at www.beeurope.com. The first inserts appeared in late April, the last ones will be in the June issues. There are a couple of reasons why CD inserts are still very popular in Europe. For one thing, Internet penetration in most countries is low compared with the US. This may explain in particular the large number of magazines circulating in Eastern Europe, where networks are not yet at the highest level of reliability and bandwidth. Magazines are rather expensive in Europe and the cost of a CD is built into the per issue or subscription price, which prevents these magazines from re-charging CD content providers. Telephone connection time is still expensive (about twice what it costs in the US). Although deregulation is changing this rapidly, Europeans still pay for local calls, so downloads are a significant expense for most people. Another factor that encourages distributing BeOS on CD inserts is that European cultural attitudes are individualistic. Germans, French, Italians, and Spaniards like to test new technologies and will adopt a non-standard product more easily. They are different, they look different, they don't drink the same wine! This individualism may explain the success of Linux, Amiga, OS/2, and Apple in the past few years in Europe. Also Europeans -- do they exist? -- tend to consider their nationality the language they speak and read. Consequently, they like to discover new products through reading their favourite local magazines. Getting an English-language version of BeOS on a CD is great, but the article or review in the user's own language that goes with the CD is even more important. I don't know yet how many BeOS-related pages of copy will accompany the CD insert, but I suspect there will be way over 200 in more than 20 languages. Going back to Internet penetration, even if Europe, except Scandinavia, lags behind the US, growth now is very high. The new Internet economy is taking shape and growth is explosive. I'm encouraged to see the emergence of BeOS-related Web pages on many sites, managed by publishing groups such as Ziff-Davis, Future Publishing, Data Becker, and others, in many different languages. This is very helpful for our users and for Be. Check http://www.beeurope.com/world/links.html to see some of the European Be-related sites. For the first time some IT-related sites have reached a very high level of visitors in Europe. A good example is Computer Channel, a new site in Germany that has excellent BeOS pages and has reached a level of 130,000 downloads in six weeks! The arrangement was made at CeBIT in March. The BeOS Web community in Europe is fairly large, and a number of Be-related sites such as BeNews are animated by European developers, fans, and individuals. So, should we expect soon to see many consumers going more naturally to their favourite site (as early adopters already do) rather than purchasing a PC magazine? I'm not sure about that in Europe. It may take several years and require the generalized use of DSL, cable, or wireless technology with low-cost air time before magazines are strongly impacted by Web competition. Maybe then we'll stop "free" CD distribution in magazines. Meanwhile, we plan on getting additional magazines to make sure that most PC users get a chance to test BeOS 5 and, I hope, order a Pro version soon afterwards. P.S. Writing about European differences, I can't resist quoting the French philosopher Descartes: "It is useful to know something about other nations' habits in order to judge our own in a healthier fashion, and not to imagine everything which differs from ours should be dismissed as ridiculous or illogical, as is frequently done by those who haven't seen anything." return to top OpenGL Performance Tips by R. Jason Sams I field many questions on OpenGL programming. The third most frequent one usually is about performance. Why does this code run so slow, or how can I make this faster? The number one and two most frequently asked questions are "When will the HW driver for... be ready?"and "Why doesn't this code do what I want?" To achieve good performance an application needs to do two things. First, it needs to minimize overdraw to make the best use of whatever fill performance the system has to offer. Second, it needs to efficiently provide triangles to OpenGL for rendering. I'm going to focus on the second performance issue and leave the overdraw component to more detailed texts. When an application renders a scene it does so by sending hundreds or thousands of triangles to OpenGL to be drawn. The core OpenGL API has several different methods for drawing triangles. Here's a list of some of the basic ways to draw objects: Drawing Primitives: Discreet Triangles Triangle Strips Triangle Fans Polygons Discreet Quads Quad Strips Of this list triangle strips and quad strips are the most efficient for specifying triangles. The reason is that after the first triangle, each additional triangle needs only one vertex to specify it. As a result, much less T&L work needs to be done. Example: 10 triangles drawn as discreet triangles, discreet quads, and triangle strips. Discreet triangles: 10 triangles * 3 vertices each = 30 vertices. Discreet quads: 5 quads * 4 vertices each = 20 vertices. Triangle strip: 3 for first triangle + 1 each for next 9 triangles = 12 vertices. Let's run a number of triangles in an actual application. In this case we'll use the new BDirectGLWindow-compatible version of Teapot with a Voodoo 3 and a PIII 500: Lighting off, immediate mode Discreet Triangles 760 fps Triangle Strips 1450 fps Lighting on, immediate mode Discreet Triangles 314 fps Triangle Strips 650 fps From these numbers it's very clear that strips produce much better performance. This will occur in almost every case. The basic lesson here is to use strips whenever you expect to draw more than a couple of connected triangles. Using strips solves half the problem but you still need to specify the vertices. Once again, there are several methods available to do this: Immediate mode ArrayElement DrawElements DisplayLists Immediate mode is probably the most common. It simply consists of calls to glVertex, glColor, and glTexCoord. ArrayElement uses a user-defined array of data to specify all the vertex data with one function call per vertex. DrawElements uses a second array to specify the indexes into the array for each vertex, allowing the entire strip of triangle sets to be drawn with one function call. DisplayLists are a recording of OpenGL commands. One of their uses is to store entire objects such as the model for the teapot. Let's take a closer look at each. Immediate mode drawing: This is the simplest choice because it does not require any setup. The downside is that there is considerable overhead to making several function calls for each vertex. However, we've made considerable effort to minimize this overhead. ArrayElement: This requires the user to set up the OpenGL vertex array machine with a description of the array. There is a utility function to simplify this. The big advantage is that now you only need one function call for each vertex. DrawElements: This requires the same setup as ArrayElement but also then requires the application to assemble a list of indexes for the vertices. As a result, this has almost no function call overhead. The one danger with this function is that if it's used with large, dynamically generated arrays you may run into issues of overflowing the CPU cache. DisplayLists: To set this up the application begins a list, then renders the object using any combination of the basic commands, and then ends the list. As a result the cost of creating the list is high. This makes DisplayLists useful only for objects that do not change frequently. They have a significant upside, though, because the OpenGL implementation can take time and internally optimize the display list. This should, in theory, result in DisplayLists being the fastest of the options. Results Lighting Off: Discreet Triangles Strips Immediate mode 760 1450 ArrayElement 780 1480 DrawElements 780 1500 Display List 550 1260 Results Lighting On: Discreet Triangles Strips Immediate mode 314 650 ArrayElement 316 660 DrawElements 318 650 Display List 276 615 These results are close to what we would expect, with one exception. The performance of DisplayLists is below expectations. This is currently due to a limitation in the OpenGL implementation. Once this is corrected, I do expect them to move to first place. Also, on chips that have hardware T&L support the gap could easily be 3x or 4x the next fastest. The other popular method for optimized drawing is the compiled vertex array. The idea behind a CVA is to allow the driver to transform an array of vertices and then use the results for batch triangle rendering. This is an OpenGL extension that is not currently supported. The primary purpose of the CVA was to help out systems that used a slow FPU to do the T&L work. As a result of this their usefulness is diminishing with the move to HW T&L and special 3D instruction sets. A note on the performance numbers. The frame rates indicated are useful for benchmarking purposes only. Running faster than the refresh rate of the monitor is not useful in almost all cases. Stay tuned for more OpenGL news. 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!