Chris Campbell's Blog

Five More Easy Pieces

I'm sure you're all sick of reading my blogs at this point, because each time I state definitively that the OpenGL-based Java 2D pipeline is "now better than ever," only to follow it up a couple months later with a blog that says, "no really, this time it's even better," and so on. It reminds me of a nearby store called "Cheaper Then Cheaper Cigarettes" [sic]; can you really improve on "cheaper" like that?

Anyway, at the risk of sounding like the boy who cried wolf, as of Mustang b92, the OGL pipeline is now "better than better", one might even say it's superfantastic. In the spirit of my recent "Five Easy Pieces" entry, here are five more reasons why the OGL pipeline is better than ever...

OGL: scrolling is extremely slow on Nvidia boards
(Bug 6298243)

This bug frustrated me for a number of months, but I was confident that the Nvidia driver engineers would be able to come up with a solution as they've done with so many other issues. Unfortunately, the problem is specific to the way data is laid out in texture memory on certain Nvidia hardware, so a simple driver fix wasn't possible. However, they were kind enough to offer a (somewhat odd) workaround of using the GL_ARB_texture_rectangle extension, since rectangular textures are laid out more efficiently on said hardware and therefore do not exhibit the performance issues reported in this bug.

It took quite a bit of work, but the good news is that we were able to get support for the GL_ARB_texture_rectangle extension implemented for b92, so scrolling/dragging performance is back to normal on Nvidia hardware, for both pbuffers and framebuffer objects (FBOs). As an added bonus, the use of that extension allows us to use less texture memory since we no longer have to pad up to power-of-two sized textures on older hardware. (This is what Michael Scott would call a "win win win" situation.)

OGL: enable sun.java2d.opengl.fbobject by default
(Bug 6439320)

Another big benefit in fixing the previous scrolling performance bug is that it removed the last big barrier that prevented us from enabling the FBO codepath by default. (I mentioned the FBO codepath in a blog entry from last autumn. Note that since then, Ken Russell and I managed to get JOGL's GLJPanel working with the FBO codepath, so that is no longer a barrier.) So as of b92, we've enabled the FBO codepath by default, which has many benefits when compared to the existing pbuffer-based codepath:

• Reduces costly context-switching overhead. This has helped to improve SwingMark (an internal Swing benchmark) scores by 15-20% on both ATI and Nvidia hardware, when compared to fbobject=false.
• Greatly improves performance when rendering VolatileImages (especially when applying an AffineTransform).
• Decreases the amount of VRAM consumed by VolatileImages, due to the fact that we have more control over which buffers are/aren't created.
• Improves maintainability, since the extension is cross-platform and not tied to any windowing system-isms.
• Works around a number of pbuffer-specific bugs in ATI's drivers, most notably the one that causes a HotSpot crash when exiting an application.

If you've been been bitten by the OGL pipeline in the past (especially those folks with ATI hardware), I'd highly recommend installing b92 for this change alone.

OGL: use new AffineTransform methods in enableGradientPaint()
(Bug 6434670)

This one's not terribly exciting... Just a three-line change, but I wanted to mention it in case folks are not aware of some new convenience methods added to the AffineTransform class in Mustang. The first is AffineTransform.invert(), which is useful in those cases where you want to invert the transform matrix in place (hence no need to create a new AffineTransform object). The second is AffineTransform.rotate(vecx, vecy), which is helpful when you want to rotate about a vector (instead of using a relative angle value).

In this particular case, the old code was not a major bottleneck in the gradient/texture acceleration path, so there wasn't a huge performance benefit. However, if you have some code that exercises AffineTransform heavily, you might want to check to see if these new methods give you a boost.

OGL: accelerate Gradient/TexturePaint when antialiasing is enabled
(Bug 6436942)

This one is terribly exciting, to me at least. We've had some nifty acceleration for GradientPaint and TexturePaint since the OGL pipeline was introduced in JDK 5, but it always came with the caveat that only non-antialiased primitives were accelerated. But as of Mustang b92, we've figured out a way to use multitexturing to combine the gradient/texture acceleration code with our existing antialiased rendering code, which means GradientPaint and TexturePaint are now fully accelerated by the OGL pipeline, regardless of whether antialiasing is enabled. The bug report has more details, but I'll include the executive summary here, because the numbers speak for themselves:

• Up to 25x improvement for antialiased TexturePaint operations
• At least 2-7x improvement for antialiased GradientPaint operations
• No significant impact on existing accelerated operations

OGL: overlapping LCD glyphs not rendered properly
(Bug 6439274)

This was a visible problem caused by an obscure bug, but fortunately the fix was easy. It was the last known problem with the LCD text acceleration code mentioned in my last blog on the subject, and the driver bugs mentioned there have since been fixed as well.

So if you're a fan of LCD text (meaning everyone but Scott, wink wink) and you have shader level hardware (Nvidia GeForce FX/6/7 series, ATI Radeon 9500 and up, etc), please try -Dsun.java2d.opengl.lcdshader=true and let us know if you see any problems. I'm fairly confident that things are working well, but it hasn't received quite enough testing yet, so we're not planning to enable OpenGL acceleration of LCD text by default in Mustang. Assuming all looks good in the next few months, we can consider turning it on by default in a Mustang update release.

Bonus: The Driver Report

As I've mentioned in past blogs, we've been working with driver teams from Nvidia, ATI, and Sun to ensure that any remaining driver issues are resolved by the time Mustang ships. We have updated our basic acceptance test (BAT) suite with over 50 tests that said driver teams can use to prevent the introduction of new regressions and to test that their existing drivers work well with our OpenGL-based pipeline.

For the past couple years, ATI's drivers have been in a sad state of affairs w.r.t. our OGL pipeline (lots of crashes and rendering artifacts). However, I'm now happy to report that ATI has fixed the remaining Linux-specific OpenGL driver bugs that affect our OGL pipeline, so our BAT suite now runs without failure on their forthcoming 8.27 series release. If you're a Linux user with ATI hardware, I'd suggest upgrading to 8.27 when it becomes available in the next couple weeks.

As for ATI's OpenGL drivers for Windows, some bugs remain and we are continuing to push those with ATI. But as I mentioned above, the change in b92 that makes the FBO codepath the default means that most of those bugs are no longer reproducible for most newer boards.

On the Nvidia and Sun fronts, things are looking really good. There were a couple driver bugs found recently on certain Nvidia laptop GPUs that have since been fixed. If your laptop has an Nvidia GPU and you've been seeing weird artifacts when enabling the OGL pipeline, please install Nvidia's 95.xx series driver when it becomes available in the near future.

In my ears: Viktor Vaughn, "Vaudeville Villain"
In my eyes: Edward P. Jones, "The Known World"

Comments

• You are totally wrong about one thing though.

  This: "I'm sure you're all sick of reading my blogs at this point, ..." ;)

  Posted by: mgrev on July 21, 2006 at 02:59 PM

• Twinkle still doesn't run under on (perhaps oldish) ATI card (even with that new fbobject thingy). Maybe JOGL / Java2D integration isn't as ready for mass development as it's implied to be. Not only the latest Mustang (which is fine with me), but changing the graphics card??? This seems like a Microsoft "new OS" tactics :(

  Posted by: kirillcool on July 21, 2006 at 04:22 PM

• Chris: I owe you some chocolate cake man!

  Kirill: Twinkle *does not* need the JOGL/Java2D bridge to work properly.[ And I indeed had many many problems with ATI drivers when I developed Twinkle. Believe me, ATI's OpenGL support for non-gaming apps is really flaky :( Before your blame the OpenGL pipeline, try without it and be sure it does not come from JOGL or your graphics drivers (in which case you could find a way to rewrite my code to make it work.)

  Posted by: gfx on July 21, 2006 at 04:40 PM

• Romain,
  This wasn't intended as an "attack" on Twinkle. It's just that the JOGL / Java2D bridge is hailed as the next big thing, and then you see those small comments such as "for most newer boards". You don't expect me to shell out 500$ on a new graphics card just to run Aerith, right?

  Posted by: kirillcool on July 21, 2006 at 05:14 PM

• 
  @Mikael: Thanks for the ego boost :)

  @Romain: Yes, please! We're going through withdrawal...

  @Kirill: What kind of ATI board do you have, and what's your driver version, and what's your OS, and what do you mean by "doesn't run" (crashing, artifacts?), and as Romain asked, do you have the same problems without Java2D's OGL pipeline enabled? (Also note that the FBO extension isn't available on all boards, so it may not make a difference for your configuration.) I'd be happy to work through the issues with you. I can promise you it doesn't take a $500 graphics card to run this stuff, even a $10 GeForce 2 should work fine.

  Posted by: campbell on July 21, 2006 at 05:59 PM

• Kirill: I never took this as an attack against Twinkle! I was defending the OpenGL bridge (which is different, by the way, from the OpenGL pipeline). Aerith does NOT need the bridge, nor the OpenGL pipeline to run successfully. Actually, Aerith, as provided on java.net and as shown during JavaOne, uses the Direct3D pipeline. So once again, don't blame the Java2D team work unless you know for sure where the problem really lies.

  So: you can run any Swing application with the OpenGL pipeline and you should, mostly, be fine (the LCD text bug for instance, is very annoying and can be worked around pre-b92 with intermediate images, that's what Twinkle and Aerith do.) In this case, Swing is rendered with OpenGL.
  The Java2D/OpenGL bridge is used when JOGL and the OpenGL pipeline are used together (plus some code magic, like the CompositeGLJPanel from Twinkle.) In this case, JOGL basically "inject" stuff in the OpenGL pipeline, avoiding unecessary round-trips to the graphics card. The main purpose of this bridge is to get better performance. Twinkle and Aerith run perfectly fine without it. They also run fine without the OpenGL pipeline!
  Now, try to run the non working thingies with the various command line flags (the most important one being -Dsun.java2d.opengl=true) and then you can tell us exactly what does not work in which situation.
  Finally, and I'm repeating myself, ATI and nVidia drivers ARE buggy. They are definitely optimized for games. There are things that the Java2D team just cannot fix in the Java2D's OpenGL pipeline.
  Remember that Twinkle, and therefore Aerith's 3D component, has been developed on a 4 years old laptop (with an ATI Radeon 7500 graphics card and drivers that have never been updated since I bought the computer.) It worked (and believe me, I cursed this hardware quite a lot). As Chris just said, you don't need a recent graphics card. But you'll get rid of many drivers related issues and get better performance.

  P.S: For instance, with my 6 months old Sony laptop, equipped with an nVidia GeForce Go 6400, I can see a black line going from the lower-left corner to the upper-right corner of the photos in Twinkle when I activate polygon antialiasing. This does not happen with my MacBook Pro's ATI Radeon X1600. And it did not happen with my old ATI Radeon 7500. Now tell me, who should I blame? :p

  Posted by: gfx on July 21, 2006 at 07:00 PM

• Nice work, I just can't wait for Mustang's release!

  Posted by: commanderkeith on July 21, 2006 at 08:34 PM

• Another brilliant blog Chris. I read your blog entires and the bug reports and find it all facinating even though I dont have a clue what any of it means!

  I work on a graphics intensive application (lots of large translucent images) and the OpenGL pipeline makes a huge difference on my desktop machine (nVidia board). Unfortunately it doesnt work at all on my laptop, which has an ATI Mobility Radaeon 9100 IGP graphics, maybe just a year or two old, and the VM crashes entirely. =(

  Still, I'm grateful for all your work.

  One question, will the new MultipleGradientPaint be accelerated by the pipeline?

  Posted by: benloud on July 22, 2006 at 01:40 AM

• I might be really not lucky because I installed the b92 a few minutes ago and I have a crash of the JVM when I run my jogl program.

  My notebook is a "HP compact nc6000" with a "ATI mobility Radeon 9600 Series".
  

  Posted by: karmagfa on July 23, 2006 at 04:26 AM

• Correction: once I stop to use my second 19' screen, there is no crash. The crash was probably due to a low amount of video memory available.

  Posted by: karmagfa on July 23, 2006 at 06:16 AM

• Is anybody testing all this goodness on the high end? My workstation desktop is 5120 x 1200 x 32 bpp. d3d/ddraw is useless. openGL is even worse.

  Posted by: gdarke on July 23, 2006 at 07:33 AM

• Well, you may be a bit too optimistic about the state of OpenGL LCD rendering ;)
  Testing b92 on my 1680x1050 LCD monitor, lower half of the glyphs seems to be corrupt (as if blended over black instead of the actual background...). ATI Radeon 9800 with latest Catalyst 6.6.

  Posted by: hlavac on July 23, 2006 at 09:31 AM

• @benloud: Re: ATI laptop graphics... At Sun we can only do a limited amount of testing on laptops since we don't have gobs of money to spend on a lab full of laptops. The best we can do is hope that colleagues (and helpful external developers, like yourself) have a range of laptop chips and test things out that way. And the BAT suite I mentioned above is helpful in that ATI and Nvidia can test our stuff on a much wider selection of boards (including laptop chips) and catch/fix any issues before we see them.

  All this to say, I'm not aware of the crash that you're seeing on your Radeon 9100. Could you email me at christopher.campbell at sun.com with more details? This goes for Kirill and any other folks too reading these blog comments. It's easier to have an email discussion with you than to turn this blog into a bug database :)

  Re: Linear/RadialGradientPaint acceleration... We're working on it, but it's too late for Mustang at this point. I'd like to get it into Dolphin early on and then backport it to a Mustang update release. It's not as easy to accelerate as the basic Gradient/TexturePaints, but fortunately shaders make this feasible.

  @karmagfa: Even if you have a low amount of VRAM, it shouldn't crash. Is the crash reproducible in non-JOGL applications, like SwingSet2 or Java2Demo? Is it reproducible in your JOGL application if you disable Java2D's OGL pipeline? (As I said above, please email me with this info and I'd be grateful to work through it with you.)

  @gdarke: 5120x1200? On a single monitor, or spanning multiple ones? We do test on a number of high-end boards, including multimon configurations. You'll have to give me more details. Just saying it's useless or worse doesn't give me an idea of what's going wrong. What kind of board is it? Is it crashing, showing artifacts, etc?

  @hlavac: The bug you're seeing is one of the ones I mentioned that are fixed in ATI's upcoming 8.27 release on Linux. The same bug should be fixed on their Windows Catalyst drivers in an upcoming release, but I don't know the exact version. I'll try to track that down. The fact that this driver bug isn't fixed in public release at this time is one of the reasons why we didn't want to enable this by default for Mustang. Thanks for your patience :)

  Posted by: campbell on July 23, 2006 at 12:21 PM

• I have not much to say, only that I love your (and your teams) work, great job!

  Posted by: shawnkendall on July 24, 2006 at 11:25 AM

• @hlavac: I'm told by my contacts at ATI that the LCD text artifact bug you're seeing should be fixed in their forthcoming Catalyst 6.7 release on Windows. Please give it a try when it becomes available and let us know if there are further problems.

  Posted by: campbell on July 24, 2006 at 03:22 PM

• I am in no way affiliated with java desktop development (only JavaEE) but i really like the way you communicate with other developers about new stuff. I really appreciate this even i dont understand a single technical point other than that you are working on openGL stuff in Java :)

  Posted by: loge on July 26, 2006 at 07:16 AM

This work is licensed under a Creative Commons License.