Symphonious

Just for my sanity, before an OutOfMemoryError is thrown, the garbage collector should do everything it can to free up more memory right? What I'm seeing now is that the JVM does a partial GC, throws an OutOfMemoryError and then decides to actually do a full GC which frees up enough RAM to get things working again.

Very annoying and I'm not sure what I can do about it. There are definitely no remaining references, but I still can't get that memory back.

If you're doing some graphic work in Java that you want to look pretty (as opposed to most UI stuff where this doesn't make any real difference), you probably want to make sure antialiasing is on for the graphics object. By default Java usually honors the OS settings for antialiasing, particularly for text, but you can get much smoother antialiasing by setting the appropriate rendering hint.

For example, originally the new progress bar I added last week didn't have antialiasing on, but in the tweaks I've done this morning (now live on our internal systems) antialiasing is on and it looks much better. It's also changed to be more dots than lines since the last post too. However, setting the antialias rendering hint for all the components in the editor simply slows everything down (rather dramatically) and doesn't actually improve the appearance anyway. Definitely a setting to be aware of but be cautious in its use.

For the benefit of my memory and those who haven't played with rendering hints much, here's how to enable antialiasing on a Graphics2D object:

g.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_ON);

As of next week I'll officially be a product manager instead of an engineer. I'll no longer be spending my days coding and for our core products I won't be allowed to make changes to them. I will however be doing a bunch of prototypes and smaller integrations of our products etc so it's still a hands on role.

Obviously I need to keep my general technical skills really high so that I can quickly whip up prototype integrations and stay on top of new technologies etc. For general technology issues like that I'll probably need to be more on top of things than I am now, and I'll wind up working in a much wider range of languages and with a much wider range of technologies. Definitely interesting stuff ahead. What I'm not sure about though is how in touch I should keep with the Ephox development team and how they are going about developing our products. I clearly need to know what the new features they've added are, but I'm not sure how much of the implementation details I'll need.

There's a couple of factors at play here. Firstly, I need to be focussing on finding out what clients want and be living in the client world more than the technical world so if keeping in touch pulls me away from that it's a problem. At the same time, when you're doing integration work, there's a lot of advantages in knowing some of the implementation details as that knowledge can give you some extra flexibility and power to get what you want done. It also makes it easier to track down problems when things go wrong. I suspect what I need to do is find an efficient way to keep my overview level understanding of the products up to date. Maybe that will happen just from the fact that I'll be in the same office with the engineering team or maybe I'll have to skim commit logs or something. I suspect I will at the very least keep a copy of the source code checked out and reasonable up to date for reference, but hopefully I won't need to actually look at it too often (otherwise we need to improve our docs).

Welcome to the blog world Brett! It's about time. Brett's the engineering manager at Ephox and we've been nagging him to blog for some time now. I'm biased, but you really should go check out the theme - apparently he's working on a post to explain the hamster….

After the whole Andy fiasco, we're making sure we out Brett's new blog early and often. So who's going to be the next Ephox blogger?

I've spent most of this week working on making the start up experience for our applet better. It should look better, take longer and most importantly feel fast to the user. The first step is obviously to profile and optimize - the faster the start up time actually is, the easier it is to make it feel fast for users. There were a few things we could do to help out there, but nothing that really made a dramatic difference.

The next thing to do is to make it look pretty. Time flys when your having fun, and it really drags when you're looking at a boring start up screen. There was a lot of debate about what this should entail. It's all fancy and Web 2.0 to copy OS X's round, indeterminate spinner. From a usability perspective that's an absolute nightmare because it doesn't give the user any indication about how much longer the process will take. So you really need a determinate progress bar, but apparently their old and boring. Sigh. In the end a few different ideas combined to come up with:

The outside bit spins in a very Web 2.0ish manner, but the text in the middle gives users an idea of how much longer before the editor's ready. Given how much effort went into this it's somewhat annoying that you really only get to see it the first time the editor loads - from the second use the editor loads so fast you hardly get to see the progress bar at all. Of course, looking at the static image I've been distracted and gone off to make more tweaks - who knows what it will look like by the time it ships…

The final challenge is making things pretty while the applet initially downloads the required Jar files and while Java itself starts up. Obviously, we can't use Java code there and most disappointingly there's just no way to know how long the jar download is going to take so we need a different approach. Sun's heavy-handed branding of Java makes it extremely difficult to display anything more than their hideous loading screen (now bright orange!) or a static image. You can't even get the image to resize to fit the applet area or center it within the applet. It just sits there in the top left corner and hopefully it loads before your applet does.

Looking at a bunch of other applets and even JavaScript based editors, the start up sequence is generally really lame. I've seen everything from a little animated GIF pretending to be a progress bar sitting just above the applet and slightly throwing out the layout of the page to greying out the entire screen and putting an animated GIF in the middle. Never mind the fact that users might have wanted to change values in other form fields, not just the editor itself. Of course, the standard technique for JavaScript editors is just not to worry about it and render in whatever order the browser manages to get toolbar icons. Usually this shows good progress to the user but it looks pretty hideous as toolbar icons randomly appear on the toolbar and the page layout shifts around during different stages of loading.

As far as I've seen what we'll have once the final few tweaks are done is the best startup sequence I've seen - the page layout remains stable, it looks elegant, fills the space of the editor enough that the loading progress is clearly the current center of attention instead of just a progress bar off at the side somewhere and still allows the user to just ignore the editor and work with other parts of the page uninhibited. It's also easy to modify if the default style doesn't work with the actual site layout it winds up embedded in. I'll be very interested to see what our clients think of it.

One thing I am really happy with is that in the last couple of days, this has been deployed to our internal systems and suddenly everyone is hugely impressed with the start up speed of our applet. The actual speed improvement is actually quite minor, but the resulting impression on the user is huge.