Bug 599

Prepared FBO support w/ last JOGL commits (Cleanup GLAutoDrawable, query FBO availability,  .. etc):

From <http://jogamp.org/git/?p=jogl.git;a=commit;h=eed8508ae1132e5f45f788e9cb3f3d5a1050ac70>
upto <http://jogamp.org/git/?p=jogl.git;a=commit;h=d5866a5d55f9445c7cedc1df03dc7958d6fd229e>

Hey Sven, all these changes, together with the fixes for bugs 589 and 569, look great. Thanks for your hard work!

When are you planning to release the next RC? In the meantime I will try testing making my own build from the trunk.

(In reply to comment #1)
> Prepared FBO support w/ last JOGL commits (Cleanup GLAutoDrawable, query FBO
> availability,  .. etc):
> 
> From
> <http://jogamp.org/git/?p=jogl.git;a=commit;h=eed8508ae1132e5f45f788e9cb3f3d5a1050ac70>
> upto
> <http://jogamp.org/git/?p=jogl.git;a=commit;h=d5866a5d55f9445c7cedc1df03dc7958d6fd229e>

(In reply to comment #2)
> Hey Sven, all these changes, together with the fixes for bugs 589 and 569, look
> great. Thanks for your hard work!
thx.

> When are you planning to release the next RC? In the meantime I will try
> testing making my own build from the trunk.
After offscreen FBO works incl. OSX for the layering _and_
another little maintenance .. so, Sunday or next week.

Tested new FBO offscreen drawable encapsuled as auto-drawable 
on X11 and Windows - working w/ resize which no more requires 
the destruction of the drawable/context.

Reduced our platform dependent dummy drawable code to a generic one
wrapping the dummy window handle only. Only pbuffer actually requires
a platform dependent drawable.

Now adding OSX dummy window handle and test it there.

Then ..

- OSX offscreen layer usage/test
- FBO multisampling blitting

Sounds great! 

I have one question: What does JOGL do when the user asks for a context without multisampling? Does it still create a multisampled FBO with number of samples set to 1, or do you use the regular FBO instead? I'm asking because the former approach would work, but it is slower than the later, because of the additional blitting operations, I guess. Look at how I ended up implementing it in Processing:

http://code.google.com/p/processing/source/browse/trunk/processing/android/core/src/processing/opengl/PGL.java?spec=svn9797&r=9797

Sounds great! 

I have one question: What does JOGL do when the user asks for a context without multisampling? Does it still create a multisampled FBO with number of samples set to 1, or do you use the regular FBO instead? I'm asking because the former approach would work, but it is slower than the later, because of the additional blitting operations, I guess. Look at how I ended up implementing it in Processing:

http://code.google.com/p/processing/source/browse/trunk/processing/android/core/src/processing/opengl/PGL.java?spec=svn9797&r=9797

(sorry for the duplicated comment earlier)

I have another question. One possibility that the use of a FBO opens up is to easily apply post-processing filters (e.g.: blur, posterize, etc) on the entire screen by means of a custom GLSL shader bound when the color texture is rendered. This is something that I was planning to implement in Processing using my current FBO hack, since I have complete access on all the FBOs and textures.

With all of this mechanism begin built into JOGL, I'm wondering how difficult would be to insert a custom GLSL shader from the application so it is used when rendering the FBO color texture.

Please disregard my last comment about custom GLSL shaders... I figured ways to do this without having to reply on any low-level API in JOGL.

What it would still be useful though, it she possibility to retrieve the GL ID of the texture used as the color buffer by the FBO.


(In reply to comment #7)
> (sorry for the duplicated comment earlier)
> 
> I have another question. One possibility that the use of a FBO opens up is to
> easily apply post-processing filters (e.g.: blur, posterize, etc) on the entire
> screen by means of a custom GLSL shader bound when the color texture is
> rendered. This is something that I was planning to implement in Processing
> using my current FBO hack, since I have complete access on all the FBOs and
> textures.
> 
> With all of this mechanism begin built into JOGL, I'm wondering how difficult
> would be to insert a custom GLSL shader from the application so it is used when
> rendering the FBO color texture.

(In reply to comment #8)
> 
> What it would still be useful though, it she possibility to retrieve the GL ID
> of the texture used as the color buffer by the FBO.
> 

Currently about to cleanup (fix regressions on 1 platform, ..) and commit today
what I have. The generic NativeWindow / MutableWindow layers via factory createGLDrawable(..)
still need to be implemented so it can be used for JAWT [OSX] and offscreen NEWT GLWindow.

Impl./Design notes:

- New FBObject handling FBO / attachments w/ or w/o MSAA,
  while it can be reconfigures on the fly (attach/detach) etc

- New GLCapabilities*.isFBO() / setFBO(boolean) to request FBO offscreen,
  similar to isPBuffer(). Rule: if both are requested, FBO shall be favored.

- GLContext queries FBO capabitlities ..

- GLContext/GL track read/write framebuffer to be queried by FBObject
  to determine whether to bind/unbind  a framebuffer

- GLDrawableImpl adds new getter for default read/write framebuffer
  which will be used at GL.glBindFramebuffer(target, 0) w/ default framebuffer 0.
  This allows a transparent use of a custom FBO even in case the applications
  attempts to reset FBO to zero.

- New GLFBODrawableImpl impl. an FBObject based GLDrawable

- Test cases for multiple FBO w/ and w/o MSAA

I will update later today w/ commits ..

Pushed Part 1 (the biggest one) impl. this feature.
Warning: Lots of OO cleanup under the hood to make things work.

http://jogamp.org/git/?p=jogl.git;a=commit;h=20bf031db719f7baa4c6e74734fc999061e08fe2

Tested/Quality:
  Linux/X11 AMD/NV Almost regression free ~ +2 .. maybe
  OSX: A few regressions .. + 10 ?
  Windows: We will see :)

FBObject is tested manually on all platform, working .. ofc.

osx offscreen layer currently broken .. fixing regression now.

When would it be safe to start running tests on my side?

(In reply to comment #11)
> osx offscreen layer currently broken .. fixing regression now.

(In reply to comment #12)
> When would it be safe to start running tests on my side?
> 
> (In reply to comment #11)
> > osx offscreen layer currently broken .. fixing regression now.

offscreen layer regression fixed .. 

Will head to a few simple other ones, like bug 606 (which you have reported).
Should be done in .. 1-2 hours max.
Then it would be best to test. Thank you.

Then .. next stage .. complete FBO

Is the new FBO mechanism already working? Can it be enabled/disabled when creating the GL context?

(In reply to comment #14)
> Is the new FBO mechanism already working? Can it be enabled/disabled when
> creating the GL context?

As you can see in the FBO unit tests, it works as standalone GL[Auto]Drawable
w/ and w/o MSAA.

However, still needs to be attached to an existing surface, i.e. JAWTWindow etc
to be used w/ e.g. OSX for applets etc .. instead of PBuffer.

This will happen after SIGGRAPH.

See commit message:
 <http://jogamp.org/git/?p=jogl.git;a=commit;h=4dd44b985fe0541be3a3bcd9045d201ed3ca2cc5>

Also resize of offscreen-layer content (no more recreation for FBO or PBuffer)
works butter smooth.

For OSX stabilization see Bug 617