Opengl + osx == high cpu?

opengl

#1

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).


#2

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)
        return;

    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());
}


#3

would an example project help anyone debug this?


#4

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


#5

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.


#6

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.


#7

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