# OpenGLContext not rendering (or doing anything) at all? **URL:** \ **Category:** General JUCE discussion\ **Created:** [May 14, 2019, 2:24pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383 "2019-05-14T14:24:33Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![ComposerShield](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/composershield/32/6655_2.png) [@ComposerShield](https://forum.juce.com/u/ComposerShield)\ **Post date:** [May 14, 2019, 2:24pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/1 "2019-05-14T14:24:33Z")
So I have a class called Visualiser that draws a bunch of audio data and I want to attach an OpenGLContext to see if that gives me a performance boost. I have the class inherit from OpenGLAppComponent (which sets continuous painting to true) and in my constructor, I have openGLContext.setComponentPaintingEnabled(true) so it draws my paint function continuously. But it doesn’t draw on its own. And if I trigger repaint() from a timer elsewhere, I can see in Instruments that it’s still drawing from the main thread, not an OpenGL thread. I put DBG(“foo”) inside the overriden render function and it never prints to the console so that tells me its just not working at all. Does anybody know if I missed something? ---
**Author:** ![DaveH](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daveh/32/4924_2.png) [@DaveH](https://forum.juce.com/u/DaveH)\ **Post date:** [May 14, 2019, 5:05pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/2 "2019-05-14T17:05:05Z")
Are you expecting it to render the Juce stuff? It’s a Open-GL window, you’ll need to create your own OpenGL code, sorry. 🙂 See the examples? They are good to build upon. ---
**Author:** ![alassandro](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/alassandro/32/4297_2.png) [@alassandro](https://forum.juce.com/u/alassandro)\ **Post date:** [May 14, 2019, 5:42pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/3 "2019-05-14T17:42:07Z")
It should still draw in `paint()` if you’ve enabled `setComponentPaintingEnabled(true)`… but `render()` not being called at all sounds like something else is wrong. Do you happen to be using either `Component::setCachedComponentImage()` or `Component::setBufferedToImage()` on the visualiser component? `OpenGLContext` achieves its texture updating by attaching itself to a component as a cached image object, so if you use either of those methods you may break the GL context attachment ---
**Author:** ![ComposerShield](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/composershield/32/6655_2.png) [@ComposerShield](https://forum.juce.com/u/ComposerShield)\ **Post date:** [May 14, 2019, 5:45pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/4 "2019-05-14T17:45:25Z")
Hmm, it’s not that I’m opposed to writing GLSL, it’s that my colleague told me I may be able to get a performance boost from attaching an OpenGLContext even without writing shaders and such. Even the Juce docs confirm this. Check out the description for setComponentPaintingEnabled(), it says it will draw the Juce paint method: > If this is false, then only your OpenGLRenderer will be used to perform any rendering. If true, then each time your target’s paint() method needs to be called, an OpenGLGraphicsContext will be used to render it, (after calling your OpenGLRenderer if there is one). ---
**Author:** ![ComposerShield](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/composershield/32/6655_2.png) [@ComposerShield](https://forum.juce.com/u/ComposerShield)\ **Post date:** [May 14, 2019, 5:49pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/5 "2019-05-14T17:49:51Z")
Yeah, that’s what I thought. Hmm, no I’m not using either of those. The only thing that’s somewhat strange although not that strange is that my visualiser is a shared pointer owned by two parents. Is there some possibility that the ownership of the context is getting jumbled or something? ---
**Author:** ![alassandro](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/alassandro/32/4297_2.png) [@alassandro](https://forum.juce.com/u/alassandro)\ **Post date:** [May 14, 2019, 5:56pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/6 "2019-05-14T17:56:37Z")
That should still be fine, as long as the parents aren’t trying to each set the visualiser as a child component (if the parents are even components themselves, that is) Your best bet is probably setting some breakpoints inside JUCE’s `OpenGLContext` code to see why the attachment isn’t being made. For example, your visualiser might not be meeting the requirements for this `canBeAttached()` method: > That method seems to be called when `OpenGLContext::attachTo()` is called, _or_ if the target component has its visibility changed, _or_ if its peer (window) changed, _or_ if it’s moved/resized… I would think your component would pass the requirements somewhere between all that, but you will probably have to breakpoint to see when (and why) it doesn’t pass 🙂 ---
**Author:** ![ComposerShield](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/composershield/32/6655_2.png) [@ComposerShield](https://forum.juce.com/u/ComposerShield)\ **Post date:** [May 14, 2019, 6:34pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/7 "2019-05-14T18:34:26Z")
Great idea! Okay this is starting to push my knowledge limits a little but I can see that context.coverrideCanAttach is false which is correct. Can’t exactly see width or height from here. I’m just posting it in case you see something I don’t… ![15%20PM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/e/ea500edce98471b607e560d1d91915717ddbbfe8.png) ![29%20PM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/8/8af3057bf630c3a0ee7ac5e4dbcaa88b1afd8f3d.png) ---
**Author:** ![alassandro](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/alassandro/32/4297_2.png) [@alassandro](https://forum.juce.com/u/alassandro)\ **Post date:** [May 14, 2019, 6:57pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/8 "2019-05-14T18:57:27Z")
I wonder what that `overrideCanAttach` is even for… it’s a private member of `OpenGLContext` that is always set to false and never changes from what I can see in JUCE’s source 😛 My advice would be to print the bounds and then check what boolean is actually going to be returned by that `isShowingOrMinimised()` function. Then you can see what’s going on a bit easier, and reset the JUCE code back when you’re done. Maybe something like: ```auto bool canBeAttached (const Component& comp) noexcept { // can easily see these in Xcode's debugger now DBG(comp.getBounds().toString()); bool showOrMinResult = isShowingOrMinimised (comp) // ignoring overrideCanAttach for now bool result = comp.getWidth() > 0 && comp.getHeight() > 0 && showOrMinResult; if (!result) jassertfalse; // force the program to stop here so we can see what's going on return result; } ``` Whenever result is false and that assertion stops the program, you can check out the call stack and see when the attachment is trying to be made. If it’s happening every time there’s some sort of underlying issue… If `attachTo()` fails, _then_ adding the visualiser and making it visible fails, _then_ resizing the visualiser fails, there must be a peer missing or some visibility setting is wrong somewhere along the line. Considering its painting normally without OpenGL though I would be surprised if that were the case! You can find the call stack view in the left panel in Xcode, under the “hamburger” looking icon. It will show a stack trace any time the debugger has paused the running app (via assertion or breakpoints): ![48%20PM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/1/1f4c028e9c4b0fb7ee04ca2dd9692f4583c46f48.png) ---
**Author:** ![ComposerShield](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/composershield/32/6655_2.png) [@ComposerShield](https://forum.juce.com/u/ComposerShield)\ **Post date:** [May 15, 2019, 3:11pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/9 "2019-05-15T15:11:38Z")
This helped tremendously. Thank you so much. I’ve been grinding at it, trying different things for like two days now. Figured it was time to put it here and see if you have any more thoughts. There is only one Visualiser but it looks like it gets created several times. Not sure why. I can still see that the render function is not called. HOWEVER, it turns out it actually works in the standalone app only. If I open it as a standalone, suddenly the render function is getting called all over the place. Curiouser… ![05%20AM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/2X/a/a97d4db6757918183ee4588dc92189641d6f6bb6.png) ---
**Author:** ![ComposerShield](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/composershield/32/6655_2.png) [@ComposerShield](https://forum.juce.com/u/ComposerShield)\ **Post date:** [May 15, 2019, 3:42pm UTC](https://forum.juce.com/t/openglcontext-not-rendering-or-doing-anything-at-all/33383/10 "2019-05-15T15:42:40Z")
Okay so redoing everything such that the context is no longer a shared pointer created in the audio processor and copied by the editor and is instead created as a regular object in the editor. The editor just points to the processor to it each time it’s created. Anyways, it draws on the open gl thread now 😃