I need a way to get the thread’s current openGL context, it would be great to have this added to juce :
in juce_OpenGLComponent.h :
/** Returns the active OpenGLComponent.
the returned value is thread dependant,
it will be returned only if it was activated in the calling thread
*/
static OpenGLComponent* getCurrentContextComponent();
Oops, sorry, I was waiting until I have this sorted, but I’d like to request that the OpenGLComponent takes avoid* instead of another OpenGLComponent as the shared context. It looks like the only place the share is used is to be dereferenced once for the actual context.
The change would make less code, be slightly safer, and will allow Juce openGLComponents to be mixed with other OpenGL contexts - currently the internal class makes this impossible.
Well, yes - since the Juce OpenGL Component is very restrictive about setting up the context, and is by nature quite transient, I have to share another context with it. That context will be made in some native format to each platform, and is retained throughout the program run. In my case, it’s per GPU.
But the Juce component is best to draw in a window, and to co-operate with other juce views.
What’s the other way you did it? Can I give the OpenGL component a platform context - that’s all I need.
Jules, I looked at the head, and I was looking for something like this, plus the related change to Mac_Windowing that didn’t work in the patch. I can’t tell whether it breaks Thomas’ request.
Either that, or some other way to force a different context. The key is that I don’t need a Juce component to be master context - that will be offscreen.
Even I support
thomas’s call.
1.Right now there is no way to customize a juce OpenGL context. We are struck with the default opetion for the pixel format.
2. Also there is no way attach the juce opengl context to a separate rendering thread(worker thread).
If Thomas’s suggezstions are followed, both these can be achived…
just replace the Main.cpp in the hello world sample to try it.
Also Bruce, I think your request doesn’t break mine, even if I didn’t include it.
I’m just being curious here but, if I understand well, you use a pbuffer as your ‘master’ context to share your resources between different windows ?
Thanks guys, I’m sure I can take all this stuff and turn it into a nice solution. I don’t really use opengl myself, so am relying on your requests to know what kind of functionality it needs.
just a small detail :
In the modifications, I completly removed the OpenGLComponent’s initialisation parameters for construction, and moved them in initialise() to be able to use it in a worker thread.
it’s also possible to let the previous behavior as the default one (initialise on construction) to keep it straight forward for simple usage, but the code was starting to be too messy to understand the rest.
FSAA means Full-scene anti-aliasing,
It is now implemented in hardware in most decent opengl compliant graphic cards.
FSAASamples are the number of samples used for calculation,
from 2 to 64 for the most expensive cards
openGL implementations require a special pixel format to create a context that allows hardware multisampling, so you have to specify how many samples you want.
After that you can only switch it on or off using glEnable/glDisable(GL_ARB_MULTISAMPLE);
one last note about the code I posted on this thread:
on win32 implementation it is really a mess to set up this, because of the win32 opengl extensions system :
To create a AA context you need some extensions to choose the right pixel format, but extensions mechanism is per-context
so you need to first create a ‘dummy’ opengl context to find out what extensions are supported, if you find WGL_ARB_pixel_format it means you may have a chance to get an ‘extended’ pixel format.
after that you have to destroy the dummy pixel format and then create a new one with the requested attributes.
The implementation finaly chooses which one is acceptable, and it is not always the one that you asked for.