Hi tor - I has a quick go through, and here's a quick mod that helped a lot on my little notebook...
It's using the bitmap cache idea - but only for the EQ curve. The FFT is still live, as there's no point cacheing something that changes every single frame. The new components are inside the little module that sits above your graph primitives, linking them to the view and area.
The cache prevents all of those graph modules from recalculating their images every time the screen is redrawn - instead, they draw to the bitmap only when any of the array contents gets changed by moving a control. I also reduced the number of points being calculated for the graphs themselves - they're now set to have the same number of points as the there are pixels across the view - saving all those float array modules an awful lot of calculations.
Even with the cacheing, there's still a lot of CPU load when you are moving the controls, but over here, it is much lower when the plugin is just running normally.
The only easy way to lower the 'mousing' CPU load would be to limit the speed that the controls update.
Quantising the display resolution might also help - i.e. make it so that very tiny parameter changes, that are too small to see on the graphs, don't bother to send a trigger
tor wrote:retriggered on the redraws. this i have not been able to reveal with the triggercounter so i guess it is not the case
This can indeed be the case, because triggering a primitive causes it to request updates from the modules supplying it with values. Unfortunately these 'backwards' triggers do not show up on the counter - in fact, this example will show you how weird they can be...
2 + 2 = 8 !!! but, 2 + 2 + 1 = 5.
If you change the top two numbers, nothing happens at the outputs because of the trigger blockers. Change the third float, and the correct answer appears at the end - the second add sends a 'reverse' trigger to the first one asking for its correct result - but this doesn't cause the upper 'result' display to update, only the primitives that made the 'request' will get to see the answer - hence you won't see it on a trigger counter.
This can sometimes happen with GUI's - ReDrawing a views causes the graphics elements to update, and in turn, they request the latest results from green primitives that are supplying the variables.
If the re-calculation and the ReDraw are both driven by the same trigger, it doesn't usually matter - the triggers have tags so that SM knows if they've already been actioned. But if a view is triggered independently by a ticker, it can cause a lot of extra calculations.
You do not have the required permissions to view the files attached to this post.