Alpha Composite

Performance Tuning
#1

So i have this particle engine which worked great. Now that I am trying to make them fade like good little particles, the performance is shot.

here is my drawing code before and after. Before had fantastic performance, after is choppy and bad.

Before:

 public void draw(Graphics2D g) {
        
        Iterator i = particles.iterator();
        while (i.hasNext()) {
            Particle p = (Particle)i.next();
            g.setColor(p.getColor());
            g.drawRect((int)p.getX()-p.getSize()/2,
                       (int)p.getY()-p.getSize()/2,
                       p.getSize(), p.getSize());
        }

    }

After:

 public void draw(Graphics2D g) {
        
        Composite c = g.getComposite();
        Iterator i = particles.iterator();
        while (i.hasNext()) {
            Particle p = (Particle)i.next();
            g.setColor(p.getColor());
            g.setComposite(AlphaComposite.getInstance(
                           AlphaComposite.SRC_OVER, p.getAlpha()));
            g.drawRect((int)p.getX()-p.getSize()/2,
                       (int)p.getY()-p.getSize()/2,
                       p.getSize(), p.getSize());
        }
        
        g.setComposite(c);
    }

I am not aware of the performance compared to other ways to do any of that realy, so any way to make it not be terrible would be great.

#2

I am afraid you can’t do much about it. I am not a Java2D guru, but I heard, the use of transparency breaks the hardware acceleration :confused:

#3

Try specifying either -Dsun.java2d.translaccel=true or, if you have a fairly recent graphics card with recent and good OpenGL drivers, -Dsun.java2d.opengl=true on the command line. For some background, try doing a Google search for sun.java2d.translaccel; also see this or this article.

#4

That made no decernable difference. It was suposed to ues directdraw 3D to accelerate the drawing of transparency right?

Unrelated but in my particle im using lots of set and get, should I be making the fields public and accessing them that way?

#5

Yes, I thought it should. One of the Java 2D engineers will hopefully chime in here.

No. The Java HotSpot VM will inline calls to these accessors. Please see some of the JavaOne presentations on the HotSpot publications page. The high-level point is to please write good code.

#6

You haven’t mentioned which JDK release you’re using, or which graphics board, or which graphics driver version… All of these are required bits of information.

In JDK 6, you can use -Dsun.java2d.opengl=True or -Dsun.java2d.d3d=True (note the uppercase ‘T’), which will print to the console whether or not the pipeline can be enabled. For more startup details, set J2D_TRACE_LEVEL=4 (that’s an environment variable) before running your application.

Either pipeline can accelerate the case you mention in hardware. If you’re not seeing a difference, then there’s something about your configuration causing the problem.

Chris

#7

Alright, using =True worked nicly. I cant tell how well it is compared to when I wasn’t using. I did =true before and it failed.

Graphics stuff should be irrelivant since releasing it would require the most stuff possible. But JDK 6. Im on a MBP using bootcamp and on the XP for 6. And im sick of XP already, so hard to do basic tasks.

But anyway, how do I give it that argument without wrapping it in an .exe (or .app when 6 comes out for OS X). Ive never used manifests to give command line args. I dont even know if you can, i suppose I could always go check myself… OFF I GO. Thanks for the help.

Can I use Sysetem.setProperty for this?

Looks like I cannot, this does not work at the very least:

System.setProperty("Dsun.java2d.translaccel", "True");

Edit:… hahahhah,…ha? I removed the D because I wasn’t sure what it stood for anyway and it works dandy now. Thank you for all your help.

Now to get this straight, on a java 5 machine it wil ignore that call? Or will it crash error out. By that I mean should i put an if (System…java version >= 6) before it? Or just leave it alone?