GUI Drawing Efficiency


#8

AFAIK it doesn't anti-alias like JUCE does. And it will have the same bottleneck I described above - i.e. the path flattening or tesselating must be done on the CPU. All openGL 2D renderers will have this issue - it's unlikely that any other library could be significantly faster than JUCE, because GL just isn't built for it.


#9

Yes, i see, thanks for clarifications.
I hope to find time to hack together a NanoVG render backend just to see what it looks and performs like with an existing juce application.


#10

Hi Jules, 

The drawing is not the problem, I can draw/repaint images very efficiently using coreimage and juce native.

I've created a test plugin with 250 sliders with listeners, and runs very smooth without lags.
Then another plugin with 5 sliders, but this time I've created 30 instances in reaper, when I start to open their guis, sliders starts to lag, if you open all instances gui, the lag is very noticeable.

so I don't think it's a problem with the paint components, for me, the render engine is fast


#11

Well it's presumably the host or OS repaint schedule adding some kind of overhead.

But like I've said hundreds of times before on this forum: The only way to investigate this kind of thing is to USE A PROFILER to measure what's actually happening!


#12

Thanks Jules, 

I'll see if I can identify where the bottleneck is, I've never used a profiler yet,  when I have some time I will look at this.


#13

as you said you tested in reaper, perhaps that could be related : http://forum.cockos.com/showthread.php?t=165227


Drawing paths using OpenGL: Polyline2D
#14

Yes, 

I noticed that reaper vst2 plugin gui gets continuously repainted a rectangle on the bottom part of the gui, 

I've done the same test with vst3 (30 gui instances) and all run smoothly... I've tested too a plugin with a big VU meter (bitmap based) and run all smooth with 30 gui instances opened.

So, isn't a juce problem... 


#15

Juce Plugin Host process from "activity Monitor" %CPU,  10 plugin instances (with gui opened):

VST2: 30.1% CPU

VST3: 6% CPU 

Macbook pro mid 2014, i5, 8gb ram, ssd disk, osx 10.9. 

Base sdk 10.10, comp 10.7, release build with fastest optimizations, coreimage.

 

Sorry, for now I will not profile because I don't know how yet, but when I get some free time, I will investigate it


#16

I think I found the problem, 

on VST 2.4 AudioProcessor::createEditor() gets called twice when you open the plugin gui.

You can reproduce it in Juce Demo Plugin: AudioProcessorEditor* JuceDemoPluginAudioProcessor::createEditor();

Edit: apparently this is normal,  http://www.juce.com/forum/topic/plugineditor-ctor

 


#17

Profilers are super-awesome.  Click, run, ohhhhhh ....:)


#18

Yes - there's really no point in spending time looking at a performance problem unless you profile it. Looking at the numbers in Activity Monitor won't tell you much.


#19

Does this still hold true?


#20

Yeah, pretty much.


#21

BTW: for anyone reading this (old!) thread who’s interested in graphics performance, I should mention that Tom Poole and I will be doing a workshop session at ADC this year about how to optimise rendering speed, with slightly more up-to-date info than in here!


#22

Metal and Vulkan with a side helping of CUDA?


#23

Would anyone care to elaborate on this? What would those 4 lines of code be?

I’ve never tried any of the GL stuff thinking that it would only be applicable for 3D stuff, but I’m drawing a lot of bitmaps and if it’s faster with GL, that would be fantastic.


#24

probably the

OpenGLContext context;

as a class member of your OpenGLRenderer component
hint:

class MainContentComponent : public Component, public OpenGLRenderer
{
    ....
};

and then in your constructor

    context.setRenderer (this);
    context.attachTo (*this);
    context.setContinuousRepainting (true);

the setComponentRepainting() causes this line in OpenGLContext::renderFrame() to call your component’s paint(Graphics& g) method:

notice that on line 250, that’s where the renderOpenGL() callback happens, and that is also (partly) why the components will always draw on top of the OpenGL viewport.


#25

Thank you! I’ll take a look at this.


#26

Is that line truly needed? It seems only if you want to do 60 fps animations 100% of the time. If you only want to accelerate the occasional update, then it seems a bit wasteful to redraw the entire GUI over and over and over.


#27

You just need to create the context object and call attachTo().
No need to inherit OpenGLRenderer or to call setRenderer or setContinuousRepainting unless you’re doing actual raw GL calls yourself.


Opengl + osx == high cpu?