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