JUCE 5.4.1 Slow GUI


#1

Hello,

After updating to JUCE 5.4.1, one of my plugin has very slow gui response issue.
This plugin has about 1300 parameters and if I don’t add parameters with “createAndAddParameter”, gui works normally.
And also if I compile with JUCE 5.3.2, gui works fine.

So I guess this is related to new AudioProcessorValueTreeState stuff.
Does anyone else have similar issue?

Thank you


#2

What’s displayed on your GUI?


#3

The plugin GUI has lots of sliders and buttons.

I tested with 100 parameters and it’s fine.
With 500 parameters GUI response starts to become slower.

The plugin works just fine with 5.3.2.


#4

So you have 1000 on-screen sliders? I’m just trying to see what it would take to reproduce the issue in a simpler plug-in.


#5

The plugin has tabbed windows.
So about 160 sliders and 100 buttons on the GUI at once.


#6

Hi !
I may have a similar problem.
I am using in a very simple plugin (5 sliders) the following code for one of the slider:

parameters.createAndAddParameter ( "l1Volume",       // parameterID
                                          "Volume",       // parameter name
                                          "",           // parameter label
                                          NormalisableRange<float> (-1010.0f, 12.0f,    // range
                                                 [](float start, float end, float gain) { return (float)cv01todB((float)gain); },
                                                 [](float start, float end, float dB) { return (float)cvdBto01((float)dB); }),
                                          -6.0f,         // default value in dB
                                          [] (float p) { return dBToStr(float(p)); },
                                          [] (String str) { return (float)dBstrToDbl(str) ; });

The functions cv01todB and cvdBto01 are very simple functions that convert the [-1010 +12] range to [0 1] and reciprocally.
I added a trace to these functions, and a counter to know how many times they were called. I also generated the application with JUCE v5.3.2 and JUCE v5.4.1.
Here are the results (number of calls):

  • launching the standalone plugin:
    JUCE v5.3.2: cvdBto01: 2 times, cv01todB: 2 times
    JUCE v5.4.1: cvdBto01: 279 times, cv01todB: 7 times
  • clicking on the widow title bar, then clicking in an other application:
    JUCE v5.3.2: cvdBto01: 0 times, cv01todB: 0 times
    JUCE v5.4.1: cvdBto01: 6 times, cv01todB: 0 times
  • clicking somewhere in the slider:
    JUCE v5.3.2: cvdBto01: 4 times, cv01todB: 1 times
    JUCE v5.4.1: cvdBto01: 25 times, cv01todB: 5 times
  • clicking in another slider or hoovering the mouse over the slider:
    JUCE v5.3.2: cvdBto01: 0 times, cv01todB: 0 times
    JUCE v5.4.1: cvdBto01: 6 times, cv01todB: 0 times

Each time, the pattern is the same in 5.4.1: there is 1 or more sequences of 3 calls to cvdBto01:

[200000441]  dB->01   -0.545465 --> 0.556425  ~~   -0.545465
[200000442]  dB->01   0 --> 0.672414  ~~   0
[200000443]  dB->01   0 --> 0.672414  ~~   0

One call for the actual position of the slider (here, at -0.545 dB, corresponding to the physical position 0.556425 in [0 1]), then 2 calls to convert value 0 dB (corresponding here to the physical position 0.672414). Note that 0 dB is not the default value for the slider, the default being -6 dB. (the trace displays the # of calls so far, 441 to 443 in this case).

So I imagine, if I had a hundred of such sliders, each one with a function being called a dozen times, that the interface may become quite slow…

Hope this simple example may help finding the bug in 5.4.1.

Regards.


#7

One big difference i noticed is, that the latest JUCE now notifies parameter changes also if the parameter value stays the same. I like that new behavior. Maybe it worked in the older JUCE version accidentally because it didn’t notify param changes with the same value.


#8

OK, one part of these issues has been fixed:

The recent changes had accidentally introduced an O(N^2) lookup of parameter values, which was previously O(N), but has now been reduced to O(1). This will mean it’s slightly slower for a small number of parameters (but in this regime it’s consuming negligible CPU anyway), but much much faster for a large number of parameters.


#9

Isn’t std::map lookup O(log N)?

Was there a reason for not using std::unordered map here? Maybe because it uses a juce:: String as the key?


#10

Ah yes, O(log N).

JUCE’s live build engine can’t compile std::unordered_map. I’m not sure why but Stefan had a good go at it a while back and ended up admitting defeat.


#11

Hi !
I have recompiled my project with the today develop branch of JUCE, with no change: still get hundreds of calls to the conversions functions.

I have put my project on github, so you can have a look a it.
It does a lot of traces using DBG, so you can check what’s happening.

Regards.

https://github.com/jack461/Orangejuce.git


#12

Are you sure you are having performance problems because of the conversion function calls? Modern CPUs should be able to do tens of millions of those per second easily.


#13

I’m not talking about performance problems: when I just launch the application, compiled in JUCE 5.4.1, doing nothing else, I get 275 calls to the conversion function for just 1 slider, while I have only 3 calls with the version compiled in 5.3.2…


#14

Thank you for your update.
I just compiled my plugin with latest develop.
And now my GUI works fine like as JUCE 5.3.2.