• Home
• Features
  • Submit an article
  • Presentations and Articles
  • JavaPolis 2004 Online
  • JavaZone 2005
  • Announcements
  • Newsletters
• Forums
  • Overview
  • Help & FAQ
  • Posting guidelines
  • Recent postings
  • Popular discussions
  • Who's online
• Blogs
  • Popular blogs
  • Start your free blog
  • Recent blog entries
• JL Network
  • Javalobby.org
  • Javacrawl.com
  • JDocs.com
  • JRoller.com
  • JUGCentral.com
  • MyJavaServer.com
  • Friends & Partners
• Members Only
  • Control Panel
  • Subscriptions
  • Downloads
  • Benefits
  • Special Offers
• About JL
  • Our story
  • Sites & Services
  • In the News
  • Privacy policy
  • Contact us
  • Advertising info
  • FAQ

What does "Swing is Slow" mean?

Recently, we have been bombarded by a series of negative postings/statements about Swing. In these postings, many argued with authority and certainty that Swing is either dead or terminally ill or it needs an extreme makeover. In this article I would like offer a different opinion.

About me: I am Java/Swing developer who also sells and supports software. I have two commercial applications written in Swing. So I have vested interest in Swing. When I see all these recent comments about Swing, I could not help posting my opinion on the state of Swing.

About Java: I believe it is the greatest development in programming languages because I finally do not need to care about memory, hardware and operating system anymore. And we have real choices. I compile my applications once and it runs on Unix, Linux, Windows, and Mainframe as is. It seems this aspect of Java is not disputed anymore.

About Swing: I guess this is where the issues and solutions are fuzzy. Four points seems to be coming up repeatedly against Swing:

• Swing is slow
• Swing starts slow
• Swing is not native looking enough
• Swing is too complicated

The arguments about “Swing is slow” are mostly qualitative at best. It is hard to pinpoint exactly what “Swing is Slow” really means. I guess it simply refers to a person’s experience with a program written in Swing. An accurate term would be “Program is Slow”, because Swing by itself does very little. GUI gets slow after one starts putting a lot of code in to the event handlers. After Java 1.4, “Swing Slow” really means the screens do not paint completely because painting is not completing due to a long task running in the event handler thread. I myself had quite a few cases where I could see a hole in the middle of the screen, or where a screen will freeze. In all cases, I fixed it by simply removing the long running tasks out of the event handler. So assuming that all event handlers are lightning fast, is Swing still slow? In this case, the question means, “ Is Swing managing the events fast enough and is Swing painting the components fast enough?” I did measure the response time of Swing alone (I explain my method below). Unless you have a very large number of components on the same screen, painting times are too small to be noticeable by your monitor, and therefore by a human being who normally communicates with the computer by looking at the monitor. Another factor contributing to “Swing is Slow” is not paying attention to code. Slow code inevitably will show up as slow GUI.

Swing starts slow: I ported (without any effort) my applications to JDK 1.5. When I start the application the first time it takes 10 seconds. The second time it takes 2 seconds (to display the first screen). My computer is a three years old laptop with 1.2 GHz CPU, 512 MB RAM, and a commodity Video card. All my reported times are measured on this laptop. The start up time is better than many native applications I routinely use, including Eclipse 3.0. My recommendation is simple: Check your code. No software gets faster by itself.

Swing is not native looking enough: This seems to be a flawed argument. I believe a better way to raise this issue would be “The majority of Swing based applications are not as good looking and they are not as easy to use as native window programs”. The implicit incorrect assumption here is that good-looking means native only. An application can be good looking and easy to use without being a pixel perfect copy of windows. The most noticeable example is Eclipse 3. Take a look at the tabs. If you really insist on native, you can pick windows look, which can be indistinguishable (from native windows) to most users. I found the JGoodies Windows look to be excellent. In my opinion, exceptionally good-looking programs (I have seen) have a custom GUI that reflects the metaphors of the user domain not the operating system. I did check the applications I use routinely: Java IDE, Media Players and Recorders, Graphical HTML Editors, Graphical Editing and Layout software, and Profiler. Most seem to have anything but a native look and feel. In short, Swing has some shortcomings, but overall it is not the reason for bad-looking applications. A great paint and a great brush do not necessarily add up to a great painting.

Swing is too complicated: Maybe. I am a fan of grid bag layout and never use a GUI designer. It enables me to write a GUI layout using constraints rather than absolute positioning. Screen looks good at all screen resolutions and screen sizes. I would say Swing is a comprehensive and general purpose GUI library. If you are writing applications where default components and GUI metaphors are not sufficient, you do not have to give up your great idea that may turn out to be a competitive advantage. It takes time and effort to master Swing.

Swing has been improving steadily. Two outstanding issues I found to be very critical are (i) Poor Fonts and (ii) Lack of a cross platform look and feel that is as good looking as Windows XP.

I usually find that when an issue becomes too fuzzy to pinpoint it is an indication that the real problem is somewhere else. Slow, bad-looking, and complicated Swing is possibly a good example of such a fuzzy argument.

How slow is Swing?

Most users interact with the computer by looking at the screen, typing on the keyboard, or clicking on the mouse. I will focus on the monitor only. The question I would like to answer is “Assuming that my code in event handlers is infinitely fast, how long does it take for a monitor to completely and correctly display the intended screen?” In general the answer depends on the screen layout. To keep this article short, I will focus on few representative screen layouts.

Monitors usually have 60Hz refresh rates. The monitor limitation to time resolution is around 17-25 milliseconds (ms). Monitor is sampling the perfect GUI at 60 Hz, which is good enough to reconstruct events happening at 60/2=30 Hz. As far as monitors and users are concerned 35 ms is as fast as it will ever get. To a user, there is no difference between a GUI painting at 1 ms and a GUI painting at 20 ms.

I used a Screen Recorder (SR) to record the screens while I was using the tested software. I wanted to use a method that comes as close to a user looking at the screen, record the screen and play it frame by frame to see how it paints. I used a Video Editor (VE) to review the recordings. If I need to, I can look at the native apps for comparison. Nothing complicated, watch the video and count the frames to find out how slow Swing is! My LCD monitor has a 25 ms response time and a 60 Hz refresh rate. Theoretically, my SR can record up 200 frames per second. And I have, in principle, 5 ms resolution. This is possible because SR is recording the screen buffer, which is (hopefully) updated much faster the screen. SR may actually show you even what you do not see on the screen. I am not an expert on the screen recorders. I did a little reading and it all makes sense to me.

I wrote a little program to test the procedure. Program consists of a JLabel occurrence whose text is redrawn repeatedly and as fast as possible.

JLabel myTime = new JLabel("0");
long t;
String s = "::";
for(int i=0; i<100000000; i++)
{
	t = System.nanoTime()/1000000;
	myTime.setText(Integer.toString(i) +s+ Long.toString(t));
} 

This program will display on the label how many times the label text is updated and at what time. I recorded the screen at 200 frames per second. The time extracted from the label text and the time calculated from the frame count are given below.

The time calculated from the number of frames and the time printed on the label is in excellent agreement. This test proves that I can use a label as a marker for time without introducing any significant error, and I can accurately determine the time between the events by counting the frames. The smallest time interval between the two different frames is 10 ms. My SR thus have 10 ms resolution, fairly close to maximum possible resolution of 5 ms.

How long does it take to display a form?

I first tested a form: an occurrence of JPanel with 10 occurrences of basic components: label, text box, combo box, radio button, and button. I added the form to right side of a split pane. To the left side of the split pane, I added a Start button to switch the form from invisible to visible state. Another button is added as a marker. When the Start button is clicked, it changes the text of the Marker button and, immediately afterward, makes the form to visible. The visual appearance of the new text on the Marker button marks the beginning of the form rendering. The final appearance of the form marks the end of the form rendering. I count the frames between the new marker button text appearance and complete form appearance to get the time to render the form. With this procedure I can measure (an upper limit to) painting time of any screen, possibly detect incomplete renderings, and the evolution of the rendering, see Figure 1 and Figure 2 below.

Figure 1. Not rendered state of form test application.

Figure 2. Rendered state of form test application. Upon clicking on the Click Me button, the panel containing the components is set to visible state. Click Me button sets the Ready button text to “Started” first, thus marking the execution of the event handler.

Desired capture rate is set to 200 frames (the maximum) per second. During recording actual capture rates were 30 frames per second. When user clicks on the Click Me button, event handler first sets the text of Ready button, and then makes the container of the components of visible. The switch between the two states of the GUI occurs within the time between the consecutive frames. The obvious conclusion is that the Swing painting time and event handler overhead of an average form is not detectable even to the monitor.

How long does it take to display a table?

I repeated the same test with a table. 100 rows and 10 columns, all string cells. I put the table into a scroll view as shown in Figure 3.

Figure 3. Test table has 10 columns and 100 rows. All cells are strings. Table is embedded into a scroll view.

Looking at the recordings clearly leads to the same conclusion. Swing overhead for an average table rendering is not detectable by the monitor.

How long does it take to display a rich GUI application?

I did record one of my applications. I would consider its GUI very rich. I already eliminated all usual signs of slowness. Again, screen painting is always complete in a given frame. In any frame, you never see a partially painted screen, or a screen painting in progress. I do not have clear visual markers of when painting starts in this application; nevertheless I believe the same conclusion holds.

What does "Swing is Slow" mean again?

There seems to no intrinsic slowness in Swing. What is slow is the rest of the program, which is holding up the Swing painting. Remember if your monitor cannot see the difference neither you can.