I have 2 questions about Component::paint in juce you may would answer.
I am about optimizing my code to minimize repainting where I have setOpaque to true for
several components i.e. sliders and listboxes. Then I put a DBG statement into its parent
paint methode to see whether that method gets called or not.
I noticed 2 things here that I don’t understand:
On MAC:
The parents paint method get called if I set the slider value of one slider with the value of
another one using slider2->setValue(slider1->getValue(), false, false) but if I don’t link those two slider and
simply drag a single slider, then it doesn’t get called.
Same thing if I update a progressbar with a slider value. The progressbar is opaque but the parents
paint methode still get called. Why is that?
On Windows:
Doesn’t matter what I do here, the parent paint methode doesn’t get called with
linked sliders and not while dragging a single slider and even the progressbar
doesn’t affect the parent paint method (That is what I have expected…)!
The CPU usage of the MAC version of my plugin is about 10% higher than the Windows version.
Is this normal and if yes, could it be related to the above issue?
It really makes me nervous cause I don’t understand why
the 100% same code gives such differences on MAC and Windows!
From my understanding MAC, does not support setOpaque but then it would always
process the paint method of the underlaying component and that would create
a CPU overhead, wouldn’t it?
Seems that I hit the same problem with the core graphics…
I did lot’s of things to optimize. I even tried setBufferedToImage w/o success.
The overall graphic performance on MAC is worse than Windows and since I hit this
setTiledImage issue some weeks ago, I don’t trust in core graphics anymore so
I’ll give your software renderer a go tonight.
Don’t know why people always trying to tell me that MAC is the better solution
for any kind of graphic work if the guys from Apple aren’t able to write a propper
graphics renderer.
You should sell your software renderer to apple, Jules.
Works much better now, thank you for the hint!
using juce graphics renderer has improved rendering alot but there is one thing
I got faced with:
I changed the scroll direction on my Macbook Pro accordingly to my Android phone (I guess same as iPhone)
but that change has no effect using your graphics renderer if I run my app standalone (there are some listboxes
inside that scroll the opposite direction to what the “hacked” OS does if I use your renderer!).
Running it inside a host works the same direction like the OS.
Can’t answer that. The only thing I noticed is that since I use your renderer, it doesn’t not
scroll along the “hacked” scroll direction of the OS anymore. It seems that your renderer
is not following the OS scroll direction or at least is ignoring the hack.
No, you’re getting confused there - the scroll wheel events have no connection whatsoever with the renderer. You must be misinterpreting something else that you’ve changed.
Okay, you’re right! It has nothing to do with the renderer but the problem remain and it appears if I compile
standalone in release mode. Everything is fine in standalone debug mode.
I am for 100% sure that I am NOT touching anything that could create that effect!
The vst plugin version works fine in both, release and debug mode!
There’s nothing in the library that could possibly reverse the scroll-wheel - it must be the OS that’s changing its behaviour. Perhaps the OS is deciding whether that feature should be enabled on an app-by-app basis?
