Be Developers' Conference Open GL Today and Tomorrow Pierre Raynaud-Richard and George Hoffman

Pierre Raynaud-Richard: So we are going to talk a little bit about OpenGL® and the BeOS, what's the current state and what we're going to do in the future. So in more detail, Release 3 has been an exciting release, but a very busy one, which means we didn't have time to work on everything we wanted to. At the same time, it was a very interesting experience.

We've learned some interesting lessons, and I want to share a couple things with you about that. After that we will look at the priority balance between the two current 3D solutions in the BeOS, the industry standard OpenGL® and the 3D Kit, our proprietary C++ API. And from there we'll be able to define what are the priorities for future 3D development, and we will get a quick look at what is currently available today.

So first things first. I supposed you've already heard about R3. There were a lot of things going on in Release 3, not all of them expected, when we started on it. Two big actions were required: moving to the Intel platform and increasing our efforts in video support. That already includes 15 and 16 bit mode support, new in R3, new API like BDirectWindow, and still more to come as part of an improved graphic driver architecture, like VBL sync support and things like video composite output. So if you also include all the things that go with that, that's a lot of work to be done.

And so we discovered that with the limited resources we have, we can't always spend the time we would like for the priority we have. And as the time is coming when you will start sale applications to user, and will need to make a business out of it, we want to enable all of you with a fully functional and 3d solution as soon as possible, which for us means we have to look a little closer to our priorities in that area, and also that we have to get more engineers to help accomplish that. That's why we have been very recently hiring a lot of new engineers.

So OpenGL® versus the 3D Kit. In the current state of the world it's becoming clearer that OpenGL® has a stronger position for at least those five reasons. First, in the Intel world, hardware accelerated cards are becoming really common and cheap. Lot of solutions are popping up all over the place and OpenGL®, which was handicapped in the past, because its poor software performance, is going to be really great, as OpenGL® has been designed from the start to a portable API for hardware acceleration.

Also, OpenGL® has been building momentum in the whole area for more than a year and I would think we saw a clear failure of direct 3D in that respect. That just improved the strong position of OpenGL®.

OpenGL® is also well-known, well-tested and you can easily get documentation for it. You can easily get sample code. You already used it, your application is already using it, so it's going to be a very fast, efficient way to get 3D on the BeOS

OpenGL® is clearly the best multi-platform 3D API and probably the most important thing, we have been getting more and more feedback from you about getting better support for OpenGL® on BeOS.

Another good reason to set the priority of future development. So the clear conclusion is OpenGL® should get a higher priority than 3D Kit.

That includes three specific points. The main one is getting hardware acceleration going as soon as possible using OpenGL® API. We also want to improve performance at any level in the pipeline, as required.

We want to improve the integration of the OpenGL® library with the graphic system by using BDirectWindow to implement single buffer drawing mode, and as we are going to reorganize and improve the speed of the low-level rendering package. The idea is to define a shared base of code that can use other acceleration modes, such as only in 3D rasterisation library and I think this, if it's a public API it's going to be very interesting for games and also later can be used by the 3D Kit itself as a common base.

So from there let's have a look at the current state of OpenGL®.

(Half-session concluded.)

Mr. Hoffman: This is going to be a whirlwind tour of GLView and GLScreen, but they're not very complex. As I said, it's really easy so just pull up. There we go.

The source code to GLteapot which is available on your R3Ds, it's in optional sample code folder. It's also -- those of you who haven't seen it, it's right here. Pretty standard 3D demo.

Teapot, blah, blah, blah, blah. Lots of different lighting, different kinds of modes you can set and whatever. Big deal.

So the main idea here is that we have this object, ObjectView, which is descended from Be GLView and as you can see, has lots of state associated with it, but it's just a normal view, which can execute GL calls within it. We created here. As you can see, we're passing in some flags, BGL_RGB, BGLdepth and BGLdouble. This tells it we want a double buffered GLView, which is the only kind we currently support and we're using RGBmode. We don't support the color, the more funky color index modes of GL and don't plan to any time soon, as RGB is quite a fine way of representing color for us.

So we have this. Where is it? There we go. ObjectView, created just like a regular view added to the window and bring up the ObjectView constructor and -- I'm being upstaged. Bring up the ObjectView constructor. Call it BGLview with the given options. It's very simple to use, given that you believe that BViews themselves are simple to use. There's not much else going on. LockGL and UnlockGL are calls that have to bracket any actual GL calls. An example of that's right here. We lock GL, this is a method in GLView, do some GL calls, set up all of our state, blah, blah, blah, blah, blah, blah, and unlock GL.

This is important because GL may be dealing with hardware and we obviously can't have many different applications writing to hardware at the same time. And this allows you to have your own granularity of locking, so that we don't have to lock on every GL call for maximum performance.

And then I had, as one of the other notes here, flags facilities. Little things that make coding in OpenGL® on the BeOS just a little more fun and a little easier. We have this call called EmbeddedView, which will return if such a thing is supported in the implementation of GL, that you're using a BView which can draw directly on the GLcontext.

So you can do normal view operations here. I use it to -- let's see if we bring up the old teapot again. I use it to do this little frames per second display and you can see it's pretty simple to use. If you have the view we go through, lock the window, set all our context, draw string, sync, that's important. Make sure that you've actually drawn everything before you do a SwapBuffer. Then you call SwapBuffers before you unlock the GL. It's fairly straightforward.

Things to watch out for when you're using GL is that, like I said, it's not thread-friendly, that LockGL and UnlockGL is necessary. We don't check for it in every implementation because, again, this is a performance hit. If we have to check for it we might as well just do the locking every time if it's not there.

So expect some strange behavior if you don't lock your GLcontext. Not all facilities will always be available. Like I said, EmbeddedView can return NULL. It's valid for it not to return a valid view, to just return NULL. The reason that might be is the GL implementation, we want to make sure that we support third-party GL implementations. If this GL implementation does not support drawing with a BView onto GLcontext, we're not going to make him do it.

It's not part of GL, so it's not going to be required so just be able to deal with getting a NULL from that. Be able to deal with it as we add more of these facilities, again, they'll be optional.

To conclude. OpenGL®, it should be clear from what we said here, is the Be 3D API of choice. It's definitely our priority right now. We want to make sure that we have a focus to get something out there that you guys can ship applications with and have decent performance with and support some subset of the 3 -- the good chief 3D hardware that's out there and in order to do that we need to provide a -- we have to define a focus and so we're going to be concentrating on OpenGL® for now.

Hardware acceleration's coming soon. This is the one big priority. We're planning on pushing a lot of the rasterization code as we optimize it down into a rasterization layer. The rasterization, some like Rave on the MacOS, those of you who are familiar with that. This will be the level at which hardware acceleration will be happening and it will allow things like mini-client drivers that you might see under Windows MT OpenGL® and that will be usable by OpenGL® and the 3D kit. We want to integrate it with OpenGL® first, because that's our priority, then open the 3Dkit. Integration will come later.

And that's the end of that one. Does anyone have any questions?

(Inaudible question.)

Mr. Hoffman: So the question is will there be documentation for Be-specific GL APIs.

The answer is yes. Actually sitting in my office right now waiting for review, so yeah, that will be going on. So yes, we will have documentation for that. It's fairly simple. There's a lot of sample code that you can get started now and the documentation is forth coming, yes.

(Inaudible question.)

Mr. Hoffman: Okay. There have been a couple newsletter articles on that. You can look on the Be web site. You know, this is an area that's still in development for us, so I apologize for lack of documentation, but as I said, there's a lot of sample code. If you have any specific questions, give me some E-mail, geh@be.com. That's my E-mail.

(Inaudible question.)

Mr. Hoffman: So the question is interest in the low-level rasterization API, whether it will be like GLIDE, just a triangle raster.

Yes, it's something very like that, dealing with no geometry, just basically dealing with direct rasterization of triangles, that kind of thing.

A Speaker: Will GLUT be supported?

Mr. Hoffman: Yeah. Actually, not by us currently, but Jake Hanby, one of our interns who was there a while back has a, as far as I know, current version of GLUT, GLUTE, GLUT, whatever, which works fairly well. He showed me a bunch of stuff working with it.

So yeah, I mean it's there. If you look around on the Be web sites there's links to it.

A Speaker: The one that I have that he did is slightly older than what's there, than what is available now.

Mr. Hoffman: We are not as committed to GLUT as we are to GL and GLU. GLU being the C++ish sort of test relation API that goes along with GL, because it's not really meant for images-scale applications and doesn't really fit that well into the Be framework, but we realize that it's nice to have for porting smaller applications and we'll give any support to anyone.

A Speaker: Have your implementation supports EmbeddedViews? Could you embed a GLView or many?

Mr. Hoffman: So the question is could we embed a GLView within -- so you want to embed a GLView within a GLView? Okay. Well, first, I'm curious why you'd want to do it. Second, no.

A Speaker: I'll tell you why later.

Mr. Hoffman: There's several ways of doing that, using GL itself, having nothing to do with GLView. To clarify what EmbeddedView does, it doesn't let you take a view and embed it in the context. It returns a view, which can be drawn to. The other one may be possible, but it's not there right now.

(Inaudible question.)

Mr. Raynaud-Richard: The question is what hardware accelerator are you planning to support. And the answer is as far as the first one we will support, it's not decided yet. It's still depending on some decision of some of our partners, so we'll see about that. I'm sure there will be public information about that as soon as it's available.

A Speaker: Is a translation kit going to include OpenGL® type files and impact type translations and so on. In other words, how do you get from OpenGL® type commands into impact?

Mr. Hoffman: OpenGL® type commands. So the question --

A Speaker: When I'm making a movie, I make some beautiful modeling thing and I want to turn it into a movie and distribute it.

Mr. Hoffman: Oh, I see. It's an interesting idea. That's not really -- I would consider that a third party kind of addition, because there are ways of getting the pixels that are -- that are in the GLcontext, so rendering with GL and then getting the context. I mean it's a -- that will be fairly simple to feed that into a Kodak and certainly either the media kit or translation kit will have translations like that.

I don't think there's anything currently planned specifically to do that, but --

(Inaudible question.)

Mr. Hoffman: Sorry. The question is is there any other way of getting, for instance, text into a GLView, other than if, for instance, the EmbeddedView is not available?

And the answer is GL applications mostly have textures which are fonts. A lot of them just draw fonts that way. They can also draw them polygonally. There's a bunch of ways that GLapplications do that. There's also you can blit pixels directly onto the GLcontext also using GL calls, which have to be supported by any OpenGL® implementation. So there's is always going to be a way out, even if not really pretty.

Sorry. If you have more questions, we are running late, just come ask us directly after the session.

(Session concluded.)