Apple Metal acceleration

[ffx]

Hi,

I would like to know if JUCE is already capable of using Metal2 for GUI acceleration. Also is it possible to use Metal Shaders?

Thanks.

[DaveH]

I’m hoping they don’t wait until OpenGL is dropped first.

[jrlanglois]

JUCE isn’t Metal capable yet.

[ffx]

Thanks. This makes JUCE quite unattractive for apps with big / normal GUIs, since rendering the GUI on the CPU only is extremely slow on macos. Those apps will lag a lot and feel sluggish.

[jules]

@ffx

This makes JUCE quite unattractive for apps with big / normal GUIs, since rendering the GUI on the CPU only is extremely slow on macos.

Woah there! Nope, it’s not a simple leap from “JUCE doesn’t yet support Metal” to “JUCE is only using CPU rendering on OSX”

We use the CoreGraphics renderer by deafult, and it uses Metal, so JUCE’s rendering on OSX and iOS is very fast indeed. Probably won’t get significanly better even when we add our own Metal support.

The problem at the moment is Windows, where our GL renderer is fast, but some people people avoid it because of compatibility problems, so what we’re working towards is a Metal/Vulkan solution that’s equally good on all platforms.

[yfede]

@jules

so what we’re working towards is a Metal/Vulkan solution that’s equally good on all platforms

Hooray

[ffx]

Well, I think CoreGraphics UIs can be also rendered on CPU, at least if you currently have a look on bigger JUCE GUIs under macos (which do not explicitly support OpenGL like Falcon), the performance experience seems to be pretty poor. Which is clearly not the fault by JUCE, this was not my intention to express. It clearly is Apple’s fault, yet these problems seem to be an accomplished fact.

Good to read now that you are working on these problems. Thanks.

[ffx]

@jules

We use the CoreGraphics renderer by deafult, and it uses Metal, so JUCE’s rendering on OSX and iOS is very fast indeed . Probably won’t get significanly better even when we add our own Metal support.

Could you give me a reference for this statement? As far as I know, Core Graphics normally nowadays renders on the CPU since introduction of metal or the removal of QuartzGL or so. At least I cannot find any hint that CG is using the GPU.

Also, wouldn’t then e.g. Falcon perform very similar if not better in CPU GUI mode than in OpenGL GUI mode? Here on two machines (High Sierra), I can see an obvious framerate dropping, if I use CPU GUI mode. Or is it because they do not use the latest JUCE API?

[t0m]

In OpenGL mode the drawing commands happen asynchronously, which moves some of the effort off the main thread and can help things render quicker. We may be able to do this with CoreGraphics too:

Slow Frame Rates on 2017+ Macs

Hey guys…This is a weird one! I’ve noticed that drawing PNG graphics is slow on my iMac Pro 5K display, but on my connected Thunderbolt display on the same iMac Pro, it’s fast. I mean I can literally drag the interface between screens and see the speed boost. If I go to System Preferences - Display Settings - Color - and select the color profile sRGB IEC61966-2.1 for the iMac’s display, it becomes fast. So it seems to be the translation from sRGB to the display’s color space. Has anyone run i…

I’ve also recently incorporated Skia’s rendering engine into JUCE and benchmarked its Metal backend. Calling the Metal backend is no faster than using CoreGraphics.

[ffx]

I would say that the sRGB profile issue thing is more an indicator that something was rendered on the CPU, not GPU. Since other color modes might use simply more bitmaps than sRGB IEC61966-2.1, so then the pixel count was increased. A GPU almost wouldn’t care here at all, while for a CPU, not made for massive data manipulation, this already is an issue. Reading your linked thread indicates in this direction even more (opengl is not affected, etc).

As far my non pro research indicates, CoreGraphics will be only accelerated by GPU, if you call it through CoreAnimation.