Testing Mac GUI performance with Hive 2.1 beta

[Yorrrrrr]

* MacBook Pro 2019 16"
* MacOS Big Sur 11.1
* Ableton Live 11
* VST2

ASYNC YES and 60 FPS is all I need for smoothness. CPU usage is higher. Fans are ramping up.

EDIT: Hive made Live 11 crash horribly.

[waltercruz]

Does it make sense that a plugin format is visually faster than another?

Mac Mini (Late 2012)
Graphics Intel HD Graphics 4000 1536 MB
Monitor LG Ultrawide
Colour Profile LG Ultrawide
Ableton Live 10
OS X Catalina 10.15.7

in a very simple test, scrolling through the presets with the arrows from keyboard, VST and VST3 is instant, Audio Unit has a bit of lag to scroll through presets.

[waltercruz]

Aw, just saw in the first post that "often it's the AU version causing problems".

Well, tested on my Macbook (Early 2013, Catalina 10.15.7, broken video interface, so I'm always on the Intel HD Graphics 4000 1536 MB and never switch to NVIDIA GeForce GT 650M with 1GB of GDDR5 cause it's dead) and the same happens: scrolling through the presets is faster on VST and VST3 than on Audio Unit.

[Urs]

now switch to Async=YES...

[mdstudio]

Thank you for this update! I love the new configuration file. Just loading the Hive's GUI in the previous version used to use almost 60% CPU for me (without playing any notes, animations etc). I was able to reduce it to around 41% by setting:

- Async to YES
- Cache bitmaps to SMALL (but not sure other values result in any perceptible changes)
- Update strategy to AUTO
- Decreasing the frame rate to 10 (this is perhaps a controversial opinion, but I my computer is a bit old so I don't care about having a high fps on an audio plugin, as long as I can use the the plugin without any issues)

My computer is:

Retina, 15-inch, late 2013
Processor: 2.3 GHz Quad-Core Intel Core i7
Graphics: Intel Iris Pro 1536 MB
OS: Catalina 10.15.6
Color profile: sRGB IEC61966-2.1
DAW: Reaper 6.19

Btw, I noticed that the order of the properties in the com.u-he.Hive.Preferences.txt file changes when you load Hive. I kept my editor open when trying out different settings and I kept getting messages that the file kept on changing in the background. Perhaps the file gets written from different places in the code or the type of the key - value structure that's being used to hold these in memory in Hive doesn't preserve the order when iterating through it.

[waltercruz]

now switch to Async=YES...

I did! Audio Unit is always slower to change presets on Ableton. But I tried on Mainstage and Unify, and Hive Audio Unit is smooth on both hosts.

[Piotr979]

still sluggish on my Imac 2017 16GB 1TB. I tried with Maschine and when Hive window is open it slows down the maschine hardware device itself (scrolling in browser).
However: When UI is scaled to 100% is a bit better than scaled to 120%,140% etc.
Also when I click on "Default skin" or "Default size" in Preferences and this little window pops up with selection I can see that in the background Maschine is running with 100% speed with no issues. As soon as I close it, Hive and DAW are slow again.

EDIT: Just realized its because Hive interface is frozen, therefore Maschine works fine again.

[Urs]

still sluggish on my Imac 2017 16GB 1TB. I tried with Maschine and when Hive window is open it slows down the maschine hardware device itself (scrolling in browser).
However: When UI is scaled to 100% is a bit better than scaled to 120%,140% etc.
Also when I click on "Default skin" or "Default size" in Preferences and this little window pops up with selection I can see that in the background Maschine is running with 100% speed with no issues. As soon as I close it, Hive and DAW are slow again.

EDIT: Just realized its because Hive interface is frozen, therefore Maschine works fine again.

You need to edit the preferences file as explained in the first post.

[Piotr979]

still sluggish on my Imac 2017 16GB 1TB. I tried with Maschine and when Hive window is open it slows down the maschine hardware device itself (scrolling in browser).
However: When UI is scaled to 100% is a bit better than scaled to 120%,140% etc.
Also when I click on "Default skin" or "Default size" in Preferences and this little window pops up with selection I can see that in the background Maschine is running with 100% speed with no issues. As soon as I close it, Hive and DAW are slow again.

EDIT: Just realized its because Hive interface is frozen, therefore Maschine works fine again.

You need to edit the preferences file as explained in the first post.

I just changed Draw Async to YES and now everything is smooth. Left other settings untouched.
My mac is : Imac 2017 27 5k Radeon 575 4GB, 3.5GHZ i5
Tried with Maschine latest and Studio One 5 pro

[matamoris]

iMac (Retina 5K, 27-inch, 2017)
Radeon Pro 575, 4GB
Logic Pro 10.6.1
macOS Big Sur 11.1

Draw Async:YES provided the most benefit. I tried several permutations with the other options, but did not notice any additional performance improvements.

[neuromod]

tas, I just noticed the same thing with the Neumann skin for Zebra: a patch playing with the original skin shows ~%2 higher on Ableton's CPU meter than with the Neumann skin. Might be mostly attributable to their refresh rates: for both Hive and Zebra, the original skins seem to update at a higher frame rate than the plugmon skins.

[tasmaniandevil]

Thanks so much, everybody, for helping to test this.

We now implemented a simplified setting in the hidden preferences with the second public beta, revision 10947, which you can find over here: viewtopic.php?f=31&t=560924

V_PROPERTY name='Preference' id='0' value='AllViews:Cocoa View Update Strategy:ECO'.
It can be set to ECO or SMOOTH.

ECO requires the least amount of CPU resources while still delivering great GUI performance.
SMOOTH delivers an even better GUI performance, but at the expense of a bit more CPU consumption.

The default state is ECO and should work fine in most situations.
Ideally you'll never need to touch this setting.
But if you want that extra bit of smooth graphics performance, you can always set it to SMOOTH.

If you had the previous beta installed, the other hidden options will still be present in the file, but they are nonfunctional now.
And the update strategy setting might still display whatever you chose last, but all settings will default to ECO now.

Let us know if this works for you.

[Ploki]

i should really do another benchmark while fiddling with gui settings

[Nimrod7]

Hey,

Maybe I can provide some insight to this topic.
It's torturing me for long since I have seen significant bottlenecks in the frame rate and responsiveness of many plug-in UI's not just u-he.

When you're using external (and probably internal) displays that support Hi-DPI, with "Default for Display" option:



Everything should work as normal:



The OS is actually rendering a Resolution: 3840x2160 (since is a 4K monitor) image, which for most integrated and discreet GPUs is "fine".

Things are getting weird if you use the Scaling Options as below (it's the same monitor, just different scaling:



Then, what happens is MacOS Metal framebuffer renders a 6016x3384 image, and then scaling that down to native res 3840x2160, which has huge impact in the performance, especially on integrated GPUs. This getting worst in larger scaling options which the framebuffer resolution is even larger, exhausting GPU resources, and bottlenecking the frame rate.



For discreet GPUs in recent Macs might be fine, for integrated ones, rendering those resolutions, with dual monitor setups etc, both retina, the GPU might exceed 12K res in both monitors... for example many users have a retina MacBook and an external 4K display, which scaling.

Hope that make sense.
Might be mistaken here, but happy to see if there are any other views on the topic.

Thanks,

[Urs]

The double sized frame buffer is just one aspect. It still works well with CGImages as opposed to CGLayers. Latter are faster when the frame buffer is not scaled. This can be tested with the bitmap caching options in earlier betas.

The problem that remains is the offscreen context we use for our Scopes. This still draws a lot of CPU unless set to eco or fast drawing modes.