Currently JOGL allows one to create an offscreen GLDrawable in an API transparent manner. User sets the Capabilities onscreen:=false and optionally pbuffer:=true (The latter of hw accel. pbuffer rendering) The GLAutoDrawable impl. (AWT GLCanvas or NEWT GLWindow) may support this request and creates the desired offscreen instance utilizing either pbuffer or just bitmap/pixmap. This mechanism is API-transparent, i.e. the user does not need to change the code - no need to care about the actual implementation. This mechanism is also utilized for the OffscreenLayerSurface implementation (JAWTWindow -> GLCanvas, NewtCanvasAWT, ..) currently used to support OSX offscreen layered compositor (>= 10.6.8, java6/7, ..). Here the offscreen GLDrawable is constructed and later composited. Problem: Even though Pbuffer's are a nice solution to handle such cases it has a few downsides: [P1] - required drawable and context recreation on resize [P2] - deprecated on OSX >= 10.7 [P3] - multisample buggy on OSX 10.7 and AMD GPU Especially a remedy to [P1] when using FBO per default and if available would help overall performance and usability. The latter is also true in respect to the removed GLEventListener calls of dispose(..)/init(..), since the FBO offscreen GLAutoDrawable does not need to be recreated. Implementation: [I1] - Use invisible window handle to create OpenGL context [I2] - Cache the FBO properties in GLContextImpl, allowing to switch back to the [now] FBO default framebuffer [I3] - Utilize existing FBObject utility class Discussion: [D1] Support render-to-texture using texture attachment to FBO
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
(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