FBO accelerates translucent VolatileImages

Java 2D
#1

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002129

Many thanks!

#2

I knew you’d like that one, Mik :slight_smile: It will be available in Mustang b53 (in about two weeks). Please give it a try and submit your feedback.

Thanks,
Chris

#3

And I knew you was the one behind it :wink:

I did some FBO experimenting by myself through LWJGL. Nice little thing! Too bad current drivers (NVidia) do not support stencils yet.

Testing ? Of course I’ll do that !

Cheers.

#4

Yeah, neither does ATI. Fortunately for us, were able to move away from using the stencil buffer to just using the depth buffer, which reduced VRAM consumption, and improved performance in some cases (on top of making FBO support work properly):
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6313838

Chris

#5

Chris,

reading the bug database comments and evaluations is really interesting.

I have a bit off topic Q about the OGL Java2D implementation: how did you emulate the Porter-Duff alpha compositing rules (SRC_OVER mainly) with an ARGB offscreen buffer (i.e. the FBO or the Pbuffer) ?

I have no problems if the dest pixels are opaque, but I’m getting black artifacts when the blending takes place on fully translucent dest pixels. It seems that the dest RGB is taken into account when computing the blend result.
I did a lot of experiments and I ended up to find only a viable workaroud but nothing more.

Please read this post if you have time: http://192.18.37.44/forums/index.php?topic=8800.0

Cheers,

Mik

#6

Which black artifacts are you referring to?

We use the P/D rules in their theoretical form, meaning SrcOver corresponds to Fs=1, Fd=1-As (in OpenGL terms: GL_ONE, GL_ONE_MINUS_SRC_ALPHA). But it’s very important to keep in mind that the P/D rules operate on “pre-multiplied” components (meaning the color components have already been multiplied by the corresponding alpha value before the blending equations). I think this is why your workaround “works”, because it is effectively premultiplying your color values as part of the blending process, but it’s also probably the source of your confusion in that thread.

I’ve always been really annoyed with OpenGL documentation because 99% of the time you will see SrcOver described as (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA), which may work out if you’re not really concerned with the theoretical results, but it’s totally wrong from that perspective, especially when dealing with translucent destinations. I have never once seen OpenGL docs talk about “premultiplied” values, and how they’re needed for true P/D blending. Our AlphaComposite javadocs actually have a pretty good explanation:
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/AlphaComposite.html

So anyway, I suggest you just use glBlendFunc() as we do with the theoretical P/D rules as described in the AlphaComposite docs. But then you will have to make sure that everywhere you are using premultiplied data in your OpenGL rendering code, which could be difficult given the complexity of your app. (Not only does your source data has to be premultiplied, but you also need to make sure the destination values are also premultiplied, but the former usually implies the latter.)

What this boils down to is, if you want a 50% translucent white color, in non-premultiplied form it would look like:
glColor4f(1.0f, 1.0f, 1.0f, 0.5f);
but what you want is the premultiplied form, so that you don’t have to fiddle so much with the blend func:
glColor4f(0.5f, 0.5f, 0.5f, 0.5f);

Hope this helps.
Chris

#7

Wow - really great to see this in mustang already!
Great job!!!

Thanks, lg Clemens