Bug Description

Just updated my mac mini to Intrepid RC and java graphics performance has degraded enormously. Working in netbeans causes a 50% (1 of 2 cores) peak every time gui interactions are performed (mostly caused by Xorg). I tried disabling Compiz but that did not help.
Applets have the same problem.

I was thinking about java 6 update 10 but that can not be the cause because I was using the same java version on Hardy. So it must be a change in the Xorg - Java - Intel drivers interaction? I'm not having any problem on my AMD Athlon(tm) 64 X2 3800+ with a nVidia Corporation NV43 [GeForce 6600 GT] (rev a2).

Yes, this seems to be fixing the issue for me (Fedora 9, GM965/GL960). IDEA 8.0 looks alive :)
But it's weird, why this issue only appeared for the individual versions of some applications?
For instance IDEA 7.0.4 worked fined with EXA when IDEA 8.0 died.

A few posts above I wrote that switching to XAA AccelMethod fixed the issue in Fedora 9 (Intel video driver).
Today I upgraded to Fedora 10 and found out that XAA causes lots of graphical glitches and makes Gnome not working.
So under F10 I've got to switch to EXA again and make a choice - working Gnome OR working IDEA 8 :-((((

So, I'm staying at IDEA 7.0 which is working properly regardless the AccelMethod and OS version.

It is related to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6708580 as well as the entry on my blog. Its caused by switching to EXA by default in later Intel drivers, as well as poor X(Shm)GetImage performance.
This problem occurs when switching between hw-accaleration and software-rendering.

I contributed a small fix to completly disable hw accaleration as a workarround which should avoid those worst-cases, it has been integrated in JDK6u12b03 pre-release, would be great if you could give it a try: http://download.java.net/jdk6/binaries/

This is not a simple bug, its an architectural change. The intel dirver switched to EXA, which means hw accaleration.

Although the intel driver does *really* bad with readbacks, this is also java's fault.
JDK7 hopefully will include the XRender based backend I am currently working on, which will even bring hw accaleration to java (instead of trying to make software-rendering faster, like my patch does).

Java does quite often fall back to software rendering, where it has to access the image-content with the CPU.
With XAA image contents were in RAM (because XAA offered almost no hw accaleration), and java was able to access the image very fast with the CPU.
Now with EXA images are stored in VRAM on your graphic card, and now the image-content has to be copied between RAM (when java wants to access it) and VRAM (when X11 wants to access it, like for screen-display).

Unfortunately, it seems that some intermediate changes made in Jaunty during the past week have made things worse for me.

Java performance is good (scrolling, view resizing, etc in IDEA8 is very fast), however if I open many windows on the same viewport (5+ or something, especially maximized ones), then switching between them becomes very slow. Dragging of a single window is fast and any redraws inside of a single windows is also fast, but things like Alt+Tab, Scale compiz plugin or anything else that operates on many windows at once is slow. Bad, but maybe this was caused by some 'stability' patches, probably related to memory management somehow. This is with EXA.

Another issue is that UXA does not work for me anymore - it is able to redraw the screen (in compiz) only once per 2 seconds (Compiz benchmark shows 0.5 fps), which is totally unacceptable. Last week, UXA was at least as fast as EXA for me, with DRI2 working. XAA crashes, too. Very bad...