|
|
||
Chris Campbell's BlogJuly 2005 ArchivesSTR-Crazier: Performance Improvements in MustangPosted by campbell on July 14, 2005 at 10:18 PM | Permalink | Comments (18)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):
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:
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!"
| ||
|
|