Performance Problem with Control P5
in
Contributed Library Questions
•
8 months ago
Hello,
this problem is really hard to describe, cannot paste all the code which contains the problem.
I have written a class called "ControllerManager", which makes it even more convenient to use some of the CP5 Controllers, performs some auto-layout and enables Serialisation. All the controllers of a single ControllerManager are pooled in a ControllerGroup. Each ControllerGroup contains an own instance of ControlP5.
To give you an idea how it works:
There is another class called "GraphElement", each instance containing his own ControllerManager to control some Parameters. During Runtime, it is possible to select a certain GraphElement to edit it with the Controllers managed by the ControllerManager.
The Problem is: When a controller Group of any ControllerManager is shown (= the controllers are visible and can be changed...), it will take sth. like 50 % of CPU Performance when the frameRate is 30!
EDIT: If no ControllerManager is selected (= no Controllers are visible, all Controllers have got the "hideControllers" Message), the CPU performance is fine.
I already tried a lot to isolate the problem without success:
- The problem appears even when there is only a single Instance of the ControllerManager
- I commented out the ControllListener, no effect on performance
- I commented out all the logic which enables Serialisation, no effect on performance
EDIT: if the Controllers aren't pooled in a group, no effect on performance
I found out, if i did not add any Controllers to the Manager, there is no performance problem. So, just an empty ControllerGroup is displayed.
I know it is an imposition, but has anybody of you an idea where to search to solve the problem?
I'm thinking about to rewrite the ControllerManager with G4P, but, the current implementation works perfect besides the performance problem...
Many Thanks for reading anyway!
this problem is really hard to describe, cannot paste all the code which contains the problem.
I have written a class called "ControllerManager", which makes it even more convenient to use some of the CP5 Controllers, performs some auto-layout and enables Serialisation. All the controllers of a single ControllerManager are pooled in a ControllerGroup. Each ControllerGroup contains an own instance of ControlP5.
To give you an idea how it works:
- cm = new ControllerManager("foo", this, controlWindow);
- // add a Slider which can be addressed with "SIZE", current value: 10, min: 0, max: 20
- cm.addInt("SIZE", 10, 0, 20);
- ...
- cm.showControllers();
- ...
- this.ellipse(x,y, cm.getInt("SIZE"), cm.getInt("SIZE"));
"this" is a reference to the PApplet.
There is another class called "GraphElement", each instance containing his own ControllerManager to control some Parameters. During Runtime, it is possible to select a certain GraphElement to edit it with the Controllers managed by the ControllerManager.
The Problem is: When a controller Group of any ControllerManager is shown (= the controllers are visible and can be changed...), it will take sth. like 50 % of CPU Performance when the frameRate is 30!
EDIT: If no ControllerManager is selected (= no Controllers are visible, all Controllers have got the "hideControllers" Message), the CPU performance is fine.
I already tried a lot to isolate the problem without success:
- The problem appears even when there is only a single Instance of the ControllerManager
- I commented out the ControllListener, no effect on performance
- I commented out all the logic which enables Serialisation, no effect on performance
EDIT: if the Controllers aren't pooled in a group, no effect on performance
I found out, if i did not add any Controllers to the Manager, there is no performance problem. So, just an empty ControllerGroup is displayed.
I know it is an imposition, but has anybody of you an idea where to search to solve the problem?
I'm thinking about to rewrite the ControllerManager with G4P, but, the current implementation works perfect besides the performance problem...
Many Thanks for reading anyway!
1