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 into this, and/or found a good way of dealing with it? You can see the example image below. You can see how fast it gets when I switch to an RGB.
Just wanted to leave an update for anyone else experiencing this. It seems as if changing the Color Profile significantly fixes the issue, yet with the downfall of brighter reds, which takes away from the warmth of the display. Also Low Resolution mode helps as well, but not nearly as good as changing the color profile. My guess is that the high res graphics are too much for the 5k display
Apple has stated that OpenGL is deprecated, but that’s not the same as making it unavailable. There are a huge number of apps still using OpenGL. This will change over time as more people migrate to Metal, but whilst OpenGL is still available there’s no reason not to use it.
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.
Thanks for this…This will be good, if I get any customers having the same issues. We have used that sRGB profile, along with the Thunderbolt Display Profile, and other profiles that work. I will admit that the colors are slightly different in the Red’s and I do like the iMac Pro Profile color space better, but it is what it is…
Thanks for this. It lets me know I’m not crazy for experiencing this on my iMac Pro.
I’m wondering if there is a way to disable 10-bit color profile to be used in our Juce app to prevent this? It’s kinda bad customer support to tell the user that the issue is that they have an advanced Mac with 10-bit color and to “downgrade” to get it to work better…
Could you explain in more detail what you refer to by ‘engines’ in this context? I have noticed UIs rendering in slightly colours in different hosts (I am using OpenGL), so perhaps this is what you’re referring to, but maybe not. Thanks.
This is not my experience.
If I build an OpenGL app in XCode 9 and those SDKs I get good performance and smooth rendering.
Since they deprecated OpenGL and released XCode 10 my app uses an entire core for graphics and looks sluggish.
Ideally we will be out of the woods entirely before the axe falls, and I hope Juce will help us achieve that. Since the time between realising Apple is going to forcefully revoke a technology could at worst be the time between a WWDC beta 1 and the following October’s GM, we will not be wanting to wait until the last gasps of OpenGL’s availability to start our transitions.
And ios even now is requiring a certain SDK in order to get approved. We’ve gotten rejected for using lower versions, so it seems it has already begun.
I just spent some time tracing this performance issue down. It looks like in Release build there are some GPU debugging tools still enabled that slow down my app a lot. Disabling these seems to bring me back to good performance. Edit Schemes -> Run -> Options -> GPU Frame Capture
Not sure it’s related to your issue but it improved my OpenGL rendering.
This is likely coming down the road with notarisation too for macOS. Temporarily the requirement to build with the latest macOS SDK is lifted until Jan 2020. After that, one assumes we cannot build using ‘older SDKs’, whatever this means in reality, but probably it is the end of the line for XCode 9 and SDK 10.13 if we wish to continue to notarise plug-ins next year. Apple is clearly keen to light a fire under anybody deliberately holding on to technologies they wish to move on from, so we must act accordingly by more proactively moving towards the replacements.
