Hi, I’ve been using the auto scaling feature in Juce, where any sub component is scaled for you. It’s a fantastic feature if you’re using resizing.
BUT it doesn’t work with a component with a ‘OpenGLRenderer’ added to it.
This is on ‘develop’ & ‘master.’
So to summarise.
I use:
class MainPanel : public Component,
public OpenGLRenderer
{
}
& Do…
openGLContext.attachTo(*this);
…In the constructor.
The above attachment destroys any internal scaling it should have got from its parent. But still scales it’s own child Components, which means the whole thing becomes a mess, as the child components outscale it when enlarged.
Removing the ‘attachTo’ makes it scale work OK again - except of course I have no OpenGL rendering.
This is only Windows, BTW. MacOSX appear to scale fine, on both VST & AU.
Can anybody help please?
Thanks.
Dave H.
BTW. I’m using setTransform only on the very top Window Component, and all my other sliders, text objects etc scale properly.
1 Like
Can confirm I have exactly the same problem, would love to see this fixed soon.
1 Like
If all you’re trying to achieve is making Juce use the OpenGL context for its own drawing functions, you don’t need to inherit from OpenGLRenderer. Simply attach the context and you’re good to go. Works fine here.
But that’s what I wanted to do. You also inherit some functions.
The point is that it SHOULD work like it does on Mac.
How do you know that it working on Mac isn’t sheer luck / coincidence and what you’re trying to do here is even supported?
It is supported. People have been using it. It was recommended on this forum to do that so all the child components get scaled with the parent.
It saves doing all the manual bounds setting in resized().
Again: we are also using an OpenGLContext to speed up our rendering AND we scale our entire UI by using transforms.
You do NOT need to inherit from the OpenGLRenderer class to do that. The OpenGLRenderer class is designed to let you render OpenGL stuff from a background thread.
It all works fine on Windows (our primary development platform). All you need to do is add a member variable of the type “OpenGLContext” and then attach it
In your plugin-editor class definition somewhere:
OpenGLContext openGLContext;
Somewhere in your constructor of your plugin-editor:
openGLContext.attachTo ( *getTopLevelComponent () );
That’s literally all that is required. No need to inherit from OpenGLRenderer and confuse/break the rendering.
When does it render your OpenGL if renderOpenGL() isn’t called?
What about setContinuousRepainting(true) ?
When do you create your shaders if newOpenGLContextCreated() isn’t there?
How do you get rid of your resources if openGLContextClosing() isn’t called.
Surely inheritance is the best way to use it?
Anyway, you’re obfuscating the bug.
Simple misunderstanding. I thought you wanted to simply accelerate the standard Juce UI drawing and scale it. There really is no need to be so hostile.
I didn’t even know standard Juce UI stuff could be sped up like that! LOL.
Is there any chance someone from Juce can look into this, please? It’s breaking my whole rendering chain, because I added the OGL panel late in development, and I’ll have to go back to manually scaling everything again, which would be a shame is it may be a simple thing to fix?
Thanks.
edit this is also nothing to do the Windows scaling. As it goes wrong irrespective of any Layout Scale.
Dave H.
@ Stenzel
OK I just managed to use a hack for this to work!! It is dodgy though, but you don’t have to alter any Juce code to ‘fix’ the problem.
You have to make the OpenGL component think it has been resized.
By:
viod MyEditor::resized()
{
.
.
editorBase->panel->setBounds(24, 24, 976, 400); // *NB. Last parameter changed!
editorBase->panel->setBounds(24, 24, 976, 402);
}
The second one being the bounds I actually want.
So I’m guessing there’s an ‘if’ somewhere that doesn’t check the parent transform changing on Windows. I don’t know for sure, it just looks like that, 
Thank you Dave!
I already have the same workaround hack in my code because Juce cannot handle changes to the component hierarchy during runtime.
It would be nice to get an official statement from Juce maintainers regarding this bug.
Stefan
@Stenzel
Why didn’t you let me know about your ‘fix’? It would have saved me a week of heartache and worry! 
Juce transform hierarchy does work outside OpenGL components though. Also this is a Windows only bug.
Yeah, this forum can make us feel left alone sometimes.
Laters,
Dave.
Dave,
That hack fixes a completely unrelated Juce problem that also occurs on macOs.
In my case this helped:
setBounds(1,0,w,h);
setBounds(0,0,w,h);
And yes, it also took me several attempts to solve it in a clean way until I gave up.
Stefan
1 Like
Can you say what the unrelated problem is, and did you report it to the github issues list?
@DaveH
Dave,
I have a base component that is usually parent of all other UI components, including one with an OpenGLContext attached. During runtime, the OpenGL component can be switched to occupy the whole window, in this case the relation of both components is reversed, meaning the former parent becomes the child and vice versa. All child components remain children of the former base component, except the former OpenGL component.
Juce cannot handle this properly, but with the above mentioned hack it works.
(And no, the component hierarchy is not cyclic at any point.)
Can you point me to the github issues list? Didn’t know about these.
Stefan
The usual place you get the code… second tab from top left.
Rest assured that we do read every post and we’ll investigate and respond to posts that require our attention. With ADC coming up next month things are rather busy so unfortunately our response times might be slightly longer than usual.
Can you see if the following commit fixes the issue for you?
2 Likes