Site navigation

OpenGLContext and the renderer worker thread

General JUCE discussion
#1


Hi there,


I am very rookie using Juce, so, please excuse if you find somthing that should be obious but I do not know.
I am doing a Juce component to paint video captured from a device. It asynchroniously receives callbacks when there is a new frame ready to paint. So, I am using a class that instanciates a OpenGLContext and on construction uses the "attachTo" member fn to tie the openGL context and the component.


So far, so good, but, I am facing problems with the OpenGL render, I cannot use the "makeActive" member fn in my callback , it just fails.


Seems like if the OpenGL component starts a new thread to render the OpenGL scene, and seems like if that is the only way to use a OpenGL context. I did not find a way to invoke OpenGL calls "setContinuousRepainting " is false.


Am I missing something? Do you have experience not using a class derived from OpenGLRenderer?

 

I am using Juce from last monday (sorry, don't know how to get version ), on Win32 (Macbook with bootcamp) with an ATI board. 


Kind regards and thanks for reading!!
Juan
 

#2

It's not possible to use a GL context from other threads.

What you could do is to create another GL context on another thread, and make them share their resources, but TBH that wouldn't make much sense in your case. Surely the simplest thing to do is just to set a flag when your video frame arrives, and then pick it up in the normal painting method?

#3

Thanks Jules,

 

Let me see, maybe I will try to implement my own OpenGLContext derived class (maybe I guess me too brave).

 

I will let you any case.

 

Thanks for your support

Juan Solsona.

 

#4

Obviously I don't know the details of what you need to do, but that doesn't sound wise.

For a side-project I've been working on a video player that has other threads generating image data, and passing it to the GL thread for rendering. It can all be done very cleanly without needing to hack anything or to use GL on multiple threads. And keeping all your GL operations on the normal GL thread will actually be the most efficient system in almost all cases.