0

I am developing an After Effects plugin where I use a VAO for OpenGL rendering. After full screen RAM preview the VAO, which has the handle number 1, is somehow deleted (glGenVertexArrays generates 1 again). The strange thing is that the shaders and framebuffers are still valid, so it's not the entire OpenGL context that gets reset. Does anyone know what could cause this?

s---70
  • 90
  • 7
  • 1
    AFAIK there's no way to free a VAO other than by destroying it (except maybe during an out-of-memory error or something similar). More likely, some piece of code is freeing it prematurely, but without seeing the code, we can't help much. – Colonel Thirty Two Dec 01 '14 at 15:24
  • Strangely I also tested this with a OpenGL sample plugin included in the After Effects SDK by just calling glGenVertexArrays for every rendered frame. The generated handle is increasing every frame until I cancel full screen RAM preview, where it starts at 1 again. I definitely don't call glDeleteVertexArrays anywhere so any vao deletion would have to happen outside of my code... – s---70 Dec 01 '14 at 15:31
  • 2
    It sounds like you're running in a different OpenGL context the second time you call `glGenVertexArrays (...)`. VAOs are not shared across render contexts, while other objects (those that store actual data) such as textures and buffer objects can be shared. – Andon M. Coleman Dec 01 '14 at 16:45
  • Yeah I guess that's the direction I have to investigate in. Probably the full screen preview does some OpenGL stuff that messes things up for me. – s---70 Dec 01 '14 at 17:31
  • @AndonM.Coleman The OP says that FBOs are still valid. I think they would also have to go away if it's a different context, because they are not shared. So while that sounds like a good theory, it doesn't fully explain the symptoms. – Reto Koradi Dec 02 '14 at 05:27
  • @RetoKoradi: Oh, is that what "framebuffers are still valid" meant? I thought he meant the contents of the framebuffer, not framebuffer objects. – Andon M. Coleman Dec 02 '14 at 08:25
  • I'm currently rewriting the plugin to use wgl instead of glfw. I think that there might be a problem with it's ways of context switching. – s---70 Dec 02 '14 at 15:30

1 Answers1

1

The most likely explanation is, that your plugin gets a completely newly created OpenGL context everything time happens. If your OpenGL context shared its "list" namespace with another "caching" context, and this sharing is re-established for the new context, you'd observe this behavior.

The strange thing is that the shaders and framebuffers are still valid, so it's not the entire OpenGL context that gets reset.

When establishing OpenGL context namespace sharing some kinds of objects are shared, i.e. get their "internal reference counts" (you can't directly access thise) incremented for each participating context, while others are not. Objects that hold data in any form (textures, buffer objects, shaders) are shared, while abstraction objects that hold state (array objects and framebuffer objects among them) are not.

So if a new context is created and a namespace sharing with the cache context established, you'll see all the textures, shaders and so on, you created previously, while VAOs and FBOs would disappear.

If you want to catch this situation use wglGetCurrentContext to get the OS handle. You can safely cast a windows handle to uintptr_t integer type, so for debugging you could print the value of the handle and look for if it changes.

datenwolf
  • 159,371
  • 13
  • 185
  • 298