Chris Campbell's Blog

STR-Crazier: Performance Improvements in Mustang

As I reported a few months back in my STR-Crazy entry, Mustang b27 included an improved, single-threaded implementation of the OpenGL-based Java2D pipeline. With those changes came improved stability and performance (surprisingly). But that work also opened the door for even more performance improvements, mainly because the code was much more centralized and easier to build on.

So with that major project out of the way, I set out to reduce the overhead of small rendering operations. By "small" I mean those operations where only a few pixels are touched, for example a 10x10 fillRect() operation. Reducing overhead of these cases is very important in improving overall Swing performance because after all, Swing typically touches small areas at a time. If you click a JButton, a small area is filled with a color/gradient, then a few lines and some text is rendered on top of that. So anything we can do to get those pixels on the screen sooner will improve perceived responsiveness of your Swing applications, and that is obviously a Good Thing for end users.

I'll spare you all the gory details, but many of the overhead reductions came with the following bug fixes (the bug report evaluations include performance numbers specific to that fix):

• 6255545: OGL: avoid redundant texture state-setting calls
• 6280588: OGL: avoid enable/disable GL_TEXTURE_2D around every texturing operation
• 6273431: OGL: improve performance of parameter queuing

These fixes all appeared in Mustang b43. With those fixes integrated, I thought it would be a good time to step back and create a chart showing just how much progress we've made over the past few months. (And JavaOne audiences always enjoy a pretty performance chart, so the timing was right.) Looky here:

This chart was shown a couple times at JavaOne 2005 but without much explanation, so here are the big takeaways:

• This chart is intended to show the performance improvements we've made to the OGL-based Java 2D pipeline in Mustang (blue bars), compared to the OGL pipeline in Tiger (orange bars) and the default X11 pipeline in Mustang (green bars).
• This of course is just a small representative sampling of operations. There are hundreds of other operations that are now much faster when the OGL pipeline is enabled, some just a few percent better than X11, and others that are 10x to 40x faster.
• These performance wins are similar across all platforms (Windows, Linux, and Solaris).
• Many of the improvements can be attributed to the single-threaded rendering project (Mustang b27), and the further overhead reductions mentioned above (Mustang b43).
• Since these operations are accelerated in graphics hardware, CPU utilization can be significantly lower when the OGL pipeline is enabled.

And now for the usual caveat: there's still plenty more work to do. Even with these improvements, there are still a few operations where the X11 pipeline beats the pants off the OGL pipeline, due to some highly optimized loops in the Xserver (e.g. small filled ovals). We'll continue to address the most important cases, so ideally the OGL pipeline will close that performance gap.

More importantly, we're well aware that these performance improvements are meaningless for your end users if the OGL pipeline cannot be initialized on their machines. I know there have been a lot of developers who have tried out the OGL pipeline on their machine and gave up in frustration due to old or buggy or incorrectly installed drivers. In some cases there's not much we can do, but we'll continue to look for ways to make the OGL pipeline work on a wider array of hardware. And as always, we're working with driver teams to improve the situation on that side of the fence. Stay tuned!

Finally, if you're interested in seeing even more improvements to the OGL-based Java2D pipeline, why not contribute some real code? You can read more about Mustang collaboration here. The JDK source tree can be daunting at first, but I'd be happy to hold your hand (so to speak) if you want to dig into the guts of the OGL pipeline code. Just drop me a line...

In my ears: Polysics, "Hey! Bob! My Friend!"
In my eyes: William Vollmann, "Rainbow Stories"

Comments

• This seems like really big improvements Chris. Good job indeed!

  I guess this will be really important if OGL will be turned on by default for non-windows. So... Will it for Mustang?

  Cheers,
  Mikael Grev

  On a side note. Is there anything happening on the Windows D3D side of thing?
  

  Posted by: mgrev on July 15, 2005 at 02:20 PM

• This is very nice, please keep it up!
  Recently I've been working on using Java2D to provide text rendering (to an OpenGL texture) for my JOGL-based application. So I'm wondering how Java2D's text rendering works with this OGL pipeline. Is it optimised in anyway? Are the bitmaps cached?
  Also, has this OGL pipeline been tested with JOGL rendering in a component at full framerate to see if there're any performance effects? How fast can the context switches be? Does the OGL pipeline take up substantial amounts of texture memory that it affects the main JOGL task? I think these are very real concerns for real-time media applications. I tried to find out with Mustang b41 but unfortunately it didn't work with my app, likely due to some transient bugs.

  Posted by: rexguo on July 16, 2005 at 10:47 AM

• Hi Chris!

  I just played a little with b43. It seems that the VolatileImage is working now (I can see it fly in my little test).

  I also tried the SwingSet2 demo but it seems there's some problems with the OpenGL pipeline: scrolling source code is very very slow. The same happens anywhere when the scrolling is involved, i.e. tabelDemo, JEditorPane, etc. What happens ?

  Posted by: mikofclassx on July 18, 2005 at 12:51 AM

• Hi Mikael, I am not sure that we are ready to turn the OGL pipeline on by default in Mustang for Solaris/Linux, but there are some nice driver improvements coming that should help stability. At this point I am confident that the OGL pipeline would be a good choice by default on a number of machines, but the trick is knowing when a particular machine meets our requirements, or more importantly knowing when to disable the OGL pipeline due to poor driver performance or robustness. We are still thinking hard about these problems, so hopefully we will have a solution soon.

  And yes, we are still making progress on the D3D side of things. We are in a similar situation (as the OGL pipeline) where there are just so many drivers that vary widely in terms of performance and quality. So again the trick is knowing when it is okay to turn on D3D.

  Thanks, Chris.

  Posted by: campbell on July 18, 2005 at 08:36 AM

• Hi Rex, text rendering is indeed accelerated by the OGL pipeline using a texture-based glyph cache. For more information see the section on Text Rendering in this article. Note that LCD-optimized text is not currently handled by the OGL pipeline, but obviously we will be coming up with a solution for that issue soon (see 6274813).

  Re: JOGL and Java2D in the same app. This depends on exactly how heavily JOGL and/or Java2D are being used in an application, so I cannot give you any specific performance numbers. And again, the amount of VRAM used by the Java2D OGL pipeline depends on what you are doing. If you are running into bugs when you mix JOGL and Java2D, please file a bug against JOGL. If it turns out to be an issue with Java2D, the JOGL guys will let us know.

  Thanks, Chris.

  Posted by: campbell on July 18, 2005 at 08:48 AM

• Hi Mik, the only change in b43 related to VolatileImages was that bilinear transforms of VolatileImages will now be accelerated in hardware on Windows. Is that the change that helped you?

  The slow scrolling you ran into is well-known at this point. With the gray rect fixes, Swing now performs their scrolling (copyArea) operations on the offscreen backbuffer, and this is known to be slow on Nvidia hardware. I have filed a bug and discussed this with Nvidia, and I hope that they address it soon, because it is obviously a huge problem for Swing apps. (By tomorrow, you should be able to see 6298243, which
  discusses this issue in more detail and includes a workaround.)

  Thanks, Chris.

  Posted by: campbell on July 18, 2005 at 09:15 AM

• Hi Chris,

  yes, VolatileImages are transformed in my test and they are now traced at hardware speed. They're not bilerped so maybe the problem has been fixed in a previous release (I did not check new releases until b41).

  As you guessed I'm on a NVidia card (FX5700). I hope they'll fix this drivers issue very soon.

  What else ? You're doing a very good job. I'm impressed. Keep up with it!

  Posted by: mikofclassx on July 18, 2005 at 10:47 AM

• Please change the way you enable/disable this feature.

  ScheduleWorld runs in the sandbox and would really benefit from the OGL pipeline (transparency issues). It would be great if a user could toggle OGL Acceleration during runtime from within the sandbox. If it works, great - leave it on. If not, disable it - no hassles.

  Thanks.
  

  Posted by: markswanson on July 19, 2005 at 08:03 AM

• 
  I ran jEdit 4.3pre2 with the command line:

  c:\java\jdk1.6.0\bin\javaw -Dsun.java2d.opengl=True -jar "C:\Program Files\jEdit 4.3pre2\jedit.jar"

  It caused the background to take on a greenish tint and the scroller on the vertical scrollbar to show up corrupted.

  
  Here are screenshots with the property set to false and the property set to true:
  sun.java2d.opengl=False

  sun.java2d.opengl=True

  
  Running java -version gives me:

  java version "1.6.0-ea"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b43)
  Java HotSpot(TM) Client VM (build 1.6.0-ea-b43, mixed mode, sharing)

  I am running an eMachines laptop with an ATI Mobility Radeon 9600, running Windows XP SP2, with the ATI Catalyst 5.5 video driver installed.
  

  Posted by: rogerhernandez on July 19, 2005 at 08:50 PM

• Hi Mark, we will take note of your comments, but it is very difficult to toggle use of OGL on and off at runtime. We are still trying to come up with a good approach for enabling and disabling our various hardware acceleration mechanisms without using arcane system properties. For example, offering a checkbox or slider in the Java Control Panel would be a good way to allow the user to control it with minimum fuss. That is just one idea though, and we have a bunch of them.

  Thanks, Chris

  Posted by: campbell on July 20, 2005 at 04:52 PM

• Hi Roger, sorry it was not a smooth experience for you. The two issues you mention (scrollbar garbage, swapped colors) have been filed with ATI for a number of months, but they have not yet addressed them in their drivers. I have forwarded your screenshots to their driver team, as they are a good example of the problems our users with ATI boards face when they try the OGL pipeline.

  If anyone else with ATI boards are feeling frustrated by these issues, please let them know via the feedback form on their driver download pages. Sometimes it helps to let them know that these problems affect thousands of users, not just a handful.

  Thanks, Chris.

  Posted by: campbell on July 20, 2005 at 04:59 PM

• Hi

  Yesterday I installed JDK 1.5.0 on my new Athlon64 machine and I noticed that the performance of Swing apps is very poor on it. The graphics card is GeForce 6200 / 256MB RAM with PCI-EXPRESS interface. The old machine's graphics card is integrated SiS with 64MB shared RAM.

  Then I remembered this article. I downloaded the latest binary snapshot and tested my system against it (with sun.java2d.opengl both turned to True and False) but the problem still remains. Indeed, with sun.java2d.opengl=True, the performance degrades significantly.

  Then I set the -Dsun.java2d.noddraw option to True and noticed that this time the new machines performs %4 better than the old one, if I set -Dsun.java2d.noddraw=True also on the old one.

  Does anybody know why Swing performs very poor on my machine? Is it because of NVidia GeForce 6200 graphics card? I've downloaded the latest drivers but, again, nothing has changed...

  Posted by: behrangsa on July 22, 2005 at 09:51 AM

• @behrangsa: The OGL pipeline should perform well on your Nvidia GF 6200 (the SiS drivers could be insufficient for our purposes though). I assume since you are talking about sun.java2d.noddraw that you are testing on Windows? What parts of Swing performance do you find to be slow with OGL enabled? The only thing that should be noticeable is extremely slow scrolling performance on Nvidia hardware on Windows; see my note above about 6298243 for more info. If there is some other area where you find poor performance, feel free to email me directly and provide more details.

  Thanks, Chris.

  Posted by: campbell on July 23, 2005 at 07:34 PM

• behrangsa ,
  I do not know if you are monitoring this still but one thing about laptops is that they, depending on setting for the driver, turn off certain parts of the gfx card when on battery power. For instance certain Java programs are almost unusable on my Dell Inspiron 8600 when on battery power. If I turn off the battery saving feature in the gfx driver when unplugged, everything is flying again.

  Just to let you guys know.

  Cheers,
  Mikael

  Posted by: mgrev on July 25, 2005 at 02:50 PM

• behrangsa,
  If you actually had a laptop that last message would have made more sense... :)

  Posted by: mgrev on July 25, 2005 at 03:37 PM

• Chris,
  I was testing the latest mustang build (b44). I found that when you open multiple windows in succession from a parent window, most of the windows are simply blank. That is the contents of the window are not displayed. The application works fine in java 5.0. Thought I would let you know.
  -Navin

  Posted by: navinkjha on August 09, 2005 at 12:52 PM

• Hi Navin,
  Please file a bug report and include a simple testcase that reproduces the problem. Also, we need to know which platform and which video board you are using. Otherwise, issues like this might be easily forgotten. Bug reports ensure that we look into and track the problem.
  Thanks, Chris.

  Posted by: campbell on August 09, 2005 at 12:58 PM

• So, does this mean that enabling opengl for java2d should improve performance for any Swing application? I have an ATI Radeon 7000 and opengl connection seems to work (connection established with -Dsun.java2d.opengl=True, but I notice a lag with the mouse movements and drawing of Swing components.

  I tried some of the Webstart demos you have on your blog (like the comparison of old/new Java2D/JOGL interoperability) and I noticed framerate speedups as expected. But with my app, just moving the mouse or resizing the JFrame is slow.

  I'm using jre 1.6.0.

  Thanks,

  Chris

  Posted by: chrisnf on January 31, 2007 at 02:36 PM

This work is licensed under a Creative Commons License.