Slow Frame Rates on 2017+ Macs

[DaveH]

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.

[dave96]

Here’s what I initially discovered:

@dave96

I think what happens with the async and layer flags is that:

1. The window has a CA layer which creates a Metal context to draw on to
2. In your paint method, instead of directly drawing on to the screen via CoreGraphics, these instructions get queued up
3. Another thread(s) then dispatch the graphics calls using Metal on to the context

This is just a rough guess from looking at the profile trace though. I’m not a Metal expert so if anyone has more insight I’d be keen to hear.

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

[DaveH]

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.

[railjonrogut]

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

[dave96]

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

[masshacker]

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

[railjonrogut]

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

[DaveH]

@t0m

If Apple marks something as deprecated then it will continue to function as it always has until it is eventually removed from the SDK. Deprecated functionality is unlikely to receive any updates, but MacOS’s OpenGL implementation hasn’t changed significantly since 2010, so that’s not much of a concern.

We’re currently investigating post-OpenGL rendering strategies, so when the axe does fall we should be ready. But I must stress again that deprecation does not mean that you cannot continue to use the functionality.

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…

[matkatmusic]

@ed95

This has been added on the develop branch in a277256 , so you can enable the JUCE_COREGRAPHICS_DRAW_ASYNC flag to test it out.

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.

[olilarkin]

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

[matkatmusic]

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.

[olilarkin]

what’s the point in your point?

[matkatmusic]

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

@matkatmusic

@ed95

you can enable the JUCE_COREGRAPHICS_DRAW_ASYNC flag to test it out.

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.

[Verbonaut]

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

Mac computers that support Metal

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

[matkatmusic]

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.

[Franchovy]

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.