Video memory and Double buffering

Hi,

I am a little bit confused regarding the most efficient way of updating a GLCanvas. My only knowledge of jogl is “the jogl introduction” pages which I found on the web - it gives an example of a basic 2d program to get you started - I’ve got that working but I’m still a newbie.

Question 1. If a canvas contained a picture containing a complex combination of squares, circles and polygons etc and the next picture was the same as the previous one but for a slight change in the position of a rectangle; then rather than the display() method going through the procedure of repainting the whole canvas is there some super-efficient way of doing it (like having all the GLCanvas’ pixels stored in video memory and thus updating the display much faster) and making swaps between two buffers (double buffering) to avoid screen flicker? If this can be done I’d love to know how.

Question 2. If I had a graphics object which the program used a lot(for example a square with a circle inside it) would it be possible to store this object in video memory and thus speed up the drawing of the object onto the GLCanvas? Again, I’d love to know how, as fast, flicker-free updating of my GLCanvas is paramount to the working of my program.

Any pointers to useful URLs, suggestions, code or feedback would be greatly appreciated.

Regards,

Sally

question 1:

If you dont clear your frame buffer at the beginning each frame then you could just update a section of it. Also you could render the scene to a offscreen buffer (render to texture, pbuffer,…etc) and then use this as a texture for a quad that covered the whole screen(use an orthographic projection or something). Some effects algorithms use method this to capture frames and do some sort of blend or combine on them, differed shading, DOF…etc)

There is a specific GL extension that do this as well (see the extension registry http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_buffer_region.txt for the ARB_buffer_region extension). Ofcouse if the eye position changes then you would have to reupdate the stockframe.

Question 2:
commonly used geometry can be uploaded to vram in several ways: Display Lists, VAR, VAO, VBO. VertexArrayObject are your best bet as (VAR and VAO, nvidia’s & ati’s early attempts at functionality similar to VBO). Display lists can be handy too, but they arn’t neccesarly only for geometry. See the extension on ARB_vertex_buffer_object.

There should be lots of tutorials on how to use these extesnsion on the net. Check www.delphi3d.net (its in delphi but you can get the jist of the examples)

Hello

I can’t find WGL_ARB_buffer_region in JOGL, am i right or can we use this extension with jogl?

This extension requires low-level window system information to be passed down into its functions; JOGL does not support these kinds of extensions. While you can certainly hack the sources to make it work, unless you have millions of triangles and have a very good idea of exactly which pixels are invalidated in a particular frame, you are better off just drawing your geometry every frame using vertex arrays and letting the hardware handle it.

Thanks, i will continue to redraw then, or use pBuffers
But it can be useful when you have multiple layers… and one not moving very often…

Have a look at (glScissor ( x , y , width , height )

glScissor defines a rectangle, called the scissor box, in window coordinates. The first two arguments, x and y, specify the lower left corner of the box. width and height specify the width and height of the box.

To enable and disable the scissor test, call glEnable and glDisable with argument GL_SCISSOR_TEST. The test is initially disabled. While the test is enabled, only pixels that lie within the scissor box can be modified by drawing commands. Window coordinates have integer values at the shared corners of frame buffer pixels. glScissor(0,0,1,1) allows modification of only the lower left pixel in the window, and glScissor(0,0,0,0) doesn’t allow modification of any pixels in the window.

When the scissor test is disabled, it is as though the scissor box includes the entire window.

Hope this helps. Am hoping this will speed my application up by streets.

Regards,

Sally

I’m not trying to use bounding box to reduce drawing but layers. That is to say : i draw a background that changes less often that the foreground and i want to save the background to improve performance. (Imagine a map with some objects moving on it’s top)

PBuffers works well but i find it’s a little complex for a simple application. But it works so…

I was just seeking a simpler way.

Thanks for all the information everybody gives.

Hi,

Some divers (NVidia) support KTX_buffer_region extension, which does not need any platform-specific infromation and AFAIK implemented on Windows and Linux. I know this is outdated extension, but it may be useful for some apps.

Here is a code that should be added to glext.h in order to support this extension:

/*
 * note(yvg): manually created this definition from the description at http://www.west.net/~brittain/3dsmax2.htm
*/
#ifndef GL_KTX_buffer_region
#define GL_KTX_FRONT_REGION               0
#define GL_KTX_BACK_REGION                1
#define GL_KTX_Z_REGION                   2
#define GL_KTX_STENCIL_REGION             3
#endif

#ifndef GL_KTX_buffer_region
#define GL_KTX_buffer_region 1
#ifdef GL_GLEXT_PROTOTYPES
GLAPI GLuint APIENTRY glNewBufferRegion(GLenum);
GLAPI void APIENTRY glDeleteBufferRegion(GLuint);
GLAPI void APIENTRY glReadBufferRegion(GLuint, GLint, GLint, GLsizei, GLsizei);
GLAPI void APIENTRY glDrawBufferRegion(GLuint, GLint, GLint, GLsizei, GLsizei, GLint, GLint);
GLAPI GLuint APIENTRY glBufferRegionEnabled(GLvoid);
#endif
typedef GLuint (APIENTRY * PFNGLNEWBUFFERREGIONPROC) (GLenum type);
typedef void (APIENTRY * PFNGLDELETEBUFFERREGIONPROC) (GLuint region);
typedef void (APIENTRY * PFNGLREADBUFFERREGIONPROC) (GLuint region, GLint x, GLint y, GLsizei width, GLsizei height);
typedef void (APIENTRY * PFNGLDRAWBUFFERREGIONPROC) (GLuint region, GLint x, GLint y, GLsizei width, GLsizei height, GLint xDest, GLint yDest);
typedef GLuint (APIENTRY * PFNGLBUFFERREGIONENABLEDPROC) (GLvoid);
#endif

In fact, I was planning to submit a patch suggestion for this, but kept this on hold because of this was not so important - I use patched version of JOGL anyway.

Yuri

Just out of curiosity, what kind of things have you patched in JOGL? Are you willing to contribute the information?

[quote]I use patched version of JOGL anyway.
[/quote]
Yuri, what have you patched in your copy of JOGL? I’d like to roll up any fixes into the main source tree. Are there issues filed for any bugs you’ve fixed, and patches submitted on the JOGL issues page? I am hoping we will do a bug crawl soon.

Most of the patches were already addressed by changes made in JOGL 1.1 (linux multiheaded fix, manual swap buffers control).

Current differences from JOGL CVS tree:

  • KTX_buffer_region extension support

  • Use of Dialog instead of Frame for dummy GL content under Windows (this ensures that there will be no window caption in taskbar even for short time when dummy window shown for a short time)

The idea of this patch is to use

final java.awt.Dialog frame = new java.awt.Dialog(new Frame(config), "", false, config);

instead of

final Frame frame = new Frame(config);

in original JOGL.

  • I have commented out emission of assertions in GlueGen

  • I added use of wglGetExtensionsStringEXT in addition to wglGetExtensionsStringARB when determining list of platform-specific WGL extensions in choosePixelFormatAndCreateContext(…) of WindowsGLContext.java

Additionally, I use reduced version of OpenGL header files to make minimalistic bindings necessary to run Xith3D - it uses only a fraction of all the OpenGL functions, so I don’t need them in my apps and this allows to reduce the download size of JOGL native libs and jars.

Right now I am working on a problem with multisampling on ATI cards - for some reason ATI drivers return empty string for both wglGetExtensionsStringEXT and wglGetExtensionsStringARB, so JOGL can not detect presence of multisampling capabilities and FSAA does not work. I think this is a problem of JOGL because of other programs (read: Realtech VR OpenGL extension viewer) show that multisampling extensions are there). The same code works fine on NVidia cards. I still don’t know the reasons and that’s why I don’t file an issue for that (if I will fix it I will suggest a patch immediately).

Yuri

Problem with FSAA on ATI filed as Issue #76. Suggested patch attached.

Yuri

[quote]Current differences from JOGL CVS tree:

  • KTX_buffer_region extension support

  • Use of Dialog instead of Frame for dummy GL content under Windows (this ensures that there will be no window caption in taskbar even for short time when dummy window shown for a short time)
    [/quote]
    Thanks for these patches; they have been applied to the CVS repository.

Do you mean the assertions that the passed glProcAddress to the native code is non-null? Those shouldn’t be enabled in the build and so should be no-ops anyway. Did you see some problem with them?

Thanks for your patch for the multisampling issue on ATI cards. This has been applied to the CVS repository.