this may be only windows related, but it might be relevant to the general juce population so ill post it here…
i came across a weird problem when using a component with a scrollbar (viewport). every now and then when clicking the scrollbar button the app would hang while the CPU would max out, sometimes for 10 seconds or more and then return back. i thought it was something i was doing wrong until i found i could replicate the same behaviour when running the jucedemo.exe downloaded from jules’ site.
now… it turns out that i could stop this from happening by setting the affinity for the process to run on one CPU only (i have a dual core athlon) which gave me some things to think about.
through debugging i found the app was stuck in the Button::repeatTimerCallback function, where it was doing some ridiculous number of iterations of the numTimesToCallback loop.
the particular part in juce_button.cpp is line 590
this was returning the maximum int value when now and lastTimeCallbackTime were equal. which was strange because i would assume these times would normally never be equal. however im guessing that because i have effectively 2 CPUs, each CPU could run the time queries in parallel and return the same value. :shock:
however i thought that shouldnt cause a major problem as the jmax macro should handle the situation where now == lastTimeCallbackTime yet it turns out it must have been getting confused with the varied types provided to the macro.
to fix this i ended up explicitly casting the inputs to the jmax function like so:
which solves the specific problem i was having, but im not sure whether this is something that might affect a wider range of situations, hence the post.