All the GL error checking was introduced there. If you’re running a debug build, then CPU and GPU threads will be sync’ed at every glGetError() call, and if there’s a lot of drawing to be done, flushing the whole GL queue to get current state could be very expensive.
In a release build, what times do you see?
EDIT - you specified release, sorry. Then I would say - double check that glGetError is not being called in your release build, and/or comment that out. It could certainly have the effect you describe. Since your frame times look suspiciously like a multiple of frame times, that may be what’s going on: a glGetXXXX type command that causes the thread to stop while all drawing takes place and the swap happens.
It is as simple as this:
The whole OpenGL Renderer code is just fine. It is the Juce Demo itself that causes the performance loss.
As soon as the TopLevelWindow is used for the OpenGl Context the performance goes down.
If you change line 163 in MainDemoWindow.cpp from
to
everything is fine and you can enjoy great performance.
In my case the render times droped from 22ms to 1.8ms at a canvas size of 2342 x 1177 !
This is also valid for the latest tip of juce version 2.
So the OpenGL Renderer is great, but it cannot be recommended to attach it to the TopLevelComponent.
Perhaps Jules has some ideas on how to improve this.
Wow. Glad you guys got there in the end - I’m not sure I’d have thought of looking outside of the actual GL rendering code!
I’m surprised that it makes any difference when you attach it to the top-level component though… I can’t see any code that would behave differently in that case, so I guess the difference is just that it’s redrawing the underlying components. (But it shouldn’t actually need to do that… I’ll take a look in there and see what I can do)
No… the window itself isn’t transparent, I don’t think it’ll make any difference. I suspect something like e.g. the normal paint routines being called as well as the GL one… I’ll investigate when I get a moment.
