I'm creating a painting application backed by JOGL. I have a tool that allows the user to click and drag to draw brush strokes on the screen.
At the moment, the brushstroke drawing code is all being done with BufferedImages. At the moment the user starts dragging, a BufferedImage is allocated to capture the entire stroke. Another BufferedImage is also created which is filled with the image of the head of the brush. As the user drags the mouse, the trajectory is calculated and used to draw many copies of the brush tip image into the stroke collector buffer. When the user is done, the stroke collector image is then drawn into the scene as a whole. The above process is quite slow, and since I am already using JOGL to render to the screen, it would be nice if I could do this offscreen task using JOGL too. The trouble is, I need to compute my stroke buffer as I receive mouse input, so I can't wait until the GLEventListener sends me the GLAutoDrawable. One option is to create a second rendering context - however, I would like to be able to render the partially completed stroke buffer over top of my image to give the user some visual feedback. If I'm using two separate GL contexts, I'd have to read the stroke buffer image out of one into the CPU and then write it back into the other. Being able to do everything in the same GL context would save me that very expensive step. I'd plan to use framebuffer render-to-texture techniques to do the actual compositing. How would I set up JOGL so that a Swing thread could jump in and read and write framebuffer textures on the fly? |
Administrator
|
Hi
I would rather use a PBO, a pbuffer or a very simple color buffer. I don't know how you process events but I don't have any problem with that. I treat mouse events before rendering. You don't need a current OpenGL context to read an image, only to load it as a texture for example.
Julien Gouesse | Personal blog | Website
|
My question is more along the lines of: How do I get an active GLDrawable from a non-JOGL thread so that I can do this offscreen stuff?
PBOs might be a good alternative. Thanks. |
Administrator
|
In reply to this post by kitfox
On 03/22/2012 05:04 PM, kitfox [via jogamp] wrote:
> > > I'm creating a painting application backed by JOGL. I have a tool that > allows the user to click and drag to draw brush strokes on the screen. > > At the moment, the brushstroke drawing code is all being done with > BufferedImages. At the moment the user starts dragging, a BufferedImage is > allocated to capture the entire stroke. Another BufferedImage is also > created which is filled with the image of the head of the brush. As the > user drags the mouse, the trajectory is calculated and used to draw many > copies of the brush tip image into the stroke collector buffer. When the > user is done, the stroke collector image is then drawn into the scene as a > whole. > > The above process is quite slow, and since I am already using JOGL to render > to the screen, it would be nice if I could do this offscreen task using JOGL > too. The trouble is, I need to compute my stroke buffer as I receive mouse > input, so I can't wait until the GLEventListener sends me the > GLAutoDrawable. However, let's say you receive NEWT/AWT mouse events you could funnel GL tasks to your offscreen GLAutoDrawable, maybe even async. <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/javax/media/opengl/GLAutoDrawable.java;h=c427a9804e6b7b8ac4ae06c9cff3815ed95876d9;hb=HEAD#l182> Composing the offscreen w/ your onscreen can be done in your onscreen GLAutoDrawable .. ? Sure, both would use separate GLContext instances, but the onscreen GLAutoDrawable could use the offscreen one as it's read buffer: <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/jogl/classes/javax/media/opengl/GLContext.java;h=41dce0d3bc1b3221155eef91c9845ad25fe77803;hb=HEAD#l151> Example: <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/offscreen/ReadBufferBase.java;h=e3ca25ae6abf79630bf5ad0d6d663e5fa85dc6b0;hb=HEAD#l35> Just brainstorming .. Ofc .. I guess using an FBO to texture might be more feasible here, sadly we don't have an GLAutoDrawable impl. for that [yet]. But it's not too hard to use having the FBOObject util .. ~Sven > One option is to create a second rendering context - > however, I would like to be able to render the partially completed stroke > buffer over top of my image to give the user some visual feedback. If I'm > using two separate GL contexts, I'd have to read the stroke buffer image out > of one into the CPU and then write it back into the other. Being able to do > everything in the same GL context would save me that very expensive step. > > I'd plan to use framebuffer render-to-texture techniques to do the actual > compositing. How would I set up JOGL so that a Swing thread could jump in > and read and write framebuffer textures on the fly? > signature.asc (910 bytes) Download Attachment |
I'm not using NEWT. I'm currently using a GLJPanel because I need this to run inside a Swing application. (I'm not familiar with the NEWT stuff - can I use it to run in a Swing component?)
I know that the GLJPanel has a getGL() method. Would I be able to call that, allocate a framebuffer with a texture, render to the framebuffer texture and then read the framebuffer into the CPU? Or is there some restriction that forces me to call GL methods only inside the GLEventListener callbacks? |
Free forum by Nabble | Edit this page |