Graphics seem slower in 5.2 (OS X)


#1

I noticed that after the switch to JUCE 5.2 from JUCE 4.2 - performance seemed a bit “sluggish”.

Did a lot of profiling and testing and JUCE 5 is actually performing better in many graphics areas than JUCE 4, but in some cases it does much, much worse.

It is hard to figure out where is this coming from, but one big hint is when drawing ARGB images.

I tested this with the official Juce Demo app and found out that 5.2 is almost 50% slower than v4.2

To do this test - simply open Juce Demo built with 5.2 and with v4.x, then go to Graphics: 2D Rendering and on the right hand side select Images: ARGB in both apps. Here is how my Activity monitor reports the CPU usage for both apps

Activity moniitor

Looking at v5.2 window - I can see the following

2

… while 4.2 looks like this

2

This is a HUGE difference and obviously v5.2 is struggling to keep up.

Does anyone have any explanation or possible workaround for this?
Should we expect that someone will look into this quickly?
This has a fairly big performance impact on any app built with 5.2.

This was tested on OS X 10.12 btw…


#2

Just to rule out the obvious, you compiled them both in release mode, did you?


#3

The app that I first noticed the issue with - yes. the demos - no - they were both compiled in debug mode, but this difference in performance is too big to be impacted significantly by compilation options.


#4

Not necessarily, if there were a lot of asserts added, e.g.
I would suggest to try with release again and report back…
But if it remains, sure it is something worth checking…


#5

There are many threads in the forum where I rant about people using Activity Monitor or Task Manager as the way to “measure” what’s going on for this kind of thing. Those apps tell you nothing useful about what’s actually happening in the code. PLEASE when investigating this stuff, learn to use Xcode’s excellent suite of performance measurement tools to see exactly which functions are taking the time. It’s really not difficult, and means that you’ll make a much better-informed report to us.

In this case, on OSX, all the image drawing has always been done by CoreGraphics, and AFAIK nothing has changed. Are you sure both apps are running in CoreGraphics mode, and not openGL? And are they showing the same image? It’s very very easy with graphics benchmarks to get vastly different results from only slightly different setups.


#6

also on that note… I just ran up the current demo, and when you turn off “animate position” and “animate rotation” the rendering time drops from 5ms to 0.2ms. So clearly there’s a huge amount of variation in CoreGraphics behaviour under the hood, where they’re probably optimising for common use-cases at the expense of transformed drawing.


#7

…and just to further illustrate how sensitive this stuff is, if you turn off all the animation so the image doesn’t move and resize the window, you’ll get variations in drawing time between 0.2ms and 6ms, because the sub-pixel offset of the image has an effect on whether CoreGraphics can use its fast path renderer.


#8

This was not reported lightly and without profiling. I think I started my post by saying that I profiled everything carefully. I would not have reported this without profiling, but it is hard to profile two versions of JUCE and give meaningful data. this was reported using Activity monitor because the difference is huge and can be easily seen even in the Juce Demo app data displayed in the top right corner.

In my profiling - the heaviest function calls are to draw an ARBG image with transformations (scaling) and stroking a path.

I cannot yet tell if the drawing itself is slower in JUCE 5 or if the drawing is called 2 or 3 times as often somehow as changes were made to how MessageManager locking is handled.

There was NO changes on our side regarding this drawing functionality except switching to JUCE 5

I would be happy to provide any information needed, but please understand that if users start reporting these issues - it’s not because we are happy about it - it’s because we like JUCE, use it and want to make it better if we can.


#9

Absolutely, and it’s appreciated!

But really the only useful info would be to know exactly which functions are the hotspots.

If, as I suspect, in both cases you’ll find all the time being spent in CGContextDrawImage, then there’s really nothing much we can do to change that, or even to work out why it’s behaving differently…

BTW in doing a quick profile myself I noticed that half the CPU was being spent drawing the checkerboard background, mainly because it was being done in a dumb way - a fix for that will pop up on develop shortly, and maybe it’s the thing that was making the difference


#10

Here is some quick profiling results of Juce Demo app with 4.2 vs 5.2
Now … these are done on two different computers now, but I think it is ver interesting to see how big a difference we are seeing.

Here is JUCE 4.2 showing that the draw image demo is not really that heavy.

Now here is the 5.2 on a newer hardware showing that drawImage demo is really slow and that the arg_32_sample_ARGB32 call to CoreGraphics is taking a long time compared to its 4.2 counterpart.

I understand that these are now two different machines, CoreGraphics is handled differently and so on, but if I can see almost 50% difference one the same machine - something is not right.

I could try to switch my main development machine back to 4.2, make sure the images used are the same and do the test again if needed, but I hope this gives a clue.


#11

Update: After trying many things, including switching the OSX SDK back to 10.11 - I realized that the juke logo image was somehow older in the previous version of my juce4 copy. That image is 128x128 pixels while the new one is 512x512 pixels.
I then modified the project to use the smaller image (same effect if you scale it down with a transform btw) and the performance penalty was negligible.
So the issue in this instance is that the larger image is taking considerably longer to draw.
I still have to try to find out where is the performance penalty really coming from, but this ARGB drawing doesn’t seem to be it.


#12

Yes, I thought it’d be something simple like that!

If you feel like changing the title of this post to something that’s less critical, that’d be nice :slight_smile:


#13

Done. I will continue to “hunt” and see why in some specific cases drawing takes more CPU when built with 5.2 and Mac SDK 10.13. It may be that building with sdk 10.11 will make a difference.
If I find something - I will report back.