If you turn off the splash screen with JUCE_DISPLAY_SPLASH_SCREEN, you will get very high CPU on the main GUI thread and the timer thread. This is caused by a startTimer(1) call at the end of JUCESplashScreen ctor. Not sure on intention, but perhaps the endif needs to be moved down.
I found this when I ifdef-ed the splash screen out in debug mode.
Drat! Thanks for reporting, I’ll fix that right away…
Drat! Thanks for reporting, I’ll fix that right away…
magnific, user testing license crap
Hello!
This is still a problem in 5.3.1. I don’t have time now to install 5.4.3, but I downloaded it and did a diff, and I can’t see that this has been corrected.
It would be good to fix this before the next guy trying to push a release out the door spends a bunch of time trying to figure out which of his timers is gobbling up a ton of CPU. But if you’ve already fixed it, sorry for bumping this years-old thread!
Thanks!
Doesn’t it just get deleted in the first JUCESplashScreen::timerCallback call though? So the worst is that the timer will run once?
unfortunately not. in the constructor, if the splash screen has already been shown before, the timer is set to go off after 1ms, but the component is not shown. so neither condition in the timer callback is met (because isVisible () == false), so the timer just runs forever calling the callback at 1ms intervals.
this happens to me the second time someone opens my plugin interface. the first time it’s opened splashDisplayTime == 0, so the splash is added to the parent component and made visible. when paint is called, splashDisplayTime is set to the current time, and the timer is set to go off after 2000ms. when the timer callback happens, isVisible () == false and hasStartedFading == false, so hasStartedFading gets set to true, and the fade out animation starts. when the timer callback happens again 2000ms later, hasStartedFading will be true, and the animation will be finished, so the splash deletes itself. everything works properly.
the second time someone opens my plugin interface, the currentTime is > splashDisplayTime + 2000ms. the timer is started with a 1ms interval, but the component is not shown, and neither condition in the timer callback will be met.
I hope this is helpful!
best,
Joe
I guess this is a slightly different problem from the one the original poster was having…
How are you switching off the Splashscreen?
If you use the switch in Projucer to
#define JUCE_DISPLAY_SPLASH_SCREEN 0
Then all what’s left in timerCallback() is a delete this;, just like Dave wrote above…
There is no paint call either, because the addAndMakeVisible is also not happening here:
Is your CPU usage maybe in fact related to the analytics before in the JUCESplashscreen constructor?
Sorry, I should clarify, my problem is slightly different from that of the original poster. I should have read more carefully.
I’m not actually disabling the splash screen by not defining JUCE_DISPLAY_SPLASH SCREEN. The problem occurs when the splash screen is enabled, and JUCESplashScreen gets constructed twice. This happens when I close and open my plugin window.
So the first time my plugin UI is opened, the splash screen works perfectly. If I close the plugin window, the AudioProcessorEditor gets deleted. Then I open my plugin window, and the AudioProcessorEditor gets constructed again, and a new JUCESplashScreen gets created in AudioProcessorEditor::initialise (). That’s when the problem I describe above occurs.
splashDisplayTime is a static global, so the second time JUCESplashScreen gets constructed, it’s non-zero, and provided that more than 2 seconds has elapsed since the first splash screen was shown, we “startTimer (1)” without making the JUCESplashScreen visible.
In the timer callback, the first condition is:
if (isVisible () && !hasStartedFading)
isVisible returns false, so nothing gets executed here, most important, hasStartedFading does not get set to true.
the next condition is:
if (hasStartedFading && !fader.isAnimating())
hasStartedFading is also false, so “delete this” never executes.
the timer never gets stopped and runs at 1ms intervals without either of the conditions in the timerCallback every being true.
it looks like this could be resolved by making hasStartedFading also a static global.
I hope this makes sense! I’m sorry about the confusion! I think I should have started a new thread. I apologize for not reading more carefully before posting.
Best,
Joe
Oh don’t worry about it. We appreciate any bug report!
Great, thanks for the fix!
