Opengl + osx == high cpu?



i implemented opengl via the instructions in this post. it was straightforward and worked, but it add ~200% to my cpu usage compared to not using it (and i’m not doing any sort of animation or crazy drawing). here’s some profile comparisons, first without opengl:

|13.31 s   80.8%|0 s| | threadEntryProc  0x954580|
|2.52 s   15.2%|0 s| | Main Thread  0x9543c3|

then with:

|1.01 min   69.7%|0 s| | juce::ThreadPool::ThreadPoolThread::run  0x9527b0|
|24.20 s   27.7%|0 s| | threadEntryProc  0x952772|
|1.33 s    1.5%|0 s| | Main Thread  0x9525dc|

all i did was add context.attachTo (*this) in my editor, seems like maybe this is a bug? i’m on the most recent version of osx/xcode/juce (10.14.2, 10.1, and develop).


I’m also seeing some crazy CPU usage using a simple OpenGLAppComponent. macOS 10.14.1 and Xcode 10.0. It’s around 65% for one circle drawing, OpenGL only, nothing else going on.

Profiler screenshot attached.

Render method:

void MainComponent::render()
    // This clears the context with a black background.
    OpenGLHelpers::clear (Colours::black);

    if (shader == nullptr)

    auto desktopScale = openGLContext.getRenderingScale();

    std::unique_ptr<LowLevelGraphicsContext> glContext (createOpenGLGraphicsContext (openGLContext,
        roundToInt (desktopScale * getWidth()),
        roundToInt (desktopScale * getHeight())));

    auto mouseRel = getMouseXYRelative().toFloat();

    shader->onShaderActivated = [&glContext, &mouseRel](OpenGLShaderProgram& p)
        auto bounds = glContext->getClipBounds().toFloat();

        p.setUniform("u_mouse", mouseRel.x / bounds.getWidth(), mouseRel.y / bounds.getHeight());
        p.setUniform("u_size", bounds.getWidth(), bounds.getHeight());
        p.setUniform("u_time", static_cast<float>(Time::getMillisecondCounterHiRes() * 0.5e-3));
        p.setUniform("u_border", 0.005f);
        p.setUniform("u_radius", 0.228f);


    shader->fillRect(*glContext, glContext->getClipBounds());


would an example project help anyone debug this?


One crazy but interesting suggestion I’ve seen would be to try Xcode 9.4 or whatever the last 9 was.


This is a known issue with macOS 10.14 and we’ll look into why it might be occurring, but for the time being building against an older macOS SDK should fix the problem.


You can use an older sdk, f.e. 10.13. It’s not a XCode problem, XCode is only an IDE. Apparently this problem is going to be solved with the next SDK update.


Yes, I understood what Ed meant, thanks. Did it solve the problem, modosc ?