Exceedingly slow UI on powerPC with new Juce

#1

I have an “interesting” problem. On my recent switch to Juce 1.38 (from 1.21), strange behavior has crept in:

On slower PowerPCs the entire UI is much slower. The most obvious symptom is moving of the main window, which is a pain. Before the Juce upgrade, this was not a problem. The PPC in question is a dual 600 MHz or somewhere in the vicinity.
When right-clicking on the program icon in the dock, other strange symptoms appear (name and icon removed…):

These were not there in the earlier version of Juce. They are not very annoying, but might hint at the proplem with performance.

I saw the recent thread about bitmap drawing, and it has helped ever-so-slightly…

Thanks in advance!

-A

#2

The main difference in the new version is that it uses HIViews now instead of just drawing directly to a window with quickdraw. Could be that that’s just not as efficient on an old PPC, but it’s the direction that apple are pushing everything these days, so you’ve got to move with the times…

Window names are set in the same old way, though, so can’t think why that’d be different. It’s the setTitle() method in juce_mac_Windowing.cpp if you want to experiment with it.

#3

Ah yes… Apple has been responsible for a lot of grief with their upgrades and stuff. Nothing to do about that then.

About the four blank thingies - I forgot to mention, that they are not supposed to have any text. The bug is that they are actually there. There is only one window in my program, and there should be only one. Where the four entries come from I don’t know. Old Juce had only the one.

-Thanks for replying :slight_smile:

-A

#4

Hmm - that’s puzzling about the four blanks. They don’t appear on my machine when you run the demo. Have you got some windows hanging around that aren’t visible?

#5

I have no invisible windows. I put a breakpoint in the window class constructor, and it is only executed once. Right now, this issue is not important though, compared to the performance - I was wondering… Is it possible to use the old way of drawing stuff by means of some compiler/preprocessor definition? I guess the changes are so extensible, that an actual code-change is somewhat impossible - but is Juce “backwards compatible”? I think I know the answer, but I am clinging to every last straw here…

-A

#6

I ditched the old quickdraw code because of all the compiler warnings it threw out, and I think it’s actually slower on new machines anyway.

I guess it’s not impossible to stick the v1.21 code back in there for builds that target OSX10.2, but I’ve not time right now to try it. Probably the only change would need to be in the bit that blits the rendered image to the window.

#7

That would be absolutely amazingly cool. There is only one thing in your post that doesn’t thrill me unconditionally: “for builds that target OSX10.2”. The powerPCs I have problems with build for and run 10.4.x. Would your fix also cover this case?

-A

#8

The way I set it up was for the Universal binary to be 10.2 compatible for all PPC code, and 10.4 compatible for Intel code, so it’d work fine in your case.

#9

Thanks Jules. I might not be the only one in need: I’ve done some investigating, and on a 533 MHz PowerPC, my application window moves much smoother around than even the minimal “Hello World!” Juce example application.

-Andreas

#10

Thanks Jules. I might not be the only one in need: I’ve done some investigating, and on a 533 MHz PowerPC, my application (with Juce 1.21) window moves much smoother around than even the minimal “Hello World!” Juce example application (with Juce 1.38 ).

-Andreas

#11

Okay… So. Time to brush up on this problem a little. I found a comment in the Juce 1.21 code that goes: “tragically this version of QuickDraw implementation seems to be massively faster that the CoreGraphics version, […] keep an eye on performance in future…” (in juce_mac_Windowing: paintWindowRectangle). That tells me, that there is some time to win, fairly easily…?

Anywho: “Probably the only change would need to be in the bit that blits the rendered image to the window” - is this what happens in paintWindowRectangle in the old Juce?

-A

#12

I’d tentatively say it might be fairly easy, though there could be important factor that I’ve forgotten…

#13

Okay then… I’ll try with the first suggestion: “the bit that blits the rendered image to the window”

->Where is this bit in the Juce 1.21 code (is it the paintWindowRectangle()?)

->Where is this bit in the Juce 1.38 code (is it the MacBitmapImage::blitToContext(…)?)

-That should formulate the question concretely :slight_smile:

-Andreas

#14

Yes, those are the bits.

#15

Here is a related topic that has a possible solution:
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=1102

#16

Thanks Dan - I already tried this though, without much luck. I think it helped a little, but still nowhere near enough. My own huge program is still running way smoother with old Juce, than the minimal “Hello world” eample juce program with new Juce… :o

-A

#17

I have now done some initial snooping into exchanging blitting code - and it does not look trivial. I have done some profiling too though, and I found something interesting.

Profiling on a 1.33 GHz G4:
In a top-down analysis og the program with Juce 1.21. As far as I can tell, the actual time spent repainting stuff is approx. 25.3% of the total execution time (by calls to paintWindowRectangle). Of course I had hoped to find that Juce 1.38 spends a lot more time repainting… When using Juce 1.38 I can’t find the blitToContext call in the profile at all, which suggests that the actual blit is not really the problem. Rather, from the structure, size, and number of callstacks, it appears that it’s the entire HI-thingy system that is bulkier in terms of calls. In other words, there are no real culprits - no certain functions that seem to take up excess of time. Could it be that it’s “just” the entire messaging system and/or call-hierarchy that is a heavy dance-partner…? That would be a serious problem, if one needs “realtime” graphics of some sort.

-A

#18

I can certainly believe that HIViews are slower than just the bare windows. There’s actually only one HIView in the window, though, so you wouldn’t expect it to add too much overhead. It could just be that they use an entirely different layer to handle repainting of windows with HIViews, and it’s that layer that’s much slower on a PPC for some reason.

#19

That sounds plausible - speaking from both the usage and profiling point of view. For me, it’s bad news. In summary it means that I cannot use newer Juce versions and support older PPC computers at the same time, which is awfull, to say the least.

Oh well, thanks for your input Jules. I’ll be sure to post any possible solutions to this pickle, if I find any.

-A

#20

Just a thought - are you sure it’s actually using more CPU, or could it just be that the timing of its repaints is different? One thing that changed is that I used to use my own RepaintManager class to collect all the dirty regions and trigger a repaint callback, but now I leave that up to the HIView, so maybe that’s just not choosing not to refresh as often as you’d like?