Panel Animation Lag on Intel Mac
-
I have created this animation within my plugin and it works smoothly on Windows and Macs with M chips. All users with Intel chips have reported a reduced FPS for the animation. It is important to note that Intel mac users see a constant reduced framerate regardless of the number of dots drawn. So I do not believe the draw time is exceeding the duration of the timer.
I am building the plugin with a M2 mac. Is it just as simple as me needing to build on an older mac? Or maybe just an adjustment to the Xcode project?
Do you have any theories for why this is happening and how to resolve this issue? Thank you for your help.
-
O obolig marked this topic as a question on
-
@obolig are you drawing one drop shadow per dot? That‘s very expensive.
-
@Christoph-Hart That was my first thought, so I replaced the secondary dots with one single blurred shape. This basically halved the number of objects, but did not fix the issue for Intel macs and only reduced the draw time on my windows computer from 10ms to 9ms. On Mac M2 it takes ~2ms to draw each frame including blurred dots.
I checked on a friend's Intel computer today and confirmed that the frame rate does not change whether there are 4 dots or >100.
-
@Christoph-Hart I set up two clocks to measure how long it is taking to draw each frame and the wait time in between each timer callback. I've set the timer to 30ms. On windows, the max draw time is ~10ms resulting in a wait between timer calls of ~25ms. When it takes less time to draw, the wait in-between TimerCallbacks becomes larger, as expected, because the two clocks should add up to 30.
On intel Mac, it takes nearly the same amount of time (13ms) to draw, but it is waiting much longer (174ms) to retrigger the timerCallback .
The draw-time is well below 30ms on this 2014 macbook, so it should be good. The wait between timerCallbacks is the issue. This is with no drop-shadows/blurred-dots. Any theories of what could be causing this?
-
@obolig I figured out the issue, but I wouldn't really call this a solution. Turns out Intel Macs HATE LookAndFeel. My images folder is literally empty because everything was made with LocalLookAndFeel's/PaintRoutines. This includes static objects like the background and glass overlay. I replaced these two panels with image controls and the lag went from 174ms down to 40ms. This is including the visible animation.
I have run the same test on my windows computer and found that removing these 2 panels does improve the frame rate, but only by 3ms. This is compared to the 134ms improvement on intel Mac.
I would also like to point out that it is not just an issue with panel controls. I enlarged the top horizontal slider (not animation) to fill the entire UI and found that the frame rate went from 40ms to 85ms. This means it is connected to size of ANY control that uses LAF.
I hope all of this information helps to fix this bug.
-
@obolig are you using the blur function for the „glass effect“?
-
@Christoph-Hart I use blur all over the place (including glass). After commenting out ALL blur, the framerate was improved significantly. I would have suspected this did not affect separate timers since the glass and background should only be drawn on initialization. Why is this only an issue on Intel?
-
@obolig the blur in HISE is the JUCE blur and is super slow. It's all executed on the CPU. No issues on desktop Intel on Windows.
Any permanent blur on the UI, with the current blur implementation, will be a hit. I use it on hover, but that's only one control at the time and rather small.
After testing drop shadow, that performs so much better so I'm thinking on using that instead. I will test it out this weekend. It can take a path so thats
I would, however, love to be able to blur out the UI when a new panel appears on top. This needs a faster blur (maybe the new melatonin) as well as a way to only affect the elements underneath, not the ones above the blurring panel.
Currently I have to screenshot the UI and use that, which doesn't look nearly as cool and won't show any changes that could happen underneath.
-
@aaronventure yup making a blurry modal dialog background was also my intention but the performance is in fact so bad that I ditched the usage of the blur.
At the current state it‘s completely worthless for anything bigger than 100x100px.
The melatonin blur is also on the CPU so while it’s much better optimises it will still not come anywhere close what you can expect when utilizing the GPU and there is currently no way to do a GPU based blur within the JUCE graphics.
-
I ended up recreating the background and glass in affinity photo. Also removed the blur from the dots. All of this brought the time per frame down to 45ms. I'm happy with this. Especially since it means it will be slightly slower for ~1/3 of users.
Thank you for all your help @Christoph-Hart and @aaronventure
-
O obolig has marked this topic as solved on
