Please welcome John Burkey, Java Class' Team Technical Lead. Hi everybody. So I'm going to talk about a lot of things today. Let me grab my little clicker. We're going to divide the talk into three sections. And this is how I work it. There's me. And so our three sections are we do a features overview of what Mac OS X Java is about, the Java 2D and things like that.

That's, I think, important because we've got a mixed crowd here, I think. Tips and techniques for how to make your apps high quality, high speed, and including some of the things that are different about our platform, which is why they're really important. And also our update, which is coming up, and the exciting new technology that's part of the update. And then we'll go to Q&A at the end. So first of all, can I have a show of hands for Java developers? Everybody's a Java developer, good. And so how about a show of hands of people who are Mac OS X people who just heard about Java.

A couple. So cool. Partisan crowd. So, great. So this is Gerard Ziemski, and he'll be assisting me today. So, Mac OS X Java. Finally we have Java 2. It's been a long time coming. We've worked really hard and Sun's been really great to work with and we finally have Java 2. And as you guys know, a big part of that is Java 2D.

Java Graphics, from sort of the Mac OS X perspective, I like to look at it as, just like Quartz, it's PDF rendering. It's, you know, general shapes, a lot of different things that PDF has, and because we are on top of Quartz, we can actually generate PDF, too. We'll talk more about that in a little while.

Also, we're an object API on top of Quartz. I just want to point that out because I think we have some really good advantages, a really good one-two punch, because we have Quartz, which is our OS graphics system, and we have Java 2D, which is a great object wrapper, and I think together they work really well. I'll go into that, too.

And also, this is actually really important. Again, you're a partisan, but, you know, the way we build these things is we use the other APIs to build the nice API, as far as I'm concerned. And so what you guys get, which is just great, is you get the same API.

You get the same API with just a few lines of code. You can render to screen, render to offscreen, you can render to printers. I think that's really great. I was a Java developer for a long time before, as long as any, whatever, three years, right, before I came to Apple, and that was one of the best things I thought about Java was that just you whip out a few lines of code and you can render almost anywhere. So I really like that.

So, to the features, what I'm going to do is first just cover sort of each of these real quick, and then we'll go to the Java 2D demo and just point them out. We wanted to sort of cover that because some of this technology is still pretty new. It's just good to do a quick summary.

So general paths and shapes. A quick way to say that is that Basically, any shape you can do with Bezier, Pass, and Quadratics, you can do with the General Path API. And that goes from lines and rectangles all the way up to the kind of things you'll see in the Java 2D demo. So that means, for the first time in Java, we can do all the things we need to do to do professional applications. Then we can take those shapes, whatever, from rectangles all the way up, and we can fill them with whatever we want.

What I like about Sun's APIs is what they tend to do is define a nice, real, open, easy-to-customize API, and then they tend to have an example or two that is the common use. So in the case of custom fills, we have textures and gradients, and they've defined these for us, and they work just great. And we actually, as a team, try to optimize those cases so that you can get the best performance using the built-in ones, because we can guess a lot better about how things work.

So then on top of that, we have completely custom fills. You can actually define your own paint, actually, it's called in Java 2D, and do whatever you want for your paint. So that's really nice. You supply, you know, maybe there's some new way to do filling that we don't know about yet. You can do whatever you want in there. But textures and gradients work just great.

Custom strokes. So same kind of idea here. This is really good, I think. What you can do is you can define, you can stroke an arbitrary line or curve with any shape you want. You basically... You can be called back and you can say, hey, this is the shape I want you to spray all over my line. However, they also have basic stroke, which is one of these ones they have built in, and that lets you do dashes and line widths, et cetera. So custom compositing, same kind of idea. You define the blit.

So it's like having copy bits for all us old Mac guys. But you can do whatever you want. So that's great. And it's all in Java. So that's great, too, because you don't have to deal with all the kind of things you run into when you run off the end of your blitter, et cetera. So that's nice.

You know, of course it doesn't work, but at least you get an exception instead of a crash. So and then also, this is another one of these that has one built in. It's got alpha compositing built in. And, of course, with the different engines that we use to implement this, that operation is built in.

So we'll get more into what I mean by that in a minute. But the main thing is that you've got custom compositing. You can define to do whatever you want to do when you blit. And you've got alpha compositing built in. Porta-deft compositing rules, which is what... The court supports natively. And, of course, it's completely portable code. You guys know that. Partisan.

So, we'll do a quick overview of the Java 2D demo. This is the Sun demo. I just wanted to do a quick overview of the features. Gerard, do you want to start it up? Oh, you got it up. Great. So we're just going to do a few of the panels. Most people have seen this, but we're just going to point out a few things. So you'll see in this one, this is the stroking stuff we were talking about in the last slide.

They call it lines here. And you'll notice that you can do dashes. That's all basic strokes in the top right. You can do the different types of caps. You can build that thing. The arrows are thick lines with different kinds of caps. They're just giving good examples of different kinds of things you can do. You can switch it.

So here's Arcs and Curves, and the most interesting one is where the cursor is. That's a Bezier animation, and what's interesting is there's a gradient. Phil, why don't you click on that and make that the big boy? and then, yeah, stop it for a sec. And then switch the draw choice to, yeah.

So you saw a texture and a dash stroke. So that's pretty cool. You define the shape and then you decide how to fill it, how to stroke it. And the stroke really is in a way, both a geometry, because you can do dashes and things like that, and a fill for that geometry. So that's pretty flexible. And all via object API, of course. So go to the next one, I forget which we had.

So this is a good one, too. I think they do a good job of making them informative and playful. So the guy in the top left is actually an animated GIF. That's why he marches. So that's cool. It's built into the images. If you draw any animated GIF, if you put it into an image icon, et cetera, they'll animate, which is kind of cool. But anyway, why don't you yank those sliders on the top right one? There's some built-in image operations, too, and they do different kinds of operations.

On the images, you can do color mixtures and some other things. So that's pretty cool. There's several built-in. You can define your own again, too. So that's pretty neat. And then, of course, I guess that's some kind of sheer filter, warp image, but it's doing some kind of sheer transform matrix.

And I think we had one more, right? and I'm just trying to stay light because we have a lot to cover, so we're just going to do a quick overview. So here is another pretty big part of Java 2D and, of course, Quartz. Why don't you mess with the scale, shear, and rotate? I know this is all obvious, but I'm just pointing it out. So there's the scale, of course, the shear, and the rotate. These are all built in. They're all standard. It's standard PDF kind of language. There's a transform matrix, and I find transform, 3x2, just like in Quartz, just like in several other things. It's great.

It's standard, and because it's Object API with garbage-collected objects, you don't have to worry about the kind of things they have to worry about in the native APIs, so I like that. So also, good news for us Mac OS X guys. The Quartz engine does really well against the other platforms and this kind of stuff.

We've measured a lot against Windows machines for these kinds of Bezier animations and things, and at the high end, we do really well with this engine, so we're really happy with that because they did a lot of great work. They're a lot more knowledgeable than we are about graphics, and graphics. And we were able to take the Sun engine, put it aside, and hook up to the Quartz engine instead, and it was really great. So you can... Yeah, we can go back to slides. Thank you.

So let me just click over here. Back to the Mac OS X bonuses, which I started to cover. It's Quartz. It's not a ported, used every once in a while engine, which as good as Sun's engine is, that is what it is. They avoid using it whenever they can, whereas in Quartz, actually, it's the OS graphic system, so we have a lot greater fidelity and a lot more resources behind it.

And that's really great for us Java guys, because as I said, the smart guys work on that in Graff and Eno's group, and they do all the hard work there. So a couple of things that I think are great for us Java guys, though, is there's no raw Quartz function calling. The other ways to use Quartz always involve calling C APIs and pointers. So we get to avoid that. We get the same fidelity and all the same access to everything. And on top of it, we get things like compositing and strokes.

We get custom things built into Java that aren't available in other APIs. That's pretty cool. So it's a real good... One, two of the built-in Apple technologies in Java 2D. Print to PDF comes for free. That's pretty cool. Even if you don't hook it up in some way in your app, every time you print, as I'm sure most of you have noticed, there's always that preview to PDF. In fact, that's always generated, so there's always PDF there. It's pretty cool. And then we'll go into more Mac OS X bonuses in the third section.

This next section is on performance. It's tips and techniques you can do. There are some of these that are really important, some of these are more nuance-y, but I think they're all worth mentioning. The four major areas are image creation, that's actually one of the most important, rendering hints, double buffering, and live window resizing.

So image creation, the key high-level message here is you want to use create-compatible image or the 1.1 create image. I'm going to show that in code in just a sec. But I also want to mention that there's a whole pile of image types that are really cool that we have now. But the fact is we will optimize first for the ones that are native on our platform. And so these aren't going to be optimized for first.

And importantly, there's sort of a little thing that all of us do, right, is we set up our app and getting close to shipping, and then we want to squeeze a little extra performance out of our app. So usually what I do is I rig up my performance analysis tools, either just timing or some tool, hopefully, like we now have optimized in our platform. And then I look and see, well, where's my soft spots, right? So when I find something that just feels slow, I go work on it.

So one of the things that people will do. One of the things that people will do is they'll go in here and say, hey, I'm in a Windows machine, so BGR must be really fast. And sometimes it will be. On our platform, it won't be. And I would really prefer if you always call it create compatible image because we're working really hard to figure out, based on what's going on underneath you, to give you the right stuff.

And if you're going to do image manipulation via the pixels directly, I can totally understand where you want to grab an ARGB or something like that to make it simple. The good news is that one in particular is actually a native image format anyway, so it will be fine.

It's pretty fast. But if you're not doing direct image manipulation, it's best not to guess. Because we're trying our best to pick the right one. So I think I said that enough. So now what we're going to do, if we can go to demo three. So we'll just do some little code snippets. Let me just... This is JBuilder.

I don't think I need to run the thing now. I'll run it once each way. You'll see everything works the same. This particular demo is meant to be simple and not beautiful, so excuse me for my graphics. Very nice. So the green box is rendered. I'll show you that in the code.

So now what we're doing is we're making an image again, except that instead of guessing, we're being maybe too clever for ourselves, and we're making the image ourselves. Looks exactly the same, RGB, but maybe too much information. So again, just to reinforce, it's best to call Create Image or get Graphics Configuration and Create Compatible Image. So back to slides.

and the code. So rendering hints. These are interesting and this is more of a nuance, but as we move forward we'll be taking advantage of these more and more.

Okay, so... let me get organized. So, what we did here was... Sorry, just indenting is a little weird. What we did here was we just drew two lines. and I just wanted to show you the anti-aliasing hand for primitives. I'm just going to run that. It's going to build it. I love the speed here. This is what we use every day because of the productivity.

So anyway, So there's one line that's antialiased and one line that's not. I just wanted to show how that hint worked. And so I'll flip the thing off, and we'll see it the other way. And then I'll just delve into the hints here while I'm here, because JBuilder provides a good assist for this particular thing. So I'll flip this off.

Oops, I think I debugged. Stop that. Okay. So here's running. and John Burkey, Gerard Ziemski. and David This is a great feature of JBuilder. I'm not giving a JBuilder demo, but it's just perfect for this. So let's say I want to do a different hint. I'm just going to copy this. And oops. So be there in a sec.

I'm just going to hit dot here. Here's all the sun hints right here. Here's the different keys. We've got color rendering, default quality speed, as I mentioned before, dithering, fractional metrics, interpolation for when we blit images, how we do the pixel smoothing. There's the rendering quality speed, stroke. There's a whole bunch of them.

So that's really cool, though. Easy way to demo the hints to show you that. There are quite a lot of them. We ignore most of them now, but we will be adding them as we go. As I said, we definitely do the antialiasing one. So I'm going to put that back in and then do, I'll just grab all this.

So can we go back to slides? So there's rendering hints. Again, anti-aliasing and text anti-aliasing. I should just point this out. Some of the old 1.0 applets, like there's an old clock, there's a second hand that sweeps. Does the erase with white or draw myself again with white to erase? On 10, that leaves a blurred trail.

And that's because on 10, anti-aliasing is on by default where on other platforms it isn't. And when you do erase with white on top of, let's say, a draw with black, let's say of an anti-aliasing, you don't get coverage over all the pixels, so it doesn't just stamp it all out.

So because of that, you'll leave trails if you use that technique. The graphic systems are pretty fast today, so we'll get more into that in a minute, as I was saying. So I would recommend not using that technique for rendering anymore. That was something we did in the old days.

Double buffering. This is important. We mentioned this last year, but I want to emphasize it because there's another trick that we were able to do under the covers that, again, we'll talk about in the third section that became possible because of this. So the deal is that on Mac OS X, double buffering is taken care of by the operating system. As you guys know, Swing is double buffered as well.

What we do to Swing is we rip out its double buffering, and we make it draw directly to our OS double buffer instead. So as far as Swing is concerned, it's drawing directly to screen. Your code will still look like it's drawing double buffered because we manipulated the Swing state so that it says what it does, which is that it is double buffered, even though the double buffering is implemented differently underneath.

Then we tell the internals of the Swing code that we're single buffered so that they don't create images everywhere. Not a big deal from your level, and the JCK also agrees that we're double buffered like we're supposed to be. So that's good. Everything works the same. The difference is, though, is because it's an OS double buffer, we get two things. The first thing we get is that the Quartz engine does dirtiness for dirty region detection. So we can't get rid of dirtiness.

We can't get rid of the dirtiness. We can't get rid of the dirtiness. So we can't get rid of the dirtiness. So we can't get rid of the dirtiness. As I said, we take care of Swing. A lot of people did double buffering in Java out of Swing. It's really important that you examine your code and get rid of that because you're triple buffered right now. So that's a memory thing, which, as all of us know, memory is the biggest thing to deal with in Java.

We don't want to be any bigger than we have to be. And especially with a real virtual machine underneath us and a real virtual memory system underneath that, memory can be kind of a sketchy thing when you're always going to have the right amount. What you don't want to do is triple buffer for performance. And then use all that extra resources and end up hitting the disk. So that's bad. So that's cool. I'm not good at this.

Oh, I think I turned it around. So anyway, next thing is live window resizing. We have that on as a feature for 10. It's as much a feature for you guys as it's a feature for us. We do our job in our apps and in our services to make this as easy as possible, but certainly it's true that if your main panel takes six seconds to render, it's not going to be live.

Just pointing this out, because it's different than other platforms. Of course, if you're doing a big complicated scene, like maybe a terrain render or something, you can do a simple quick pass, or you can keep the thing from last time and stretch it or something. There's a lot of games you can play.

A few more. This came up in our list, so I wanted to point it out. All graphics objects are created equal. Every graphics object is the same class in the system. They're all 2D objects. It doesn't matter where you get them. They have different implementation plug-ins underneath, but that's all invisible to you, and there's really no way for you to affect that.

So every graphics object can be casted to a graphics 2D. Again, that came up in the list. That's why I'm mentioning it. Also, the more complicated the clip, the slower the graphics speed. That'll become really apparent in a sec, but I hope it makes sense. Actually, just to be real clear, the other UI frameworks always use the painter's algorithm, which is the draw my guys who are my parents first, draw the children last, so they don't have to deal with clipped rendering. And Swing does that as well. Swing is like Power Plant.

Mac App and Cocoa, they all do the same thing. They use the painter's algorithm. ADBT, for reasons, long, complicated reasons, some of which I agree with, some of which I don't, has thread-safe pre-clipped rendering. So you can actually, just to be real clear, you can stick two heavyweight buttons in a parent view and make three threads and have them all render into the children and the parent all at the same time, and we'll clip it all for you and make everything work. It won't always be fast, though. So, um, it's better to watch the clip.

Don't draw through too much clip. Watch out for too many repaints. I know that's obvious, but we all know of many examples where we're pinning way more than we need to. And especially with double buffering, because there's not as much flicker, you tend to maybe miss them. So, certainly we have, that's one of the things that we're always working on, too. So, So last thing, of course, is profile. Then cache the expensive stuff.

Metrics is one of those ones that's been around for a while. If you have one of those complicated views, I don't recommend double buffering, but I can imagine in some weird cases you would do that just because you've got one piece of thing that you just want to render. For example, maybe you want to do a really beautiful icon that has a piece of artwork and maybe some tags on top, sort of like what Mail does.

They put that stamp on top with the little five or whatever mail messages you have. Maybe you want to do that and then throw that into an image because you just don't want to have that code execute. That's one way to save yourself some computational time. So those are all things you can do.

So, this is the third section. So that's it for tips and techniques for now. This is really exciting. This is our new update, and it's momentarily available as a DR release, DP release, developer preview. And we're really excited about this. We've been working really hard this fall. Excuse me, this spring. Seems like the year goes by really quick, I guess. This spring. And a lot of the stuff that we really wanted to get into Mac OS X Final is made in here. And we're really excited about it. Three things.

Cutting-edge technology, which you'll see in a sec. Much better correctness. We've been working very hard with our partners to iron out our wrinkles that we have in Mac OS X Final. And then performance. Performance has been a big deal. John, the update's live now. The update is live now. Yay.

So that's great to hear. So this is some of the things that we concentrated on the update. Heavyweight ADBT was a big thing that we had an issue with. I feel for Mac OS X Final, specifically properly rendering deep hierarchies of heavyweight ADBT panels, et cetera, with card layouts, et cetera. We worked really hard to get those bugs ironed out, and I think you'll be pretty happy with how far we've come. Swing, we've made a lot of progress.

Leanne Rucker is a person who is a Sun employee who works on our campus and bleeds the rainbow colors, I think, more than we do. And she's been working very, very hard on making our Aqua look and feel really amazing. So that's been really great. You'll see some of the results of that in a little bit.

Printing works much better. All the image formats will be supported when we ship. We made some progress on there. This update, they're not all in. They will be in when we ship. Those are those ones that I was mentioning earlier. We'll get to those real soon. And we've wiped out a whole bunch of bugs. We're really interested in your feedback on this release because we're going to push real hard to get the rest of them nailed. So, more on the update. Oh, here we go, the demo. So what we're going to show you here is a side-by-side before he starts it.

So, we're We've been working really hard to hardware accelerate Java Graphics. So what you'll see is a before and after of the hardware acceleration. So Gerard, why don't you do the software first? And we just did some, I just picked an image off my disk. But what we did here, this is important, is, as we'll talk about more in a minute, we picked the primitives that are used a lot in UIs here for our testing, and this is actually a result of a piece of code that we had for doing profiling.

So we did, as you may be able to see on the screen, we did images, rectangles, lines, and glyphs, glyphs being text. Those are the four most important things in the UI. So what's important to me, and those of us who have been working really hard on this, is that this is actually what's important for UI rendering. So now we can do the hardware. So, a little bit faster. Thank you.

So, ten times faster in text lines. I'm not even sure what that ends up being. That looks like a hundred times faster. For rectangles, we're talking ten times. Images, we're talking more like, that's a big number, 200 probably. That's possible because of the stuff we'll talk about in a minute, and it'll become more apparent of where that performance comes from. So you want to hit the hard-roll one more time, just in case they missed it? - Okay. - Ray. - Okay. So let's go back to slides, right? Yeah, back to slides. So I'll talk about how we did that and why, et cetera.

So, first of all, here's the other number that's interesting. This is the caffeine mark for Mac OS X. We went from being kind of slow to pretty competitive. This is really exciting. We're the only platform with hardware-accelerated swing. and John Burkey: That's because of the double buffering thing I talked about earlier.

The reason why is that because we removed the double buffer from swings code, where they actually allocate an image and then render to it, and we use the OS, then over the summer and the fall and the spring, it took us a while to get this all worked out, we switched to a hardware buffer so our hardware pen can render into the back buffer. So you get the advantage of a double buffer where you don't get to flicker all that stuff, but you also get the advantage of a hardware pen.

We worked very closely with Peter Graffagnino's Quartz team on this. They were very, very helpful. In fact, we went to SIGGRAPH with them last year and started talking about this over interesting New Orleans drinks. And had a base plan then and started talking about how to do this. And then we started designing an architecture that would handle the kind of things we need to do here. So, of course, double buffering, as I mentioned.

So this is what we've done. This is sort of the details. All primitives are hardware-accelerated. What that means is lines, rectangles, ovals, recent event. All those things that you do, they're the methods hanging off the graphics object. They're all hardware-accelerated. 95% of all text rendering is hardware-accelerated. And I'll talk more about that in a minute. I say 95% because we will back down on either hard ligature cases for nationalized text or very large fonts. That's because we build hardware caches in VRAM for our glyphs.

And so we don't want to build hardware caches with fonts that are this big, right? That would be a really big hardware cache. So we've backed down on those cases. And general path tessellations being done right now, that's really cool because especially for polygonal shapes and then moving towards the general path cases, we'll be able to hardware-accelerate those too.

So I'm really excited about that because I think it would be great if we had the Java 2D API and all the power it gives you in terms of being able to specify really great things visually and actually have it in the system. So we're excited to have that hardware-accelerated. That would be sort of a first in object APIs. And then hardware double buffering, as I mentioned.

And the fourth one's very important. This is actually our biggest sweet spot. We upload all static images and even have image dirtiness detection in there. So as long as you don't grab the pixels directly, We can tell if you rendered to an image recently, and we will only upload on demand as you dirty the pixels. So what this does is keep our bus traffic to a minimum and draw basically blit images from VRAM to VRAM.

That's what the cards are really good at, so you get optimal performance. That's why we get 200, 400 times, you'll see some more demos in a sec, difference in artwork rendering. That's really important, because although it does make good demos, it also speeds up your UI. I know some of you probably saw the JBuilder before and after where he showed that he could slide the slider back and forth. What was cool about that was that the way Swing implements the slider is it actually repaints the entire view on each side of the slider. So when we accelerate that, and it's that much different, that means we've basically accelerated the whole UI by that amount.

So it's not some simple blit. It's not like a scrolling operation. And that's because when you have separators like that, they could choose to scale their content based on size. They don't have to slide it out of the way. So that's really important. We may go over that again in a minute too.

So, the reason why we did this, we took careful measurement, profiling typical apps with our profiling tools last summer, and we built prototypes in the summer, and basically post the New Orleans SIGGraph, we built prototypes with the guys on the Quartz team. And then, based on that information, took some other easy wins and tried to find out if we could actually do this.

At that point, we re-architected the graphics subsystem so that we could plug in separate engines, and we'll get into that in a sec, and then started profiling our UI rendering system because if you want to seriously render UI, you have to let it have access to the hardware pen as well. So, we'll get that in a sec, too.

We did a project plan So here's the new Java 2D implementation. The main things to notice are, there's sort of two things I want to talk about here. The first is that from your Java app, you basically talk to sort of the graphics system you've always dealt with, but then what we do underneath is we plug in different pens based on what surface you're rendering to. So we've got a printer pen on one side, we've got the hardware pen on the other.

Printer pen generates PDF, hardware pen generates calls to the hardware cards. And then the guys in the middle do the stuff that's actually very similar to the printer pen, that they generate PDF-like stuff and renders to those surfaces. That's very important because we manage the graphics state separately from the actual rendering so that we can switch pens on the fly and that we can pick the right tool for the job.

And then this middle section is very important too. As I was mentioning, static-accelerated Java graphics are very important. They're very important to us. They're very important to us because they're very important to us as well. And static images are cached in hardware and glyphs are as well because glyphs are really images, right? What we do is we pre-render our text using Quartz into a hardware cache and then we use the engine to put it to the screen on demand.

So it's, in effect, another hardware cache, just like an image. And we try to manage that as well as we can so that your images are hot, so that your UI renders quick. And then the primitives, as quickly as possible in the screen case, get to the hardware pen and execute card calls. So that's that. If you have questions about that, we can talk about that in Q&A.

So this is the second part of the piece. And after we built the first part, we ran into a lot of profiling with--

So, this is where I, my other tips and technique thing, which is great for a lot of reasons. I know it's always been true in the past that ADBT was the fastest way to do stuff on your platforms, but as of now on Mac OS X, Swing will always be the fastest GUI framework to use for Java. It will always be faster than ADBT. The reason why is because we put a hardware surface across the entire window and render with a hardware pen basically always if Swing is active.

We will turn our hardware pen off very quickly if ADBT is active. Only real simple hierarchies will work. That gets back to the clipping thing. We fall off very quickly if the clip gets complicated because hardware surfaces are rectangular. So, we're sort of, that's just how it is.

I think the good news is that Swing is really fast, and it's very competitive with any other Swing implementation anywhere. The bad news is that ADBT won't be accelerated that way. There's just not much we can do there. So, that's pretty important. Swing will always work best first because, again, the rendering path is very simple. It's painter algorithm like the other UI frameworks, and the state is much easier to manage.

and David It's a much richer UI framework, so there are some serious advantages to using it over ADBT. I think you guys all know that, but what's cool is now it's actually the faster one too. And it uses the same rendering layer for the widgets as ADBT does. So in almost all cases, you'll be calling the same rendering code anyway, so there's not really much point to using the peers. So, I'm just going to show an example of that.

Yes, it is. Okay. So this is a little sneak preview of what will happen next. This is a piece of code and it's a swing app that I built in JBL using their wizards. And I'm just going to cheat and just go like this. You can see my cursor. I'm going to take this J panel and make it into a panel. And I'm going to run.

Did I hit right? Yeah. The image will take a sec. This image is 11 megabytes uncompressed. and so I don't know how many of you recognize this image, but one of the hardware acceleration talks was using this yesterday, so we thought it would be cool to use it too.

Anyway, this is with a heavyweight peer sitting in the middle. So, you know, it feels kind of fast, maybe. It's so hard to know with these kind of demos until you see the before and after. So what I'll do is stop it. and you'll see what it's supposed to be doing. So now I'm gonna go back here and I'll just do one do. Just a sec.

So again, all I did here was I just made it back into a swing panel. So that means it'll be a normal swing setup. The frame that contains it is a J frame. That's a swing frame. And this image panel, which is a real simple piece of code, is a J panel.

So that's normal swing. So now you'll see how it's supposed to work. Oops. So this is what you should expect. And this is what you saw yesterday at the hardware acceleration demo. Big image took a sec to load. You see the CPU. It's a busy boy. It'll be a sec here.

and David So, a little bit better. So, I know that's sort of cheating because I took a swing app and made it into an ADBT app and then turned it back. So, that's obviously, if you have ADBT apps, you'd have a lot more work to do. But the point is there is light at the end of the tunnel. You do get speed out of it in addition to all the additional functionality. So, I think that's a pretty good reason to think about it anyway.

Back to slides. Oh, oops. Did I do that? Okay, so actually, we're going to go to our next demo. Come on out, Scott. And I forgot, this is the surprise demo, which is why I was surprised, too. So this is what happened. Yesterday, we saw the hardware acceleration demo, and we thought it was really cool. They showed that 11 megabyte, 2,500 or so by 1,500 pixel image, that's what we were just rendering that fast, being rendered very fast by hardware. So we thought, really cool, we'll do that, too.

So we rigged it up, and then about 10.30 last night, which is why we looked a little tired, we thought, well, geez, actually, we have a 1.7 gigahertz P4 in our office. So why not see how fast it does at the same thing? So this isn't a benchmark.

This is just, we had a machine, and we said, well, let's rig it up. So Scott's on a Dell 1.7 gigahertz. Oh, yeah, can we switch to the demo machines, the split? We'll go back in a minute. So, Scott's on a 1.7 gigahertz. You got a mic you can talk about.

I'm getting about a blazing 7.3, 7.7 frames per second. He's at 305. Go ahead, Gerard. I'm getting around 300 frames per second. Well, 400.

It's not really fair. So what this demonstrates is that there's an architectural performance issue here. Because we use static image VRAM upload, we can actually deal with very large images very effectively. There's very little bus traffic going on. And because the hardware cards do this kind of operation natively, we take advantage of them. The other implementations may do that someday, but we're doing it now. John? Yeah. We have one more thing we want to show. Go ahead, sorry.

Surprise. We developed this actually on John's PowerBook. And Gerard wanted to show you guys. Because we're running on this really cool machine. I think it has a video card in it. But that's the Rage 128 Mobility. And you can see the frame rate is almost identical. Can you read what it says there? The frame rate is almost 500 frames per second. And this is Rage 128 Mobility. OK, so it's higher than what we're getting out of this thing. It's not dependent on having a huge-- Can you see it now? It's the same demo.

So this is architectural performance. As I said, our software is built differently. It's optimized because of the engines we have underneath us on Mac OS X, and because of that optimization, we make it an unfair race. Our CPU and our graphics card work really well together, and that's just how it goes on Mac OS X.

That's it for the demos. I just want to close with a slide on... So, sort of three things. The promise of Java and Mac OS X. Of course, you just saw performance. We have an object framework access to Quartz. That's really cool. You've got easy objects to use to a great Quartz API. You've got Swing, which is a very rich cross-platform UI framework. The code runs anywhere. So, we'll go to Q&A. We'll take any questions.