Hello Ivicks,
the first part of your question is about the pair of calls at the beginning of draw:
- PGL pgl = ((PGraphicsOpenGL) g).beginPGL();
- gl = pgl.gl.getGL().getGL2();
I can't give you the most detailed answer about why they are necessary, for that you should turn to someone more involved in OpenGL and Processing or some good books on OpenGL, but their purpose is roughly to prepare OpenGl for drawing. If you look at the source code for the PGraphicsOpenGL class, line 1640 to 1645, you'll see that the function beginPGL() "flushes" out any previous graphics and geometric transformations that hasn't been processed or drawn and in turns calls the beginGL() (line 1217) of the PGL class - a Processing-OpenGL abstraction layer according to the header comments - which sets up the default Processing projection matrix.
After the function called on line 1 returns, the variable pgl points to an instance of the PGL class, the OpenGl-Processing abstraction layer.
The second line is more important, and probably causes the crash when omitted. Through the PGL instance, you can access the javax.media.opengl.GL object which for all practical purposes can be though of as the point of entry into the OpenGL API in Java when using JOGL. This also where things get confusing and I must admit that I don't really know what happens behind this interface. In any case, the chained function calls pgl.gl.getGL().getGL2() should return an OpenGL context that is suppose to look and behave like described in the OpenGL 2 specifications. You can think of OpenGL as machine which you operate by setting levers into different positions or states. You feed this machine geometry data and colours and by setting certain states it will perform specific operations and output the rendered frame like you want them (if you know what you are doing, otherwise you often get a mess of pixels or nothing at all).
I believe these getGL functions from line 2 also put the machine in a kind of ready state which is needed to start working with it.
This concept of state machine is important to understand the pushing popping and to try and answer the second part of you question.
The purpose of the code I posted was to show how to modify PGraphicsOpenGL so that one could push and pop framebuffers from outside the class. This was to solve a problem which caused the attachment of a texture to the FBO to fail because of conflicts with the FBO used by Processing internally (see andres answer). The solution was to push the current (that is the Processing internal buffer) FBO on the stack, perform my own offscreen rendering in my FBO, pop back the Processing FBO to return to a 'normal' state and finally show what has been rendered offscreen by texturing a quad using the texture attached to my FBO.
In my example, I'm not doing anything fancy in the offscreen rendering, I'm only filling the frame buffer with a colour that changes every frame using the noise function, thus setting the viewport to match the dimensions of the FBO (10 times smaller than the sketch in my example) could be omitted in that particular case. However, if you are going to do something a bit more complex, like re-rendering a complete scene at a much higher resolution, you will need to set the viewport to the dimension of you FBO so that the your geometries are actually drawn where you intend them to be. Also notice the pair of ((GL2)gl).glPushAttrib and ((GL2)gl).glPopAttrib. What I'm doing there is pushing the viewport matrix along with the information about what is enabled (like lighting) before I render offscreen, and pop them back afterwards. This is to save the state of the machine as set by Processing and to restore it after I'm done working on the custom FBO. Note that the operation of switching between states can be expensive in terms of processing time which could cause your animation to seriously slow down, so handle with care!
Judging from the code in your post, it seems that you are not binding your FBO, and actually not rendering anything in the FBO. You are only filling the window with black, getting the OpenGL context and binding the default frame buffer with glBindFramebuffer(GL.GL_FRAMEBUFFER, 0); and then showing the texture attached to your FBO (which is empty because you haven't drawn anything in it).
As for why my example do not work on your machine, I don't really know, but hopefully I gave you enough information for you to figure out how to make your own code work.
Good article about FBOs in OpenGL :http://www.songho.ca/opengl/gl_fbo.html
Regards.
Not in PDE. In NetBeans. May be some library..
