OGL Pipeline Improvements in Mustang b92

Java 2D
#1

Just wanted to point to a blog I wrote about a number of improvements to Java2D’s OGL pipeline in Mustang b92:
http://weblogs.java.net/blog/campbell/archive/2006/07/five_more_easy.html

If you haven’t been trying out the latest Mustang builds and the OGL pipeline, please give it a shot and submit your feedback.

Thanks,
Chris

#2

The GL pipeline fails here. It renders everything correctly at first, but then freezes (almost immediately in Font2DTest, after a while in SwingSet2). Apparently the UI is working on the background, but repainting inside the window has completely stopped.

This is on WinXP, Mustang b92, GeF 6800GT, FW 91.33.

I’ve also tried opengl.lcdshader=true, captured the screen and zoomed, looks just fine (before the freezing). Btw, I noticed the fragment shader in /share/native/sun/java2d/opengl/OGLTextRenderer.c. It looks like it only does the gamma correction & blending part of LCD antialiasing and the glyph texture contains an LCD antialiased version of the glyph (in RGB). Is that correct?

#3

I tried the new version with a swing application I am working on. I enabled the OGL pipeline and the window went white. However the application still receive user input because the mouse cursor changes when entering text fields.

Fujitsu Siemens laptop
Mobility Radeon 9000

Benjamin

#4

The white screen problem happened to me when I first installed mustang. For some reason after I restarted it was OK. Maybe that’s the problem you’re having?

#5

You were about to make me a very happy man. I could really need the performance boost. Unfor… I just tried it. The same thing happend. Thanks anyway.

It is actually not a new issue. I also tried with an earlier version of mustang and the same thing happend though only part of the screen went white.

Benjamin

#6

Thanks for giving it a shot. I just got back to the office after being away from a couple weeks, so I just got to try the latest 91.33 for the first time. It did fix some earlier bugs with FBO support, but I can also reproduce the bug you are seeing. This is disappointing. I’ll report it to Nvidia ASAP. The workaround is to disable the FBO codepath via -Dsun.java2d.opengl.fbobject=false (since it is now enabled by default as of b92).

Yep, that’s basically what is happening in that code…

Thanks,
Chris

#7

Hi Benjamin,

Thanks for the report. I haven’t seen this problem before… Could you look at your ATI display properties dialog and see what driver version is installed? Also, could you check that control panel for a setting related to “full screen antialiasing” (or similar wording) and see if it is enabled? I suspect that this problem might be caused by FSAA being enabled by default, which often screws up OpenGL/D3D applications. If this is the case, does it help to disable FSAA?

If that’s not the problem, we’ll have to report the issue to ATI for further evaluation.

Thanks,
Chris

#8

The scrolling bug was annoying but now Netbeans works great. Keep up the good work.

#9

For the record, I’ve just filed a new bug with Nvidia:
242459: Java apps stop rendering (or crash) when FBO codepath enabled (91.33, Windows)

Thanks for bringing it to our attention.
Chris

#10

For the record, I can run the latest IDEA early access build with no graphical glitches or exceptions whatsoever. :smiley:

I also have lcd antialiasing enabled and it feels pretty fast (although not substantially faster than without the GL pipeline). I guess we’ll see a nice performance boost once this fbo bug is fixed.

#11

Are there any swing-mark results available which compare the opengl pipeline with the X11 default pipeline and descent default hardware (like a GF6600).

Thanks for this great piece of software, its a great piece of software :slight_smile:

lg Clemens

#12

We don’t typically publish SwingMark scores because they are dependent on a number of factors, such as the CPU, GPU, and that sort of thing. But just for comparison purposes, as in this case, it probably can’t hurt to share. Here’s a tiny bit of evidence showing how far the OGL pipeline has come in Mustang (this is on SuSE Linux, 3.2 GHz P4, ATI Radeon 9600, 8.27 beta drivers, JDK 6 b92, grayscale text antialiasing, lower is better):

X11 (default pipeline): 14420 ms
OGL (pbuffer codepath): 13681 ms
OGL (fbo codepath):     11983 ms

Again, this is just one configuration. However, similar scores are seen on other OS/platforms (Windows, Solaris), and on other (Nvidia) hardware.

Chris

#13

Thanks a lot, very interresting :slight_smile:

Well keeping in mind that X11 still does not use XRender at all (please change this in an mustang update release at least for antialiased text) I am still a bit shocked how well X11 does.
Anyway very impressive results, thanks a lot for all your hard work. Its great :slight_smile:

lg Clemens

#14

Feel free to start hacking on an XRender-based text renderer. We can’t do it all, and I’m not sure how long it will take for us to get to something like this in Dolphin.

Chris

#15

The drvier version is 6.13.10.6143 from 2002. I guess this is a bit old…

I tried to disable the anti-aliasing as well without any result. I guess I should try to find and install a newer driver and see if that will improve things.

Benjamin

#16

Sad to hear :-/

Do you know wether SUN allows dual-use of code? E.g. if I would also write some piece of stuff for gnu-classpath which I would allow to be also integrated into SUN’s JRE - is this possible?

lg Clemens

#17

Leaving IDEs aside … if you need rendering text and widgets in your app you can always try FengGUI ;D

Johannes

#18

I doubt that’s possible today (might change as we become even more open), but I’m not a lawyer. You’re better off asking the experts over on this forum:
http://forums.java.net/jive/forum.jspa?forumID=25

Chris