Hello everyone. Welcome to Java Graphics session. My name is Gerard Ziemski. I'm Java Classes Engineer and my responsibility is graphics. I would like to welcome also Vladimir Lotak. Vlad, tell us who you are. Hi there. I work on Java Classes and my specialty would be anything to do with events. Vlad will help me with some demos. So, let's get started.

Session overview. In this session we'll cover three topics. First of all, I'll give you a brief introduction to Java graphics on Mac OS X for the benefits of those of you who do not know that much about Java graphics. And specifically I'll focus on some of the features Mac OS X provides you.

Then I will talk about advanced topics. In that part I will talk to you about things that you as a developer should be aware of. Things that may help you explain and understand how to make the most of your program, how to make it run the fastest as possible. And if something goes wrong, possibly tell you why things go wrong. And specifically I will focus on graphics performance and imaging.

And then I'll talk about future. And there, in that part, I'll tell you a bit where we come from and what we are thinking of doing next with Java graphics, specifically on Mac OS X. So let's talk about Java graphics on Mac OS X. Again, here I will try to inject some of the details and implementation specific details of Mac OS X implementation for Java graphics.

First of all, you have to realize that our implementation of Java graphics on Mac OS X is based on the Quartz engine. When we started working on Java2D implementation some time ago, we had a choice. We could have gone with the SAN provided source code that implemented the renderer and its software.

We could have done that. In this way, we would stay very closely matched with what Java graphics looks like and how it behaves like on other platforms. We also had a choice to base our own implementation of Java graphics on Quartz, and we decided to go with Quartz.

I'll talk in this part about three things. First, I'll introduce to you briefly the graphics, original graphics object and what you could do with it. Then I'll talk a little bit in more detail about the Graphics2D features. And lastly, I'll talk to you about specific features that Mac OS X brings with its Java graphics implementation.

The original graphics object. The original graphics object was primarily designed to be fast and the key underlying concept in graphics was to make it fast, all the primitives were supposed to go over the network. So the primitives were limited in scopes, they were very basic and that's what you have. With the original graphics object you could draw lines, rectangles, ovals, polygons, simple graphics primitives, but they were fast.

You had limited access to the color. What you basically had was a solid color. You could choose whatever you wanted to, but it had to be a solid color. Moreover, transparency, the alpha channel, it was all tricky to access that. And in Graphics2D, that feature has been added to make it much more easier for you to play with transparency.

Original Graphics Object had very limited support for images. It had only one type of an image, which in a way makes it a little bit simpler, because with Graphics2D you have, I'll talk about this a little bit more, you have several different buffered image types and depending on the platform and depending on how you use them, things may not go as smoothly as you would want them to be. So the basic images support was there in Graphics Object.

You could do things like animation using the producer-consumer model. So you could do some interesting things with Graphics, but Graphics2D goes much more beyond that. In text, you had very basic also support for the text. What you could do primarily was simply draw a string. That was about it that you could do with Graphics. So as you can see, you can do a lot of things with Graphics. You can do a lot of things with graphics.

Graphics2D is, first of all, highly extensible. What that means is if there is something missing in Graphics2D that you wanted to have, you have interface that are provided for you that you can simply implement. You can create your own objects, and you can simply take them, plug them in, and everything else will just work.

It is also low-level. What that means is it gives you an access to things that really covered the basics of what graphics is. For example, with buffered images you have the access directly to the pixels. You can find information about the layout of the pixels. All of that is encapsulated in the raster objects, color model.

You can look it up, and you can find out information about this and use it to your advantage. So you have an access to really low level

If you wanted to implement modern web browser, you could do this. The Java advanced images itself, which we don't have on Mac OS X, But Java Advanced Images itself is implemented on top of Graphics2D. They didn't have to implement their specific native hooks in order to do some fancy stuff. All of that, the underlying features are already there in Graphics2D.

Graphics2D, in order to understand Graphics2D, be really successful using it, you have to realize and you have to really understand three basic principles, and that is, what is graphic context? What are the graphics context attributes and also the graphics objects? So what are those? The graphics context is, you can think of it as the surface. If you're drawing whatever it is, a primitive image, single pixel, you have to draw it somewhere. That is represented to you as a graphics context. Graphics Context Attributes.

This lets you control the The features of the context itself, things like what kind of color you want to use, what kind of color model, do you want to use transparency or not, do you want to use transformation matrix or not, those are the graphics context attributes. You should be familiar with those. What is there, what is available, how to use them? Graphics objects, those refer to the actual objects that you can render. So those are basically shapes, images, and text.

All of them are represented as objects, and you can do some interesting things with them because they're objects. Now, if you want to be really successful with Graphics2D, you have to go a little bit beyond that, and you should have a clear understanding of buffered images and transformations. And right here, I'll talk to you a little bit more about buffered images and transformations.

This is a basic concept in Graphics and if you want to play with them and if you want to combine them, you need to realize what effects they have. And also it is important to you as a developer because we do have some bugs. So you need to be aware of, it would be helpful if you knew what the effect of combination of transformations is supposed to be. If things go wrong, you should be able to realize that this is probably not because you're doing something wrong, but it's probably because there is a bug in our implementation and then just tell us about this, we'll fix it.

So right here I'll tell you-- I'll just give you three examples of the Graphics2D features. Because our implementation is based on Quartz, you can do all of that in Quartz. And on the left I showed you an example of the concept, the name of the concept as it refers to in Java.

On the right I show you just bits of information of what we as Apple had to do in order to make it run, to implement this using Quartz. So first, shape objects. Shape objects. They are primarily defined as paths. If you look at Quartz, everything in there, even a line, the line is not just a line. It is a path.

In Graphics2D, you have an access to that. So what is a pad? This is a concept of your visual pen. You pick up a pen, you put it down, and you start drawing. You start defining a pad. The pad can consist of line segments, can consist of cubic and quadratic curves.

So this is basic concept behind shapes, but now we have shape objects here in Graphics2D, and that means you can do some interesting things. For example, you can use a shape and actually use it not only to draw, but for example to define a clip. So we have an example here where we had a glyph vector, and then we simply asked the glyph vector for its shape, and once we had that shape object, we simply used it not only to draw it on the surface, but to define a clip. This is an example.

So this is an example of objects in Java. Now we have an access also to compositing. This is an interesting feature because nowadays, and I'm sure you're familiar with Aqua Look and Feel, so you can see how many transparencies and and Andy Eliasson are involved in drawing modern graphics user interface. You have an access to all of that through compositing model.

So for example, what you can do is you can set different transparency values and then obtain interesting effects. If you wanted to implement nice drag and drop feedback action, you can simply render the object that you're about to drag as a translucent image and you can use that in order to give feedback to the user. You can do that very easily with transparencies.

and Mike Skipwin. Strokes. This is another interesting feature in Java2D. You not only can render a line, a path,

So beyond Java2D, because our implementation is based on Quartz, What is important to you is to realize that on Mac OS X, Windows all double buffered. If you use swing application, There is a way to turn on or off double buffering in the swing.

On Mac OS X, that operation is set to a no-op. You can try and set it to be double buffered, but because the windows on Mac OS X are already double buffered, we don't do anything. However, you may want and try to implement your own double buffering mechanism. In some instances, that might be necessary.

However, most of the time you should not probably do that. What you will end up doing is simply triple buffer and you will pay a penalty for that. So, with your application just try and run it in Mac OS X and see whether you really require your own double buffering mechanism. Probably you will not.

PDF underpinnings. Quartz itself uses PDF to describe a scene in a resolution-independent way. What it means is if your destination context is screen, the pixels are actually baked in at a certain resolution, the resolution of the screen, and that's how it is presented then on the final destination, final context, which is your screen. However, you can render your scene to a printer, which is a different device accessible to you from Java2D.

If you do that, you're seen as being rendered in a resolution-independent way. What you could do is then specify, I don't really want to print it. I want to save it, for example, as a PDF file. And what you will get is right from your Java application, Your scene can be rendered in a PDF file very, very easily.

So somebody asked me yesterday a question about they had a problem and what they wanted to do was they wanted to do exactly this, except they probably didn't realize that this support is already in there. What they tried to do was, they tried to render an image, they tried to render a scene into an image, and because the printer has much higher resolution than a screen, what they tried to do was they tried to render their scene in a much bigger image so that once they created the image, once they rendered their scene into the image, they simply wanted to send that image right to the printer. Now, the problem was they weren't sure what is the resolution of the printer.

So that's one of the problems. The second problem is once you render it to the image, what you're sending to the printer then is this huge job. An image is simply a bunch of pixels. It's a bitmap. It's a lot of information to send to a printer. It would be much easier to simply create a PDF file and then send that to the printer.

Can we take this off, please? Go to the slides. This one. and Fun Support. Now again, when we had the source code, when we were starting to work on graphics on Java2D on Mac OS X, We also had a choice to go with Sans' own sort of renderer for the fonts. We decided not to. We decided to go with Quartz. And because of that, we get beautiful looking, beautifully anti-alias fonts.

That's what we have here in Mac OS X. So let's move on. So this is the second part of the session, advanced topics. I call it advanced, but it doesn't mean it's difficult. It simply means that I'll cover here some topics that may not be, you may not think of them necessarily. You may not be aware of them, but you probably should.

So I'll talk to you about rendering hints, the graphical context in more detail, and graphics for acceleration, and then I'll give you some hints and tips. Rendering hints. First of all, they're optional to implement. On Mac OS X, we have support for only few hints. We have support for text rendering hints and graphics rendering hints.

Now, the default settings of these hints on other platforms is different than what it is on Mac OS X. That is because on Mac OS X, we have implemented our own Aqua look and feel, and we wanted that to match as closely as possible to the native Aqua look and feel. What that means is we had to turn anti-aliasing on for the text. Otherwise, you would see the buttons with this ugly non-aliased text.

It just didn't look good. So we had to do this. However, if you know that your application does not need to use the hints and to use the anti-aliasing, you can override that. You can use the runtime options for the text and for the graphics, and you can set it to false.

Also, what you could do is, in your applications, once you have the access to the graphics to the object, you can use the setRenderingHint method and set your hints to whatever you want. And lastly, there are other rendering hints. For example, there is a rendering hint that lets you specify what kind of interpolation to use for your images that you draw on a screen and those images are scaled either upwards or downwards. This hint, the support for it exists in Quartz, and the implementation of this will not be difficult. However, that's one of the hints, for example, that we're missing. So, yes, on Mac OS X, we don't implement all of the rendering hints yet, but we probably will.

Graphical context. Let's talk about this in a little detail. Now this is important for you to understand. First of all, conceptually you have to understand that there are two different types of context depending on the What kind of service do they provide? You have a source context, an image for example, where its purpose is simply to serve as a source of the pixels, and you simply grab pixels from the source context, and then you do whatever you want with them. And usually what that ends up being is you simply put them down, or your destination context. So we have two types of context, source and destination.

And then based on their image representation, there also can be of different types. Now this comes because in Java2D you have buffered images. And buffered images were added because there was a need to represent platform specific types of images. So you have, you have types of images such as RGB, RBGR, and here is where problems may occur on Mac OS X.

So, let's look at the problems So let's talk about the flow of the pixels. If you think about your Java application, then this would be this box on the right. What you usually do is you have a source of a pixel, whatever it is, the source context or your graphics primitives object that you want to draw. They go then and they end up being drawn on the graphics context, the destination in your Java application.

However, this is not the end of life of pixels. The way they're being displayed on the screen is they have to be natively put almost physically on the screen. How does that happen? Well, natively there is another context, the final destination context, which represents a window, which represents screen.

In Quartz, that is the native window surface. Now the problem here is that In Java, you have the access to many different types of context based on their image representation and also on the color space model that you're using. However, when we had to implement this on Mac OS X, we were slightly limited. So, suppose this is how many different context types you have in Java.

Then Quartz can only represent that many, a subset of original Java2D types of context, can represent only that many as a source context. Then, again, you take a subset of that, and this is what Quartz can do as a destination context. And then yet another step, you take a subset of that, and only this is the subset of context that Quartz can use in order to draw on the final destination. So, what is of interest to us is that natively there are only two context types that Quartz can handle. And that is the RGB, the integer, 32-bit representation, and RGB, 16-bit representation. So let's go to the demo. Can we turn this on? Right.

Let me show you what that means in practice. So, Vlad, what is the buffered image type we have set right now? We are running 16-bit RGB 555. So this is what we have it set right now. The key point here also is that the computer, the monitor itself is set to 1000 color mode. What this means is if you refer to this picture, All the contexts match. Why? Because the monitor is set to thousands colors mode, which is 16-bit.

And then we use a perfect image, which is 555, which is 16-bit. So there's no conversion that needs to happen anywhere on this path. So the pixels just flow. So this is the best we can do. And what is the frame rate? Anywhere in between 120 to 140 frames a second. Alright, so let's remember that number. Now let's switch to another type.

Alright, you can see it's a little bit slower. What is the frame rate? And that's about half of what we were getting before, 70 roughly. And the type of the context right there, the image? And we are looking at 32-bit alpha RGB pre-multiplied. So natively, this is a context that actually Quartz can handle.

However, the Because the computer, the monitor is set to thousands of modes, right now it cannot handle that directly. So there needs to be conversion that takes place, and that conversion takes place right here. It doesn't happen in Java, it happens in Quartz itself, but the conversion takes place and we are losing some speed. As you can see, we only get half of the speed. And can we switch to another time? Sure.

Now we are looking at a 32-bit A BGR pre-multiplied and we are about 25% of the original speed, 45 or so frames a second. So we are slower yet again. Now why? You have to realize the key point here is this is BGR type. What that means is for every single frame we have to walk through every single pixel and we have to swap R and B. So this is an example where things go wrong right here in this step.

This happens in Java code and this is the code that we are responsible for. Right now we are not using things like Altevec to try and optimize that. We could and probably we will. So there are things that we can do about this to speed it up. However, right now you just have to pay penalty and that penalty is never going to go away. We can make it smaller by trying to use smarter algorithms but we can do things like for example capitals.

We can cache pixels once we swap R and B. Why not? Because if you have a buffered image you have the access to data buffers. If you have the access to data buffers we do not know when you can draw directly on those pixels. So we cannot detect that.

What that means is we have to assume that once you call data buffer, you call getRaster, and then you extract from the data buffer, you start manipulating the pixels, which is the case you have to do for animation, for example. We cannot cache that conversion. That conversion has to happen for every single frame. So there's penalty, speed penalty. It's never going to go away. It will get smaller with better implementations. And we can do that. We'll work on that. Thanks. Slides off.

Can we take slides off here? On JavaDev, there was a thread about three weeks ago and some of you asked, "So what's the deal with the Plasma Output? Why is it so slow?" And the reason was actually two-fold. First of all, the original, the Plasma Output uses the original image type and it uses the producer-consumer model, which means that when we try and render that, we have to convert that image into a buffered image.

So this is where the penalty happens, first of all, because we have to create a buffered image object for every single frame. So we have to do that. And also, unfortunately, well, more fortunately, Plasma Output uses the index color model. Index color model in back days, it was used as a sort of compression object. in order to... In order to represent an image in a smaller number of pixels, we had index color.

So the color was represented simply by an index, by a simple number, as opposed to, for example, 32-bit value for a pixel. However, right now on Mac OS X, we don't support index images directly. So what happens is we have to convert the index color model to the direct color model, and that incurs a penalty.

However, there are things you can do about this as a developer. First of all, important things to realize is that So this is just pieces of the code that are in original applet, the Plasma applet. What you can do is you can switch to using buffered images. and Don Hardcode the types of the context. Because you never know what can change in the underlying implementation.

Quartz may decide to implement different destination context that may be faster and we may want to switch to them internally. So there's a way for you to obtain the best context without hardcoding any values. And this is a piece of code that shows you how to do this. So notice there we don't hardcode anything there, especially the type of the context. We just ask the system questions. Give me your graphics environment.

Give me your device. Give me the configuration. And give me the default color model. We ask all those questions and then we create a buffered image to represent our context. We use that information. And then you're guaranteed that if you do this, on Mac OS X, you're going to get a lot of information. And you'll get the best matching context.

And keep in mind, if your monitor is set to 32 bit mode, millions of colors, then it will end up being the integer ARGB pre. And if your monitor is set to 16, to thousands of colors mode, then that will end up being new short 555 RGB. But don't hardcode those values anywhere. Can we switch to demo one, please? I will show you now the Plasma Upload as modified by me.

Vlad is trying to get that ready. I'll show you that demo later. In the meantime, let's go to another slide. Hardware acceleration. This is a topic I like to talk about. Hardware acceleration. Introduction. We ready? Mm-hmm. Okay, do you guys want to see the Plasma demo? Just speed it up? Okay.

Can we switch, please, to demo one again? is a-- it's in that iBook? We're running this on the iBooks, so the frames rates will not be as impressive. But relatively to each other, this should still give you an idea. Right now we're running at about 34 frames per second. This is the modified version. Remember, the modification was pretty much only making sure we're using the correct Context type. That's all.

So this is the new one, modified. So we get 32, maximum 37. And now let's run the original This is the original one running at around 22, 21, 20 frames per second. So you have, there was 35 say versus 22. So you have nice, Nice increase in speed by not doing much at all, just making sure we're using the correct image type. That's all.

So let's move on and talk about hardware acceleration. Here we have some demo machines. There are dual 1 GHz machines. The performance of them is 15 gigaflops. One gigaflop is one billion floating operations per second. You may be surprised to know that there is actually equally faster CPU sitting right in there in this box, and that is the graphics video card. Those computers have GeForce 4 MX video graphics card, which have performance of 15 gigaflops.

So let's take an advantage of that. And this is where hardware acceleration comes in. Normally, this CPU, this graphical processing unit that sits right there on your video graphics card, is not doing much at all. So hardware acceleration is trying to actually utilize that extra CPU, if you will.

Now, on Mac OS X, there's only one way to achieve hardware acceleration, and that is through OpenGL. You'll hear a lot about OpenGL. You probably heard about Quartz Extreme. So if you are interested in graphics on Mac OS X, I would suggest that you pay attention to where OpenGL is moving because it is going to be an underlying mechanism for us implementing hardware acceleration efforts.

Because we're using OpenGL, OpenGL was designed with speed in mind as opposed to Quartz where these guys really pay attention to the quality. And you look at every single pixel and it's just almost hand tweaked by these guys to look pretty. OpenGL doesn't care much about anti-alias pixels, it cares about the speed. So if you use hardware acceleration, you'll gain the speed but you will lose the quality. You have to be aware of that.

The activation. Many of you were unhappy with our decision to use the opt-in mechanism for turning on hardware acceleration. Because what that means for you is whenever we introduce a new computer, you have to update your application. We understood that and we changed that mechanism to be opt-out. So I think we'll be happier with that. Once you start playing with this, please give us feedback on this.

Heuristic and fallbacks. There are things we cannot do using hardware acceleration yet. In those cases, we will have to fall back on the solder renderer, on the Quartz, make an under Quartz itself to render the scene. We are using heuristic in order to determine what we can do using higher acceleration and what we can't do. For example, drawing fonts at sizes larger than 24.

is not going to be hardware accelerated. Why not? Because the way we hardware accelerate the text is we render every single glyph off screen to an image. And then when the time comes to actually draw the text, we are simply extracting those pieces of the image and we're blotting them on the screen. So this is very fast.

However, if you increase the font size, at a certain point, the image we would have to create in order to represent the glyphs is going to be just too big and is going to be too memory--. It would take too much memory in order to represent that. So, for example, heuristic is the piece of the code that determines when we can use our acceleration and we cannot use it.

UI framework implications. What this refers to is basically do not double buffer. If you want to use hardware acceleration, do not double buffer because OpenGL is a mechanism for accelerating drawing on screen. If you double buffer, it means that you're rendering a scene to buffered image off screen. That is not being hardware accelerated. We cannot do that yet. We will. So let me show you then a demo of hardware acceleration. Can we switch to demo one? Give it another second, Gerard. Another second? Okay. Can we go back to slides, please? Power Acceleration.

Now, let me tell you... I'll have two different demos showing two different... Two different issues where hardware acceleration helps. First of all, images. If you think of the flow of the pixels in a slightly different way, you have to realize that if you have a buffered image, for example, that represents your image, the pixels live in your RAM. In order to show them on the screen, they have to go through the CPU bus, they have to go to the video graphics card, and then from the video graphics card to the screen. That's a long path.

So what can we do about this? Well, with OpenGL, and this is an implementation detail, what you can do is we can represent the static images as textures. So then we upload it once to the video graphics card, then the image, all the pixels, live right there on the video graphics card itself. When you want to render that image, we simply say, render the texture with that number, with that index.

and then when you think about this, the flow of the pixel, the path the pixels have to go through in order to be shown on the screen is much, much shorter. They simply, they already exist, they live on the video graphics card. So in order to be shown to the screen, they take a very, very short path. Right from the video RAM to the screen. Boom. That's it.

So this is one aspect of hardware acceleration. Now another one is if you render simple primitives like drawing lines, rectangles, this is what the hardware--this is what the Video Graphics card were designed for in order to speed up those operations. So those are not bus intensive. So for example, the same demo just drawing lines on my app book versus on this dual 1 gigahertz machine, the demo that would simply render lines is not going to be that different because... The call to draw a line is very simple. We just pass four parameters, x, y, and another x, y, and that's it.

ImageTiles demo. This one will show off the images.

So we have an image here. Another thing to keep in mind is with hardware acceleration, transformations are for free. If you think about software renderer like Quartz, if you apply a transformation matrix, then every single pixel has to be remapped using a software algorithm, an algorithm in software.

Here, the hardware will do all that job for you. So, it is a little bit of cheating, but, well, I'll show you. So, we can do this. Let's reset that. And let's look at the frame per second rate. So we are getting around 300 frames per second. Now let me switch hardware acceleration off.

This is with hardware acceleration off. Now it is Quartz that is doing all of the work. 14 frames per second. So this is a demo showing you the images. Now let me show you a simple demo that shows you the performance of drawing simple graphics primitives. Drawing lines. So here we have a very simple 3D model viewer.

So we have 63 frames per second and around 1500 lines every frame. We have this model, So this is how it looks with hardware acceleration on. Let me go back to a very simple model, Qube. There's no perspective here, so that's why it looks a little weird. Let me turn hardware acceleration off.

So this is with hardware acceleration off. I'm not sure if you can guys tell whether this looks better or not. But this is hardware acceleration off. So we're starting with very small, very simple model. This is it. This model. Look how slow things get. and this. Now let me turn hardware acceleration on right here.

Did you see any difference in the quality of the model? Although, let me turn it off. This is the Quartz hardware acceleration off. This is OpenGL hardware acceleration on. Now, if your application cares to draw many, many lines per second, then probably you're not going to miss those pixels that are anti-aliased and look just slightly bit better.

So there are certain applications which you can simply not do if you do not have hardware acceleration. Can we have slides, please? That was a demo. And now hints and tips. Use hardware acceleration if possible. Just turn it on, see if it helps. If it doesn't help, turn it off, leave it off, don't worry.

If it helps, fine, use it. Use appropriate image types. Don't hard code them. I showed you a piece of code that showed you how to find out what is the best representation of an image on a specific platform. It's not platform specific. There wasn't any coding there. We didn't hard code anything.

We just asked questions. Use clipping if possible. If you know there's a scene where you don't have to bother rendering certain parts of it, use clipping in order to make it smaller and easier for the underlying mechanism to draw. Cache fonts objects. Creating font objects on Mac OS X in Java is a very expensive call. So if you have to work with fonts, cache them. Don't recreate them. Do not double buff. and do not mix AWT and swing.

Now the future. 1.4 is our future and we're moving there. We started working on this and you'll have a developer preview of our 1.4. You can play with this. And there are certain interesting features in 1.4 that we're looking forward to. For example, Plugable Image I/O Framework. This is an interesting feature.

It makes your application not really care about understanding what the underlying image representation is, whether it is PNG or JPEG or TIFF. Somebody else, a third party can implement a plugin for you and you can simply use it in your code and your application doesn't have to care, doesn't have to know what is the actual representation of the image.

In 1.4 we also get better font and text support. And now this is an interesting point. True type hinted fonts. Now you remember me mentioning to you that we're not using the sans solver font renderer. We're using Quartz to render fonts. So things like this, they're already there.

Because we're using Quartz, because Quartz supports true type hinted fonts, we support true type hinted fonts. So we already have that feature. Unicode 3.0 binding algorithm, that will help you if your application has to be internationalized. If you need to handle Hebrew or Arabic text. This algorithm will help you determine the layout of the text. So it's not a nice feature. We're looking forward to having that.

Also in 1.4 you'll have a full portrait of Compositing Rules support so you can play with the transparencies and with alphas. In more greater detail than was possible. And on this slide, I put these two features specifically together because they're interesting from our point of view. First of all, new pipeline architecture, that is 1.4.

What that refers to is it gives you, it tries and cash the attributes of the context. So if you set a color, if you change one color to the other, it will not invalidate into our pipeline. It will try and be smart about this and not try to invalidate into our pipeline, but just the piece of the code that represents the graphics attributes.

Now, this is interesting to us because we already have that in our implementation. We already have the architecture that supports that. For those of you who were here last year, we talked to you about our pen model, and this is something that John Berkey came up with, and I helped him implement this. Hey, John. And so we already have that.

Volatile Images. This is what SAN does in order to hardware accelerate drawing primitives. Again, I just showed you the hardware acceleration demo. We are already doing this. Now the difference here is that because Swing is double buffered, they decided to optimize off-screen drawing. So they came up with this volatile image object that lets you hardware accelerate your scene to off-screen context.

That's slightly different from what a hardware acceleration is, which In our case, we only have the on-screen context. So that's pretty much the difference, but we can and we will do this as well. And the interesting point is that we already went through much of this, so we already know how to do this. It will be pretty easy for us to actually implement a lot of images on Mac OS X.

Gerard Ziemski, Ken Russell And it's really very similar to what we have. They offer fast paths for images, and so do we. And I explained to you why those static images can be hard to accelerate and can be drawn very, very fast. And they support basic 2D operations.

We go a little bit beyond that. We try to optimize more primitives, but we are so limited. But we can certainly do what Volta images can do. Gerard Ziemski, Ken Russell And they also cast glyphs for high-tech performance

So these two features are interesting because you guys already actually have them.

So let's talk about 3D graphics. Java3D, as you probably know, we are working with Sun on that and that's what I can tell you. We're just working on that. Geo4Java, so what can you do if you actually want to do 3D graphics in Java in Mac OS X? Well, the answer is Geo4Java. And to talk about this, I would like to invite Ken Russell.

: So what we'd like to show you is another demonstration of a new feature in JDK 1.4. and I are going to talk about a new application called NewIO. NewIO can help accelerate your graphical applications, although not the 2D graphical applications that you've seen today. It can actually help accelerate 3D graphical applications. It can also accelerate non-graphical applications, like if you're doing high-throughput sound.

Let's fire this up. So this is not running off the iBook. Oh, it isn't. Okay, that's fine. No problem. That's good. Okay, so what we've got here is a large dataset. It's a terrain dataset and this is actually of the Grand Canyon in Arizona. It's a pretty large data set. It's about 300 megabytes in size, and it's too large to fit in main memory typically on most computers, although actually not on Mac OS X hardware.

So what do we have to do? We have to take the data set and downsample it to a reasonable size that can actually be processed by the computer in real time. Now, what this application is showing off is how you can use new I.O. to do all of the processing that's necessary to render this terrain data set in real time in the Java programming language.

and David Levy are the two main speakers.

The first speaker is David Levy, who is the Now what's phenomenal about this is that you can develop on OS X with the great operating system, the great developer tools, and the great OpenGL implementation. and you can get really high performance out of it. You can approach C++ speeds.

We're getting, frankly, in some of these demo applications, 90 to 100% of C++ speed at this point using the Hotspot JVM. And you can deploy, in addition to OS X, you can deploy on any platform that has a JDK 1.4 implementation, which is good for you, the developer, because you get more possible market penetration for your app, but you get the advantage of developing on a great operating system with great hardware. That's really all I've got to say. Thanks, Ken. That was great.

Go back to slides, please. That was Ken, sharing JL for Java and native I.O. Now, where to go from here? Obviously, there are some interesting Java sessions that you probably should think about attending, but also, if you're interested in graphics, I would like to reiterate that you should pay close attention to OpenGL and what we are doing with it. So, there are many OpenGL sessions in this year's WWDC. I would encourage you to at least check it out. And let's go to Q&A.