Very bad performance for paint() on MacOsx

MacOSX and iOS
1

There seems to be very bad performance on MacOsx for drawing anything.

System: 2017 13" macbook pro with 2.3 GHz Intel Core i5

I set up a simple test to test 25FPS redraw of a black background.

MainContentComponent::MainContentComponent()
{
setSize (1024, 800);
startTimerHz(25);
}

void MainContentComponent::paint (Graphics& g)
{
   
    g.setColour(Colours::black);
    g.fillAll ();

    
}

void MainContentComponent::timerCallback()
{
    repaint();
}

This takes 35->40% of the CPU as shown in the profiler.

This doesnā€™t seem to be the case on windows.

Anyone has any tips, maybe change some flag or something?

2

Try a slightly higher timer frequency. I read somewhere that macOS start throttling UI rendering calls if they go below 30ms.

3

The higher the frequency the higher the cpu goes. At 50, itā€™s at 70%

4

Sorry I meant higher timer interval. Does the problem persist with startTimer(30) or startTimer(40)

5

startTimer(40) is the same as startTimerHz(25)

6

Oops, Iā€˜ve misread your code example, sorry again. But have you actually used a profiler (Instruments) or is it just the activity monitor CPU value?

7

I used a Time Profiler Instruments. The time is all taken in Paint() method.

8

So after much investigation I decided to use OpenGL context

Iā€™ve created an OpenGLContext and in the constructor called:

openGLContext.attachTo (*getTopLevelComponent());

This seemed to improve performance drastically.

1 Like
9

I think youā€™d need to drill-down further than that to get any useful clues.

And if all youā€™re doing is filling the window with solid black, that should be very quick for CoreGraphics to do on a machine that has GPU acceleration. If all the CPU is really spent waiting for the CoreGraphics fillrect function to run then it sounds like somethingā€™s a bit odd with the OSā€™s rendering system.

10

I assume you are measuring a release build?

  • optimisation on
  • removes jassert and other development time safety checks

There is not much point in doing that on a debug build, it will have poor performance (more or less on purpose)

HTH

1 Like
11

Hi there,

It seems really weird to me too, but this apparently happens a lot on different systems in MacOS sierra 10.12.6

Call to CGSFillDRAM64 seem to be very expensive.

This was profiled using:
System: MacBook Pro 2017
Graphics: Intel Iris Plus Graphics 640 1536 M
OS: MacOS sierra 10.12.6

Other systems with the same OS seem to have the same issue with performance.

OpenGL Context fixes the issue.

2 Likes
12

Very odd - that kind of implies that the OS has decided not to use the GPU for rendering your windowā€¦ Havenā€™t ever seen that happen!

Is it an app or a plugin? If a plugin then it could be something weird that the host is doing, I guessā€¦

13

In this test case it is an app, but the issue arose due to an AAX plugin taking a lot of cpu on a 2015 i7 macbook pro with the same version of operating system macos 10.12.6.

14

Could be something quirky about that specific version of OSX, I suppose. Do other apps also seem impaired, or is it singling out your app for this slowdown?

15

ā€œJUCE Demoā€ on logo splash screen with animated sinusoidal wave seems to have very high cpu at 84% when taken to full screen.

16

Hi there,
Sorry to reopen this topic.
I do think this is an issue with specific OSX version, unfortunately MacBooks from 2017 seem to ship with this version of OSX.
Also a lot of users are on this OSX version.

Iā€™m not particularly happy with openGL.
Will changing the minimum OSX change the way the os treats the paint method?

17

TBH thatā€™s probably a bad example, because the rendering isnā€™t trying to run efficiently, it uses very complex 2D paths that are probably very expensive to draw. With graphics, the only really useful benchmark is whatever your real app is trying to do, because even subtly different things have very different performance characteristics.

Well, if the problem is definitely because 10.12 is doing something sub-optimal, if if youā€™re sure that the same thing never happens on 10.13 then sure, you could enforce that as the minimum compatible version.

18

I would not feel good forcing everyone to be on 12.13, many people donā€™t like to upgrade immediately.

Is there a flag to force Hardware Acceleration?

19

A full screen fillAll() takes nearly 100% (1 full core) at 33 frames/sec

Iā€™ve created a test project:
This is it:
http://www.signumaudio.com/Profiles/TestUIPerformance.zip
Trace file here:
http://www.signumaudio.com/Profiles/TimeProfileSimpleFillAll.trace.zip

I prefer not going for the opengl context as lines are not nearly nearly as good, and Iā€™m doing simple vector UI.

20

Sure, I understand, but like I said, we literally just call CGContextFillRect!

Iā€™m not sure what you think we could do that could change the way OSX handles it?