Win a copy of Node.js Design Patterns: Design and implement production-grade Node.js applications using proven patterns and techniques this week in the Server-Side JavaScript and NodeJS forum!

Romain Guy

+ Follow
since Sep 18, 2007
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Romain Guy

Instead of using an ImageObserver you can make sure that all of your image instances are instances of BuffereImage. A BufferedImage, contrary to the ToolkitImage, is guaranteed to be loaded synchronously.
14 years ago
Yes, NetBeans, IntelliJ, Eclipse...
14 years ago
JFXBuilder is a visual tool that lets you build complex animations visually:

No coding required
14 years ago

Dirty regions are marked dirty when you call repaint(x, y, w, h). The RepaintManager is not scrutinizing your components to find out what changed. The components/the application tell the RepaintManager what is dirty. Simply put: forget about the RepaintManager.

. If I follow you correctly, graphics operations on the Graphics instance passed to any JComponent are written directly to the back buffer, and there is only 1, large, back buffer. Is that more or less it?

That's it.

I was under the impression that there was 1 buffer per component, and that we might be disabling it by taking control of the full panel rendering space.


Now, in some cases you might want to create your own buffer for a specific component. Even though there's a global buffer in Swing, there might be cases in which Swing will ask your component to repaint itself into the buffer. At that time, your component's content might not have changed, but Swing (ie. the RepaintManager) does not know that. In most cases, you simply repaint the component with Java 2D commands (drawLine(), etc.) It is fast enough. In some cases, when the rendering code is very heavy, you instead use a local buffer.

A local buffer also allows you to do background rendering. In the case of an HTML renderer, painting can be very complex. So what you would do is this:

This technique is exposed in the book under the name "intermediate image."

In the first generation I start out with three living cells at 0,0 to 0,2. In generation 2, the model is updated so that cell 1,1 is alive. The panel is now dirty (from Swing's perspective). What is my responsibility, as component owner, to redraw? Do I have to keep my own back buffer for the panel and update the just clip for just the affected cell on my buffer, then copy the buffer back on to the Graphics instance?

The panel is not dirty until you tell Swing so with a call to repaint(). When your model changes, you need to call repaint() or better yet, repaint(x, y, w, h). You can issue several calls to repaint(x, y, w, h) and the RepaintManager will try to coalesce them by merging the dirty regions.

Then in the paintComponent method take into account the clip. This clip basically comes from the arguments you passed to repaint(). Just redraw the cells that intersect with the clip.

This is important because in some cases Swing will repaint the whole frame or the whole component, even though there's a back buffer. This happens for instance when you have a non-opaque component on top of your component (for instance, a glass pane).
14 years ago
Games also have the advantage of being able to use all of the compuer's resources without the user complaining
14 years ago
Swing applications are always rich in the strict definition of the term "rich client." A rich client is simply an application that does storage and process locally. Thin clients, like web sites, do storage and/or processing remotely.

That's why we came up with "filthy rich clients" to mark the difference between rich clients: those with regular UIs and those with animated, appealing, bewildering UIs.

To find out whether a Swing app is filthy rich or not, just use this rule: Did it make me go "wow!" when I saw it?
14 years ago
The source tree contains all the jar files you need and compiles without installing any other library except for JOGL.
14 years ago
Visual elements are also important to usability: contrasts, colors, spacing, etc.
14 years ago
Remember that Google Earth was bought and not created by Google. It used to be called Keyhole or something like this.
14 years ago
You forgot the NetBeans Plarform, which is equivalent to Eclipse RCP but for Swing.

The Swing Application Framework only helps you on the UI side. It is meant for small or medium sized applications, or for applications in which you don't want to deal with huge beast like NetBeans/Eclipse RCP. It is a nice framework you can learn in a couple of hours and that will help you write Swing apps more quickly.

I have no experience with either NetBeans RCP or Eclipse RCP so I cannot comment on that. Then again, I never worked on a Swing app large enough to justify the use of either one of them.

If you are in Europe you can try to come to JavaPolis in December. We invited the author of blueMarine, a photo management application based on NetBeans RCP. And there will be talks about Eclipse RCP too.
14 years ago
It's always a matter of priorities. Not taking care of the UI is always a short-term solution. In the end, the users will spend a LOT MORE combined time using the applications than the developers will spend writing it. Where's the gain here? Spend less on development and lose more on users productivity and happiness or the other way around?

Our book always presents the effect with a few ideas on how they can be used EFFECTIVELY. Visual effects are not only about looking good, they are also about making the UI better, more usable, easier to understand.

We also developed a bunch of libraries and utility classes to make effects easy to add quickly in enterprise applications; to save you guys time.
14 years ago

First the dumb one, how applicable is the technical substance of the book to making UI's for games?

Very applicable Many of the effects I talk about in the book were first inspired by video games. I actually often made a connection to video games in various articles on my blog (

I mean from one angle a game is just another application, but then a game UI would need to be light weight and very fast, si swing even suitable?

It depends on which part of the UI you are talking about. In the game itself, sure. In the menus, there's no problem. I have seen a few games on the web based on Swing and Java 2D and it seems to work really well.

Note: I once worked for Atari and created the UI and menus for a video game we shipped on GameBoy Advance ;-)

Rich UI's seem to be all the rage, but I wonder, if the cycles used to display the rich UI are actual worth it, and would not be better spent on processing actual data.

It depends on how much data you have to process. When I look at the CPU usage on my two laptops, it rarely exceeds a few percent (those percents are usually taken by multimedia apps to play music and video.) Let me ask you the question the other way around: is it worth having those very powerful CPUs and use only a few percent of their capacities?

A UI is always a tradeoff. I am convinced UIs need to be rich and interactive and pleasing BUT not at the detriment of the actual data processing and not at the detriment of user interaction. Yet, I would sometimes rather sacrifice a bit of data processing performance to improve the UI. For instance, any application that shows a progress bar is wasting quite a bit of CPU time. Without the progress bar, the operation would go faster. But the user would be at loss about what's going on.

are they really worth the effort and processor cost? Are menu effect actual useful? I just want my drop down to appear (with ALL menu options).

Again, it depends on how it's done. On Windows XP and Vista I disable most of the visual effects. For instance, the menu effects on Windows XP are just way too long. However, I keep all the visual effects enabled on Mac OS X. Why? Because they don't get in my way. On Vista I hate the fade/grow effect when a window shows up/disappears, because it is way too long. Would it last 100 or even 50ms less, I would love it!

Should we not be learning how to struture our UI's before we "pimp" them?

Yes, definitely yes.
14 years ago
Unfortunately no And this is a shame because most of those apps are not available from Google for Windows and Linux and OS X.
14 years ago
Forgot to answer the question: yes, it would be nice to have screenshots and webstart demos. But it would take quite some time and I don't have it at the moment.
14 years ago