Site navigation

UI Performance

General JUCE discussion
#1

1) Is OpenGL be more performant than Core? (iOS)

2) I used the XCode performance feature to draw in yellow when part of the screen is being redrawn. It keeps highlighting the whole screen, but I don't have any code that refreshes the whole screen (iOS on actual IPad). Is there some way to figure out where this might be happening? Or, is this somehow expected?

I'm asking as my code is using 36% of the IPad CPU, which although not horrible, seems like it's using much more than it should. Is there any performance tips partcularly around drawing? Should I be drawing offscreen bitmaps and blitting them? etc.?

J

1 Like
#2

I found that everything was re-rendering more often as the base component had setOpaque(true), that was causing the background redraw to redraw all the child components. 

I tried also allowing juce to use bitmaps to redraw stuff, but that didn't seem to have a noticable effect. I think for it to work, I'll have to manage those offscreen bitmaps myself, as repaint() causes it to dump the bitmap cache.

#3

I don't recommend using bitmaps unless you really understand what you're doing - it can have the opposite effect to speeding things up. Have you tried using JUCE_ENABLE_REPAINT_DEBUGGING? And remember that you should never, ever start optimising until you've used a profiler to actually measure what's really going on.

#4

I did enable that flag previously, and it seems to claim that the whole screen is rarely updated (which is good, of course). However, it didn't seem to agree with what the XCode profiler was saying. I need to repeat that experiment.

Switching to bitmaps seems to have helped a lot on OSX anyway. I'm not very good with the XCode profiler yet, as I just started, but running Activity Monitor is spiking at 7% cpu usage, and ~2% when "idling". This was spiking to 35+% before bitmaps. I'm not worried about OSX, but hoping the changes have similar effects on iOS. The drawing included alpha/gradients, which I'm guessing was the expensive part.

I'm attaching a log from Instruments (profiler) in XCode. What I find odd is that it looks like I have a deep nesting of components. I have a "main screen" with one component with many buttons (about 30). Screenshot attached. It looks like this nesting of calls is using most of the CPU. At this point, I don't think I need to squeeze much more out (depending on iOS), but this seems "curious" to me. 

#5

Yeah, that doesn't tell you too much about what's really burning CPU - just having a deep stack isn't inherently bad. If you do have really complex component arrangements, one trick is to use setPaintingIsUnclipped to avoid the overhead of clipping each component when they get painted, but the usual advice applies: be careful not to waste your time optimising the wrong thing.

#6

The numbers seem to indicate that CPU is getting eaten up before you reach the paint operation.

However, the other way to read it, is its not a lot of cpu time to start with, so maybe there's not much left to optimize (this was over a 12sec or so run). I'll post iOS results if they diverge somehow.

#7

How do I test if OpenGL rendering is being used? I presume its quicker?

If I run the profiling on an IPad, it says "No GL Data", but it gives me numbers for "core animation", and lists data under OpenGL ES Driver, but nothing under OpenGL ES Analyzer.

#8

It's only used if you actually enable it. See ComponentPeer::setCurrentRenderingEngine

#9

Should it be more efficient?

#10

Some things are much faster, others not. Like with all optimisation, the only correct answer is "measure it and see"!