Drawing over openGL

I’m trying to paint over an openGL context - or even just display a regular component on top of it.
I see the teapot example is doing this successfully but can’t figure out why my example refuses to display things on top of the GL image.

My Component is an openGLRenderer and it holds a couple of other components which are openGLchildComponents - and these each supply part of the frame that I’m displaying and trying to draw over.

I’ve tried paintOverChildren() and adding a component with .toFront() and .alwaysOnTop() but nothing works - as soon as I load an image and render to the GL the overlay components are hidden

I read somewhere about using GL for the parent window - is this how the teapot example manages this trick?

1 Like


You should enable component repainti g on the OpenGL context with:


1 Like

Hey! Just ran into this exact problem myself. I tried everything @thecargocult tried as well as calling myContext.setComponentPaintingEnabled(true); (Before I attach to a target)

Still can’t see a slider on top of my OpenGL. Any ideas?

I have same problem. Is there any solution? I don’t want to enable drawing component into opengl context, because it uses a lot of memory and little slow on ios. And not sure what todo. My currenT task is simply display popup message. But when I draw it, the opengl component overlapping this message :frowning:


I think the way this works is a window is created that OpenGL paints into, and that window is hovered over your apps window. So if you wanted a non-OpenGL component painted in front of this, you’d probably need to pop up yet another window. JUCE doesn’t provide a way to do this, but it would be possible in theory.

In my experience it works if you add a regular child component to the component that is attached to the OpenGLContext. But it seems not to work for siblings to the OpenGL component.

I think adding another window on top makes matters worse.

Is there any tool/way in Juce to make a screenshot of the OpenGL component? Or maybe get somehow image from a buffer (unfortunately my level of knowledge is very low).

I’m thinking about following steps as temporary solution:

  1. make a screenshot
  2. when popup is opening, remove OpenGL from context
  3. draw screenshot

As @Daniel mentioned, no need for workarounds. Just add a child-component to the attached component and do your non gl drawings on it, JUCE takes care of everything

@chkn it’s not working. My popup should be full screen on iOS. And when I’m adding, my child component is cropped to the OpenGL bounds. (i.e. I don’t need my popup inside the OpenGL I want to display it fullscreen, so that open gl component will be displayed not over my popup with alpha opacity)

Here is example of the issue:
The wavetable is a OpenGL Component. The white popup have a black fullscreen component with 0.7 opacity.

This is when I’m adding popup to the OpenGL Component:

If I attach OpenGLComponent to the getTopLevelComponent() then UI is little slow with glitches and memory increases up to 466 mb instead of 145-150mb as in case when I attach to “*this”

This would be OpenGL doing component rendering, though, no?

Yes, but it would use the OpenGL version of the juce::Graphics backend, so no code changes needed.

But drawing outside the openGL components bounds might be a problem. I haven’t tested that use case. I think it would be best to attach the OpenGLContext to the outer most component. But I don’t know how that would work to use your bespoke openGL renderer in a sub component. I guess it’s possible, but I haven’t tried yet.

Good luck

@daniel as I said in previous post, if I attach component to the parent/or top level component, then UI is slow and memory is about 450mb or even more. Which seems to be a lot, because a limit for AU plugin as I know about 250MB. Actually you can see the level of the CPU as well. 116%

Something is going on somewhere in your code. Are you by chance using a juce::path for those lines? I’ve always found that to be highly inefficient. I’d look at drawing them using vertex buffers straight into OpenGL. I’ve never been able to do anything animated using juce graphics, it always ends up being far to resource hungry. It’s great for static GUIs with a few things that move on mouse activity.


there are a few different native components that seem to be impossible to overlap without creating a new window:

but creating a new window isn’t a viable solution for me because it makes logic crash:

Without using GL (for anybody else who doesn’t want to go that way), If you need to update something regularly/quickly like a scope view it’s good to use a JUCE timeSlice thread and draw the graphics to a image, which then gets drawn in paint calls.
dRowAudio Scope/Triggered Scope is a good example of that and I used it in Hyperion Synth with good effect and low overhead.

That said… for full screen graphics/particle effects etc. inside an audio plugin I have previously used OpenGL drawing using vertex buffers/shaders.
(https://youtu.be/jW-fggSuTeI - synth plugin I did for work - running full screen (all audio and graphics from the plugin))
Isn’t OpenGL support going away at some point on Mac/iOS?

Interesting, I’ll have to try this!