Slow Frame Rates on 2017+ Macs

Wait what… “this Metal backend”?? Sounds intriguing - what is it?

See dave’s reply around #24 Slow Frame Rates on 2017+ Macs

It means they are way ahead of Juce itself?

You can use the async metal backend right now in JUCE by specifying JUCE_COREGRAPHICS_DRAW_ASYNC=1 in your project’s preprocessor definitions.

1 Like

Thanks, can we use metal shaders yet? Or enable proper GPU rendering with it?
I don’t think I understand what ‘backend’ means at all.

Here’s what I initially discovered:

So “no” to Metal shaders and I’m not quite sure what you mean by “proper GPU rendering”?

1 Like

Thanks, I meant setting up our own triangle lists and sending them to the GPU to be drawn exclusively.
edit like we currently have with OpenGL.

So I’ve had mixed results using this… while it works really well on my system, it has flashing on my EQ’s Spectroscope/Graph Component on my client’s MacBook Pro with Mojave even when he updates other objects unrelated to the EQ.

I’m wondering if it’s related to the fact that I’m using a Base SDK of 10.12 with a Deployment Target of 10.8

Anyone else have any reports of flashing when JUCE_COREGRAPHICS_DRAW_ASYNC option is enabled? The Component in question has an Opaque Component over a non-Opaque Component with dragable nodes for each EQ band.

My gut feeling is that it’s going to be system dependent based on the graphics hardware and is due to the opacity of the Components.

Cheers,

Rail

I’m using SDK 10.13, deployment target 10.9.
I’m not sure if I’ve got a case like that though…

Do you use ColourGradients? I experienced the same thing at some point and replacing a gradient fill with a solid one fixed the issue.

Actually I do use a ColourGradient for my background… but it’s rendered to an Image before the paint() method… so don’t think that’s it (I’ll do some tests anyway).

Thanks! Best wishes for the holidays.

Rail

To be honest - The whole point of deprecation is so developers can get used to the new ways, BEFORE the ‘AXE’ falls down. With Metal being out for half a decade now, isn’t it time to change?
A lot of us pay Juce people to develope Juce, to give us time to work on our plug-ins etc. I don’t understand the delay.
I’m sorry, I guess I’m a little frustrated and worried about OpenGL being ‘Hobbled’ to a standstill by Catalina, and there is no replacement yet - we could also do with some DirectX for Windows as well, as not everybody has OpenGL on that platform either… :slight_smile:

4 Likes

I just wanted to add that this solved a bunch of graphic slowdown issues on my 2013 Macbook Pro, running Logic Pro X 10.4.8 on OS X 10.13.6. I noticed this console message when firing up logic to debug the plugin:

2020-02-06 10:45:46.868956-0800 Logic Pro X[71541:6609282] Metal GPU Frame Capture Enabled
2020-02-06 10:45:46.870070-0800 Logic Pro X[71541:6609282] Metal API Validation Enabled

So it looks like the new version of Logic Pro X uses the Metal framework.

Those are messages relate to metal debugging tools you can disable in Xcode. They are meant to slow performance down

You miss my point. a 2013 mac book pro running 10.13.6 can support Metal-based rendering, and also that LPX 10.4.8 uses the metal framework for drawing now.

what’s the point in your point?

My point was that this issue affected retina laptops that predate 2017+ macs, and this solution also cures those issues.

In my case, it’s a 2013 Retina MBP, which shouldn’t work with the Metal graphics according to which computers can use Metal (based on graphics card), but this DRAW_ASYNC fix cures the slow frame rates.

Hence the reason that I wrote

1 Like

Why do you say you have a 2013 MBP that does not support Metal? Apple shows 2012 and up MBPs should have support.

I have also observed better performance on a 2013 MBP using this change, so I don’t question the finding.

1 Like

you’re right! I was looking up the video card for this laptop and didn’t see it listed in most every resource I checked for compatibility. I don’t know how I missed that one.

Hey everyone, sorry to bring this topic back up again. It recently saved my life, but I’ve now run into another issue and I wouldn’t know where to start to investigate it.

The fix worked amazingly well for my mac, I’m sure everyone remembers the ecstasy felt when seeing it activated.

However, I’ve now applied a setGlobalScaleFactor() and on my mac, the drawing is back to slow. It seems as slow as it is without the fix. On linux there’s no slowdown.

(However, on linux I’m getting artifacts when moving stuff around, so I may not use it at all… Although it is mighty convenient.

Should I report the artifacts with reproducible code? On other posts @Jules asks for examples of the repaint not working. Is this still of interest?)

Upon further investigation, the slowdown is barely noticeable until values of about 0.7, and get worse and worse closer to 1. But at 1 everything is fine.

1 Like