Creative Creations

The Java Media Player is back on track, and I have a Web Start Demo to prove it! The reason I haven’t blogged in a while is because I haven’t made much progress compared to the time spent. I didn’t have that many problems with making things work on the Mac, except for some window ordering problems that seems to be Mac related. But creating a version without problems that worked on both the Mac and on Windows was an exercise in mind control, Vulcan style. The process was like the old game on circus where you hit frogs with a stick. Hit one and it goes away, but another one pops up…

The performance problem I reported in the last blog is all but gone. It’s not like the problem has been solved from Java’s side, I have just found a very narrow way around the problems. Let me explain.

The problem was that turning a window translucent would absolutely kill performance on Windows, for reasons mentioned in the last blog. I initially made one window for all graphics but that was way too slow since it needed it to be translucent. I now have four (4!) windows and it will be at least five before I’m done.

One window is the shadow for the main window. That window is also the main application window when you count the order and owner, strangely enough, but it had to be that way. Since the shadow should show the background though it is of course translucent. But since the graphics is almost never changed the performance isn’t that relevant.

Both sidebar windows are now normal JDialogs, but undecorated of course. They have set the shadow window as the “owner” window since it needs to be on top of it. They don’t change size when they slide, that was too slow and jerky on the Mac, it is just the graphics in the window that slides. These are also translucent and paints their own shadow. The performance here is good enough since they don’t change too much, the number of pixels are quite small and I can have full control of the painting process and optimize it like a mad pixel pushing junkie.

The main window is a normal window, but it is “shaped” on Windows and translucent on the Mac. This means that hardware acceleration will be in place for the main window, where it is most needed. You can see that it is a shaped window on Windows since the corners are pixelated. I do however have a sneaky way to solve this. I will paint the corners on the background shadow window instead, where we have translucency and thus anti aliased clipping/shapes.

If you run the Web Start demo you can see the GUI in action. Or at least parts of it. Please don’t be disappointed, it is far far from ready yet, but I have made the critical things work, things that required performance to be “enough”. There are still a lot of optimizations left to do. For instance I don’t use Romain Guy’s much faster blur algorithm for calculating the shadows, I use the naive approach with Gaussian blur, which is quite slow.

The app will need Java 1.6.0_10 on anything other than Mac. On OS X Java 1.5 is fine. I have not tested this on Linux, it will probably look like sh*t. Anyway, most things are just mockups, feel free to click around.

I will continue to update the app in place as I develop it and the same web start link will be used. Note that there are no media stuff in it at all, so don’t think it will play your mp3s, because it won’t. Yet… The app is signed with an old certificate so you will get a security warning. I will fix that when I get around to it.

The size of the whole app is 180k, most of it images, and it is pack200 compressed. If you are on update 10 that “.pack.gz” file will be used, otherwise you will have a 400k jar instead…

Well, enough babbling, just try it and let me know what you think. Is Java always ugly?

Cheers,
Mikael Grev

As you following my blog knows, I have dug down deep into the coding of the GUI. I started there since I deemed that to be the most risky part given Java’s tendency for being slow, unless you know exactly what you do and on which platform. I have coded Swing for a long time so I thought that the problems would be quite a few but I was was confident I could code around them.

Seems I was wrong, or at least it looks like that right now. Congratulations to those who left comments in the line of “Why Java since it’s so slow and unreliable on the desktop”. The reasons are complicated but I will try to explain them below. Why? Because maybe if I write them down I can solve them?

First I made a GUI with a few cool, but subtle, effects. I have created the carousel component, the totally customized JScrollBar and both optimized glow and shadow effects. Everything was really fast and smooth, much because of the hardware accelerated image blits and scales. I am very happy with the carousel, it is every bit as fast as iTunes’ Cover Flow.

The second phase was about getting the side docked pullout sidebars to work. I had several fallback options for this that all should look the same as in the screen shots. And since I develop on the Mac using Java 1.6.0_07 everything went really smooth here as well.

To enable translucency you just set the background color to a color that have transparency (e.g. new Color(0, 0, 0, 0) and the rest is handled by the Mac Java implementation. I draw the shadows myself since I needed them to look the same for all platforms. It is easier if I make everything as one big window with the pullouts as normal components (and not heavyweight windows). On the Mac this work beautifully, fast and totally seamless.

Then I switched to test on Windows Vista and XP. There were some initial problems but that was mostly because of me and small inconsistencies that I wasn’t aware of. Like that you need to constantly poll for a new Graphics object from the component you want to animate on Windows. In OS X you could hold on to the same one. No biggie.

The trick of just setting a background color to get transparency doesn’t work in Windows, not even u10. Not sure why since it is such an obvious way to do it. Instead you have to add two lines, one which is in the protected sun libs. This makes this version update 10 and later only, unless of course I do it using reflection. The lines are:

window.setUndecorated(true);
com.sun.awt.AWTUtilities.setWindowOpaque(window, false);

With those lines pixels that aren’t painted with an opaque color will have the background show through.

But.. The performance totally went out the window (pun intended). With that last line in the code the GUI turned to dough though. Even selecting a row in the JTable was painfully slow and with a very noticeable lag. Unusable even. After an hour of investigation I found out, not from the documentation mind you, that when translucency is enabled the whole component tree of the frame will be repainted for every little local repaint!!! For instance, when the cursor blinks in a JTextField the whole frame will be repainted. How stupid is that! And not only that, it will be repainted to a buffer and then that buffer will be software copied to the screen! No wonder it was slow..

OK, I fired up mail to let my favorite Sun engineers know that Java 1.6.0_10 was not bug free just yet. I was surprised that they told me that this was the intended behavior! To make things worse they first even tried to convince me that it had to be this way because of how windows works. But after a few emails back and forth it became clear that it is Swing that has a problem with rendering to a translucent back buffer and there were no resources to address that. Bummer… It “may or may not be fixed in an update”…

So, I though that, well, me being a self appointed Swing/Java2D expert I could make my own back buffer and render to it. If I create my own RepaintManager I can intercept the small repaints and only repaint what is need to my own buffer. Then copy that buffer to the Frame, which in turn will be copied to the screen by Swing. But first I thought that I might do some performance testing, to be sure. It turns out that even a GUI that takes 0.0 ms to render is too slow for any window larger than 800×800 on my 2.4GHz one year old computer. So, even if I made the perfect algorithm that was infinitely fast it wouldn’t be enough. Just add a single JTextField to a translucent window of some size (like 1280×1024) and try to edit it… translucent windows in Java makes GHz feel like MHz. Dead end.

OK, being an expert and all I was not about to give up just yet. I praised OS X’s version of Java for not having any problems in the first place and took a warm shower, which is the place where most of my ideas come to. Ping! New idea!

I can use the normal window decorations (will look worse, but still ok) and have tool like dialogs for the pullouts. I began testing and at first it looked like it could be done. But it couldn’t… It turns out that there is no way to control the z-ordering of windows/frames/dialogs in Swing. The only control you have is that you can set a Window to be “alwaysOnTop”. Not very usable since that would disrupt the interaction with the other windows on the user’s desktop. Then I tried all the modality modes. You can actually make a tool window float on top of the main window, but not below it! I must have it below since the OS drawn shadow around the Window must be on top of my pullout or it will look very weird. Also, as soon as I pressed the pullout window the main window’s title bar would deactivate which is not the intended behavior. So, dead end there as well and another few hours wasted. And I was out of hot water to get new ideas (OK, not really. (About the water)).

This is where I am now. At a dead end. I could of course release only for the Mac, but no.. That would go against the whole thing of sharing music with your friends, not many of them have macs…

Actually when I was writing this I came up with another idea. Not sure it is viable but I might try it. I can set the main window and pullouts to clip with round rectangle shape. No window decorations. That means no problem with z-order or deactivated title bars since I draw the title bar and the windows will not overlap. Of course this means that there won’t be any shadows (not an option) but that might be solved with a kind of shadow-only window that has those much needed translucent pixels. Since those windows aren’t changed much, and they don’t host that many pixels in the first place it might actually work. I’ll think about it some more…

A lot of wining, I know, but I actually thought Sun would step up to the plate and make Java a viable choice for the desktop. And when I mean the desktop I’m not talking boring enterprise apps with crappy GUIs, I’m talking media players and widgets.

To add insult to injury it turns out that resizing windows on at least Vista turned sluggish with the jump from 1.6.0_07 to _10. Look at this post for more info: java.net forum link

Cheers,
Mikael Grev

ps. For those of you that come here for the screenshots, if you have managed to get through my ramblings here’s how the Media Player looks right now on the Mac. Everything, including the shadows, is drawn with Java2D (except the album art picture of course) and it is really really fast. Even the volume control is working…

Maybe the most important part of a good media player is how usable it is and how good it looks when minimized. Ultimately you should be able to do everything you can do with the full interface yet the real estate should be as small as possible and never be in the way. Obviously there is a lot of hard decisions to make since we don’t live in the ultimate world. Yet.

Currently I have two smaller versions of the GUI. Mini and micro. They should both be dockable to a side of the screen where only a “tab” will be visible when it is semi-hidden. Not sure if that tab will show any info or expose any functionality though. This might even have to differ depending on the platform. There are also the mini-icons available in almost all OS and I don’t want to make a special case for using this media player, so it should play nice with that too.

In the screenshots both versions have the bottom attached see-through pulldown panel. They’re there for the time being but I am unsure if they will make it to the final version. I’m worried that it will look a bit too cluttered, especially for the micro version. Opinions are appreciated.

I have made some smaller changes to the main window as well. Nothing much but I post a screenshot anyway. Changes are mostly around the scrollbars, media add buttons, and I have added a new, or possibly alternative, left panel in the tracks tab. It is a filter panel and only what’s selected will be visible in the tracks list. Normally the user shouldn’t have to be bothered by the actual physical location of the media files, what’s playable is there, but power users and more curious normal users must have an easy way to know what’s where. The acute reader might notice that there seems to be no obvious way to once you have started filtering go back and “show all”. This is something that needs to be resolved. Possibly with a button that is only visible when there’s some filtering applied.

I have now finished the first round of designs and I have actually started coding. Wohoo! I haven’t come that far yet but many parts of the main window is there. Some might say that I am approaching this from the wrong end, starting with the GUI, but I think it’s the only way to do a really good UI. When you have no backing services, other than a home made demo collection of songs, it is easy to get the GUI right and you won’t be tempted to model the GUI after the data, which is by far the most common mistake when you see a crappy UI.

I have shadows, buttons, button glow and fast gradings done already through my already made Decorator implementation, which I have borrowed from migcalendar.com. With it, it is easy to create such effects and they are of course cached in intermediate images when needed. For shadows and glow this means always since they are created with a Gaussian blur filter. I have not yet implemented the fast version of that algorithm that Romain Guy and Chet Hasse introduced in the excellent book Filthy Rich Clients, but I will.

Talking about speed I made a very interesting discovery when I made the tracks TreeTable component. If I overrode validate() to do nothing in my JComponent subclass (used as a TableCellRenderer) the performance of resizing + repainting the JTable was increased 30 times (yes times!). Before that resizing of the window was slow as Java 1.0, but now it is actually pretty fast. This is on Leopard with Java 1.6 and I haven’t tested if the speed increase is the same on the uglier platforms.

Next week I aim for having a WebStarted demo of the GUI. Lets see how that goes. Currently I am struggling with customizing row selection in the JTable. Looks like I have to write my own ListSelectionModel. So Swing..

This is being cross posted at Javalobby and they made the first two parts into one, so this is either part 2 or 3 depending on where you read the first one (or two). The next one will be part 3 for sure though…

OK, redesign, redesign and another redesign, that is what designers do until all pixels makes sense. Anyway, no biggies but the devil is in the details and a there were a lot of details that I didn’t like. Go and look at part 1 and part 2 to see the old screenshots for comparison.

As you can see the top button labels look better now. Cleaner and more readable. I have also opted for monochrome icons with a tint for the selected button/tab. Again, it looks more clean, at least compared to having the full colored icons. I may need to recreate the icons from scratch later, to get that pure custom feel, but for now I use the excellent icon set from Icon Experience.

If you look at the second button from the left you can see that it has a slight white-blue glow. That is how the mouse-over effect will look. Of course it will fade it but it will do that very quickly, we don’t what it to feel sluggish. I have also unified the color scheme a bit. Gray-blue is the favorite color fo the day, let’s see if it sticks around to the final version.

I have removed the “track” for the scroll bar so now it looks very iPhoney (pun intended). I don’t want to be a copycat, but it looks clean. Not sure if the track should be re-enabled for mouse over or not, or maybe it will be there all the time? Not sure and it is a decision for later when we have the animations in place.

You might have noticed that the shadows have changed slightly. They are now more consistent and correct with the intended z-ordering of the main window and the side bars. Out of a performance perspective they are now also easier to make really fast.

One comment on the earlier designs was about the bottom button bar. The buttons didn’t really look like buttons. They still don’t look like normal GUI buttons but I think they look more like buttons. The easy to recognize play button will help the user in his quest to understand the GUI and what he can do with it. Usability tests will later will show if I’m wrong.

The biggest new part is the bottom bar. As I said before I didn’t want to make it white, that would make the whole GUI too blended and boring. It is still a bit experimental but generally I like the look. It should be noted that it is 60% translucent, which is impossible to see since the background is solid gray…

The main windows is now showing the newly designed tracks tab. It was harder than I first expected. Not because tracks are particularly hard to show but because they are so boring that there is little room for innovation and spicing it up. The albums on the left are all the albums to the selected tracks. Here it is very important the that loading and preparation of the album art is done in a background thread or the GUI will be sluggish at best.

Next time I will show the mini and micro version of the GUI, I promise…

Mikael Grev

The perfect media player main window v2

OK, I have redone some of the graphics. Not too much but still things that will matter. The top gray background is now striped. I think it looks more fresh. I am still not 100% confident on the new look of the track’s play progress bar. Blue made it more prevalent which is good though.

Unfortunately Adobe Fireworks does not do subpixel anti-aliasing on the text. This makes it look more blurred that it will in the finished application. Nothing to do, but it hurts my eyes..

As you can see I have added side bars. This is how extra information that you might or might not want to have visible at all times will look. The example bar is the playlist editor/player. I have opted for a Outlook stackbar look. I think it will work better than the tree structure in iTunes. iTunes mixes playlists, sources and the library in the same sidebar. I think that is a suboptimal setup as it will make it quite cluttered and too multipurpose to be really user friendly. For instance I never know where to drag stuff in iTunes…

The lower tabs (in blue) will pull out another type of sidebar, or rather bottom bar.. It will look like frosted glass and be more informational in nature. One could argue that I should go with white here as well, but that makes the whole GUI a bit too blended IMO.

The reason that the playlist tracks list looks the way it does is that I wanted to move away from very long names. The user must be shown both the track and the artist’s name, but quite commonly you will play several tracks from one artist which makes the artist name redundant for each track. Having the artist above in bold makes the tracklist look more clean and artisty and less computer-use-every-pixely, if you know what I mean.

I don’t really know how the “get it” buttons should look like and I have tested several looks, none of which makes me warm and fuzzy. You will see them change again I for sure.

I have also added arrows to the very custom scrollbar. Note that they should fade in when the mouse is over the scrollbar and then fade out again some five seconds after the pointer leaves it. Arrows will never be really “clean”, but they do serve a usability purpose in large lists.

The player should minimize nicely of course. You do not want that big window open all the time. Currently I am using a model where it will minimize in three steps. Mini, micro and nano. More on that later.

Not a title that is easy to live up to… Well, at least I am going to try. If you are interested I invite you to tag along for the ride. It is going to be some technical stuff, in Java mostly, and some design related stuff. Lets get right to it why don’t we?

What I’m creating is a Medial Player that will actually help you when listening to music, looking at pictures or watching movies. The goal is that anyone should be able to use it, even your mother, and her mother. And it should look darn good too. In all it should look better than iTunes, be more versatile than WinAmp and at least play all files that your OS plays (but probably more). As I said, not an easy task..

Design. Very Light. I like light designs. Vista black is nice too, but it’s to high in contrast for my taste. Light it is. I do have something of a blueprint in my head and I have just finished some preliminary GUI design using Adobe Fireworks.

Here is a screenshot of a first take and the main view shown when the player is in “full mode”.

Main Window (Click to Enlarge)

I am not a big fan of menus. They are a scrap heap where you put stuff you didn’t think of putting in the GUI. Therefore one of the main goals, of which there will be many, trust me, is to create a UI where you can reach all functionality directly. WYSIWYG UI…

Tomorrow I will add something sliding in from the side… Stay Tuned.