OGL pipeline improvements

The OpenGL-based Java 2D pipeline has been revamped in Mustang-b27 for improved performance and stability. For more info:
http://weblogs.java.net/blog/campbell/archive/2005/03/strcrazy_improv_1.html

Please download the latest Mustang binary snapshot (build 27, available today) and take it for a spin:
http://www.java.net/download/jdk6/binaries/

Feedback is greatly appreciated. The more people testing this stuff, the better the chance of enabling the OGL pipeline by default in a future release. (And in that case, everybody wins, right?)

Thanks,
Chris

Awesome release. I hadn’t tested the OGL pipeline since 5.0 and I’m impressed at how much improved it is now. On win32, GeFX, 76.10 drivers:

  • Everything is looking great, no glitches whatsoever.
  • I get ~2-3 times better performance on most demos of Java2Demo.
  • All my swing apps are running with no problem.
  • I even tested IDEA, everything looks and runs nice, except for this (which you’re obviously aware of):
java.lang.InternalError: not implemented yet
      at sun.java2d.opengl.OGLSurfaceData.getRaster(Unknown Source)
      at sun.java2d.loops.GeneralRenderer.doSetRect(Unknown Source)
      at sun.java2d.loops.XorFillSpansANY.FillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.fillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
      at sun.java2d.pipe.PixelToShapeConverter.drawLine(Unknown Source)
      at sun.java2d.pipe.ValidatePipe.drawLine(Unknown Source)
      at sun.java2d.SunGraphics2D.drawLine(Unknown Source)

Campbell, personally I’m for moving to Mustang permamently but I would like to know weather or not it will break current code which I use at university, uni uses Java 5.

I also don’t understand why you believe Java defaulting to D3D on Windows is better because I get poor performance under the D3D pipe vs the GL pipe when it comes to transforms and transparent/translucent images.

[quote]but I would like to know weather or not it will break current code which I use at university, uni uses Java 5.
[/quote]
No issues here, with any build.

[quote]I also don’t understand why you believe Java defaulting to D3D on Windows is better because I get poor performance under the D3D pipe vs the GL pipe when it comes to transforms and transparent/translucent images.
[/quote]
From what I’ve read, they plan to apply the same techniques used in the OGL pipeline (most importantly, the STR) to the D3D as well.

Please do not beat me, this are just the experiences on my laptop with a Geforce-Go488 (basically a tuned 4MX:

  • Gradient Paint is REALLY slow when accerlated (not AA)
  • For many other rendering operations performance is about 1/2 of the X11/XRender pipeline, only in some special cases I get 2x-5x performance improvements.
  • Performance sometimes choppes, it goes fast, then slow, then fast. This is especially the case when running the circle-demo of java2ddemo.

I think most are driver-issues, however…

Thanks anyway for the hard work, lg Clemens

I’m getting some benefits from the new implementation (and yes, I’m using a similar single-thread design in my LWJGL based api).

No more crashes at system.exit with my NVidia drivers 66.93.

I’m facing some little java2d problems, maybe related to the swing glasspane: the control handles of Castalia objects do not show at all.

Does the new implementation support translucent volatile image acceleration ?

Cheers,

Mik

[quote]Does the new implementation support translucent volatile image acceleration ?
[/quote]
well yes… try java -Dsun.java2d.translaccel=true
but it seems that it wont work with -Dsun.java2d.opengl=True
also i know only how translucent v’s work on my pc… and its like opque ones only that they run slower :wink: no transparecy at all :confused:

I’m aware of this limitation, but I can’t tell from the stack trace what is causing the problem. Could you email me the full stack trace, or perhaps more detail on how to reproduce it, and then I’ll look into it…

Thanks,
Chris

[quote]Campbell, personally I’m for moving to Mustang permamently but I would like to know weather or not it will break current code which I use at university, uni uses Java 5.
[/quote]
Well, the Mustang snapshots should be beta quality, but they’re not intended for production use. That said, there’s nothing in there that should break existing apps. It would be great if you did use the weekly Mustang snapshots, and then report problems if/when you see them.

That’s because the D3D pipeline rearchitecture hasn’t been integrated yet into Mustang. Those changes will produce better performance on Windows than even the OGL pipeline for things like transforms and compositing. And regardless of the performance numbers, the DirectX-based APIs are better supported in Windows drivers and by Microsoft going forward than OGL ever will be.

Chris

[quote]Please do not beat me, this are just the experiences on my laptop with a Geforce-Go488 (basically a tuned 4MX:

  • Gradient Paint is REALLY slow when accerlated (not AA)
  • For many other rendering operations performance is about 1/2 of the X11/XRender pipeline, only in some special cases I get 2x-5x performance improvements.
  • Performance sometimes choppes, it goes fast, then slow, then fast. This is especially the case when running the circle-demo of java2ddemo.

I think most are driver-issues, however…

Thanks anyway for the hard work, lg Clemens
[/quote]
When you report issues like this, please mention the OS and driver version being tested.

I’ve seen the slow GradientPaint issue on very old GeForce (2) boards, so it might be a hardware limitation. I’ll have to check with Nvidia about that.

We don’t use XRender at all (currently) in our X11 pipeline, so it’s incorrect to say otherwise. Anyway, please provide more detail about which operations are slower than with the X11 pipeline (e.g. which Java2Demo sub-panels, which hints enabled).

Same details would be needed about your “Circles” demo report. Was AA on or off? Etc, etc.

Thanks,
Chris

[quote]I’m getting some benefits from the new implementation (and yes, I’m using a similar single-thread design in my LWJGL based api).

No more crashes at system.exit with my NVidia drivers 66.93.

I’m facing some little java2d problems, maybe related to the swing glasspane: the control handles of Castalia objects do not show at all.
[/quote]
Hi Mik,

Thanks for trying it out. Could you provide a testcase for the problem you describe? Or at least a description of how the control handles are rendered?

No, still no translucent VolatileImage acceleration. There’s still an RFE open for this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002129

Thanks,
Chris

To be honest, I always thought SUN isn’t really interrested in getting suer feedback.

[quote].
We don’t use XRender at all (currently) in our X11 pipeline, so it’s incorrect to say otherwise.
[/quote]
Well, great! So there’s always room left for improvements g

Here are some results from mustang-b27 on my laptop:


All animations were run with the default window-size in maximized mode (so this animation is the only one), with the default settings.

worst:
BezirAnim      X11:100fps    X11AA:90fps   OGL:18fps   OGLAA:130fps
Clipping.Areas X11:90fps     X11AA:84fps   OGL:9.6fps  OGLAA:~150fps
GradAnim       X11:135fps    X11AA:77fps   OGL:3.5fps  OGLAA:60fps

not so good:
LineAnim       X11:750fps    X11AA:74fps   OGL:350fps  OGLAA:133fps

great:
TextureAnim    X11:138fps    X11AA:86fps   OGL:650fps  OGLAA:63fps



Some driver-infos:
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce4 488 Go/AGP/SSE2
OpenGL version string: 1.5.3 NVIDIA 71.67 (had similar experiences with the latest 6xxx)

AGP:
Status:          Enabled
Driver:          AGPGART
AGP Rate:        8x
Fast Writes:     Disabled
SBA:             Enabled

Linux-Kernel:     2.6.9

xorg 6.8.1 with RenderAccl activated.

Hope it helps a bit - Good luck!

I’m not sure who/what gave you that impression, but we do take user feedback seriously… Especially in this case, the more data we get, the greater the possibility of enabling the OGL pipeline.

Thanks for the details. I believe you meant “ClipAnim” instead of “Clipping.Areas”, which isn’t animated, correct?

I’m able to reproduce your findings on a GeForce MX4000 board, as well as an older GF2 MX400. I believe the boards are based on the same chip, as is your GF 488 Go.

The poor performance in the three “worst” cases you mention are due to the lack of acceleration of GradientPaint on these boards, as I suspected. I will file a bug report with Nvidia. If it turns out to be a hardware limitation, then we might have to find some way to disable our gradient acceleration mechanism conditionally on this family of boards (yuck).

In the “not so good” case, the slowdown may be attributed to the small drawPoly() calls, which we may be able to optimize. I’ll look into it.

I’ve also thought of ways to improve gradient performance when AA is enabled, so the “OGLAA” score may improve in your “great” case.

Thanks for the feedback. I’ll post again if I get some information from Nvidia about these issues.

Chris

Yes, sorry for this mistake :-[

Well, I think this is the best idea! Enable optimizations if they are possible, but do not try to support all those low-end cards and make the fast ones slower.

Another other not_so_good_cases:


Curves.Arcs      X11:1000fps    X11AA:85fps   OGL:300fps   OGLAA:163fps
Clipping.Intersection  X11:500-1000fps  X11AA:75fps   OGL:300fps  OGLAA:~100fps
BezierScroller (only text): X11:1300fps  X11AA:92fps  OGL:400fps OGLAA:300fps

You see, most tests runs slower using the OGL pipeline on my hardware :frowning:

Btw, the choppy performance I reported to the ogl-pipeline occurs just with the X11-pipeline, seems I messed something.
It occurs e.g. with BezierScroller(text), after startup I get 1300fps, after minimazing the window a couple of times the performance falls to 100fps and stays there. No idea whats wrong :frowning:

lg Clemens

[quote] Hi Mik,

Thanks for trying it out. Could you provide a testcase for the problem you describe? Or at least a description of how the control handles are rendered?
[/quote]
With the new b28 everything works fine with or without the OGL pipeline. By this time I upgraded my NVidia drivers to 71.84 and maybe this fixed the problem.

Cheers,

Mik

Btw. Netbeans no longer crashes on OGL mode when opening the main-window. With 1.5 I got an “illegal async reply” message and the whole thing died :frowning:

I also noticed better performance for “normal” rendering operations like lines, rects and text - maybe the Java2D-Demo isn’t well suited for testing those low-level calls since it uses only more complex higher-level features.

Great to see progress on this task!

lg Clemens

[quote]- I even tested IDEA, everything looks and runs nice, except for this (which you’re obviously aware of):

java.lang.InternalError: not implemented yet
      at sun.java2d.opengl.OGLSurfaceData.getRaster(Unknown Source)
      at sun.java2d.loops.GeneralRenderer.doSetRect(Unknown Source)
      at sun.java2d.loops.XorFillSpansANY.FillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.fillSpans(Unknown Source)
      at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
      at sun.java2d.pipe.PixelToShapeConverter.drawLine(Unknown Source)
      at sun.java2d.pipe.ValidatePipe.drawLine(Unknown Source)
      at sun.java2d.SunGraphics2D.drawLine(Unknown Source)

[/quote]
This bug has been resolved as part of the fix for:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5106309

This fix (along with a bunch of others) will be available in an upcoming Mustang snapshot (probably b32 or so).

Chris

Thanks, everyone, for your feedback. There are still a few performance tweaks and minor bug fixes that we’re making in our Java 2D code; these will be available in an upcoming build. As for the driver-specific issues I discussed earlier, I’ve been filing bugs against the vendors. Here is a partial list of the ones I’ve filed in the past few weeks:

Nvidia

  • glCopyPixels() is very slow for pbuffers (Windows only?)
  • Java 2D shape clip problems on GF2-based boards (Windows only)
  • Lines are missing endpoints on GF2-based boards
  • Java 2D GradientPaint is very slow on GF2-based boards

ATI

  • Java/Swing apps crash upon exit
  • Gradients rendered incorrectly in Java 2D apps
  • Images rendered with Java 2D sometimes have red/blue components swapped

Please continue to file bugs and report any issues you’re seeing. I’ll post updates if I get any new info on these driver issues.

Thanks,
Chris

I reported another bug I came across about one month ago, but did not get any repsonse till now.
The ID is: 409145 - but its not visible till now.

The bug-report was that the size of volatile/managed images created via Component.createImage() is limited.
However I’ve found out some other facts which seem to show that this is an Java2D and not a driver bug:

  • The size of the image is limited to the highest-level-heavyweight component. If you have a component-hirarchy of JFrame(500, 500)->(AWT)Panel(300, 300)->(AWT)Panel(100, 100) and you create the image on the highest-level panel (100, 100) then the size of the backbuffer-image will be limited to 100, 100.
    If you use JPanels instead of Panels your image is limited to (500, 500), because that is the size of the highest-level heavyweight component (JFrame in this case).
    This happens for both, Volatile and Managed images.

  • If I increase the size of the generated image to something bigger than 4096, everything works quiet fine. (I then then accerlation is turned off).

  • This bug happend in 1.5 and the Mustang-builds too.

Hope this helps, lg Clemens

I also have an ugly test-case:


import java.awt.*;
import javax.swing.*;

/**
 * (c) Clemens Eisserer
 */
public class OGLTest extends Panel implements Runnable
{
    Image contentImage;
    public static final int contentWith = 200;
    public static final int contentHeight = 4096;
    
    int currScrollPos = 0;
    
    public OGLTest()
    {
        Frame f = new Frame();
        f.setSize(800, 800);
        f.setVisible(true);
        
        f.setLayout(null);
        this.setLocation(20, 20);
        this.setSize(500, 500);
        f.add(this);
        
        contentImage = createImage(contentWith, contentHeight);
        drawContent();
        
        Thread t = new Thread(this);
        t.start();
    }
    
    
    public void paint(Graphics g)
    {
        g.setColor(Color.white);
        g.fillRect(0, 0, 500, 500);
        
        g.setColor(Color.black);
        g.drawString("That is the clipping test", 100, 100);
        g.setClip(0, 150, 500, 300);
        g.drawImage(contentImage, 0, currScrollPos, this);
    }
    
    public void run()
    {
     
          while(true)
          {
              currScrollPos--;
              if(currScrollPos < -(contentHeight-300)) currScrollPos = 0;
              Thread.yield();
              this.repaint();
          }

    }
    
    private void drawContent()
    {
        Graphics contentG = contentImage.getGraphics();
        GradientPaint paint = new GradientPaint(0f, 0f, Color.red, (float) contentWith, (float) contentHeight, Color.yellow, true);
        ((Graphics2D) contentG).setPaint(paint);
        contentG.fillRect(0, 0, contentWith, contentHeight);
        contentG.setColor(Color.black);
        ((Graphics2D) contentG).setPaint(null);
        contentG.drawRect(1, 1, contentWith-2, contentHeight-2);
        for(int i=0; i < contentHeight; i+= 20)
        {
            contentG.drawString(String.valueOf(i), 20, i);
        }
    }
    
    public static void main(String[] args)
    {
      new OGLTest();
    }
}


[quote]Thanks, everyone, for your feedback. There are still a few performance tweaks and minor bug fixes that we’re making in our Java 2D code; these will be available in an upcoming build.
[/quote]
Are there any plans for Mustang to implement a path for render-to-texture operations with EXT_framebuffer_object? By the time Mustang development finishes, I would expect implementations of this extension to be widely available. It would improve both performance and (video) memory consumption (especially on non-Windows platforms).