Some Xojo apps are much slower on Sierra

[Richard_Nicolella]

I’ve been dealing with a huge performance hit on my spreadsheet-like apps on Sierra. Scrolling that is fluid and snappy under ElCap and Yosemite is now ponderous and almost unusable on Sierra.

I made a test app to demonstrate that indeed graphics functions can run as much as 3x slower on Sierra. My customers who upgraded to Sierra are now irate, and I am having no luck correcting the issue.

Is anyone else experiencing this?

I have added a feedback case with a sample app - case 46020. I boot the same MacBook Pro in Sierra and ElCap and the difference is striking.

Here’s a sample of my results:

ELCAP -> SIERRA
StringWidth: 96 -> 301 = 3.1x !!!
DrawString: 273 -> 555 = 2x
DrawLine: 44 -> 60 = 1.36x
DrawPicture: 40 -> 56 = 1.4x
FillRect: 27 -> 35 = 1.3x
MidStr: 4 -> 5 = 1.25x

Please have a look and if you have any suggestions, I’d love to hear them!

[Michel_Bujardet]

You forgot to join the file blue.png to your report.

[Richard_Nicolella]

Oops, sure did. Added blue.png to the to the fb report now. Thanks.

[Michel_Bujardet]

BTW I did verify your data. It is even worse in the window paint event …

[ChristopheDV]

I reported this from the start when Sierra was released as a beta. No-one believed me.
It is a 100% fact: Xojo apps that use extensive drawing in a Canvas is much slower in Sierra for sure. Unfortunately there is nothing you can do about.
If some Xojo dev would actually look at this in more detail, it may be optimised after all.

My guess it has something to do with the new Metal APIs. Not sure though.

[Roger_Clary]

Not to suggest that Xojo apps could not be optimized to run more efficiently, but my subjective experience is that every app on my computer is slower under Sierra than El Capitan.

[Richard_Nicolella]

Wow, Michel, you are right. It’s MUCH worse in the canvas paint event.

I moved the code from my test app to a canvas paint event and while the numbers are marginally higher there in ElCap they are off the chart in Sierra. This is actually a show stopper for me. When a canvas drawing operation takes up to NINE times as long on Sierra, simple optimization won’t do!

I don’t know whether this is for Xojo or Apple to fix, but I hope this can be resolved soon.

My results in the canvas paint event:
ELCAP -> SIERRA
StringWidth: 118 -> 280 = 2.3X
DrawString: 290 -> 1049 = 3.6X !
DrawLine: 46 -> 283 = 6.2X !!
DrawPicture: 56 -> 292 = 5.2X !!
FilllRect: 27 -> 238 = 8.8X !!!

[Travis_Hill]

It seems that Apple is indeed working on some of the performance regressions in Sierra. We’ll see what that means as the next Sierra point releases come out.

[Sam_Rowlands]

Some thoughts on this:

1. Confirm in 64-Bit; 32-Bit is unofficially deprecated.

2. Layer-Backed Views are flaky as shit; but it seems to be the way Apple are moving forwards. In my experience these really do slow down canvas based controls. You can opt-out if Layer-Backed Views with a declare.

Add the following to a module:

Sub wantsLayer(extends c as rectControl, assigns value as boolean) #if TargetMacOS and TargetCocoa then declare sub doThing lib "Cocoa" selector "setWantsLayer:" ( NSViewID as integer, value as boolean ) doThing( c.handle, value ) #endif End Sub

Then add the following to the open event of a control:

me.wantsLayer = false

3. I don’t have the time right now; but could someone replace the Xojo functions with native CG and see if it makes a difference.

4. Make sure that your code is as tightly optimised as possible; this is a rule that I preach, but I’m not really able to do myself. Move and cache as much logic as possible, your drawing routine should only be drawing. My OpenGL apps are coded this way.

5. If you’re only updating part of a canvas, use invalidate like below.

canvas.invalidate( left, top, width, height, false)

This alone has helped some of my apps go from being jerky to smooth.

6. Make sure that your scale is being correctly returned, I had a weird bug in El Cap two weeks ago where it was returning a scale factor of 2.0 on a 1.0 screen, which I presume was the OS thinking that screen was a high resolution when it wasn’t. Restarting fixed it.

7. Check your console; my Sierra machine is a pig; but I found that there’s the code for the Touchbar trying to connect to the Touchbar every few second, on a machine that doesn’t have a Touchbar. I need to manually disable that POS.

8. Report this to Apple via Bug Reporter and include a sample application.

9. Are you testing on a 2014, 2015 Retina iMac or 2016 tbMBP? These support wider color gamut, and Sierra includes changes to the graphics subsystem for these machines.

[Jeff_Tullin]

Not wanting to hijack the thread, but having looked in the console
a/what would touchbar messages look like?
b/Any idea why I have loads of messages about Sophos Anti Virus when I dont have it installed? (nsurlsessionid DbOpen of /Library/Sophos Anti-Virus/Sophos.keychain)

[Sam_Rowlands]

Sorry; the message I am getting is:

com.apple.xpc.launchd[1] (com.apple.nowplayingtouchui): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

[ChristopheDV]

@300649:@Travis Hill

It seems that Apple is indeed working on some of the performance regressions in Sierra. We’ll see what that means as the next Sierra point releases come out.

With latest macOS beta it’s still very slow.
Maybe Xojo should take a look at the new Metal API?

[ChristopheDV]

[quote=300674:@Sam Rowlands]2) Layer-Backed Views are flaky as shit; but it seems to be the way Apple are moving forwards. In my experience these really do slow down canvas based controls. You can opt-out if Layer-Backed Views with a declare.

Add the following to a module:

Sub wantsLayer(extends c as rectControl, assigns value as boolean) #if TargetMacOS and TargetCocoa then declare sub doThing lib "Cocoa" selector "setWantsLayer:" ( NSViewID as integer, value as boolean ) doThing( c.handle, value ) #endif End Sub

Then add the following to the open event of a control:

me.wantsLayer = false

Tried this but it does not have any impact on speed (on my new MBP with touchbar)

[Sam_Rowlands]

@300649:@Travis Hill

It seems that Apple is indeed working on some of the performance regressions in Sierra. We’ll see what that means as the next Sierra point releases come out.

IMHO this is just one of the problems that Apple face with yearly releases; not enough time to debug any changes they make. Plus they only give us developers two months to test our apps and report issues.

I’ve not noticed a serious slowdown on Sierra, because I’m running it on a 2015 MacBook (which is slow to begin with)… Lol… Apart from that stupid POS TouchBar UI thing constantly failing.

[ChristopheDV]

@300697:@Sam Rowlands

2015 MacBook

It also is slower on my new MBP.

[Ulrich_Bogun]

@300601:@Sam Rowlands

3) I don’t have the time right now; but could someone replace the Xojo functions with native CG and see if it makes a difference.

I did create a small test project using AppleLib, with a Xojo canvas and an NSView, taking care that the NSView has no layer, but no:
It’s not Xojo, it’s Sierra. Both are almost up to the same speed, with the native control being a very tiny bit faster. Xojo’s graphics methods are really fast – I am almost sure you can blame Apple for the performance breakdown:

[quote]Xojo Canvas DrawOval:
257407714
NSView StrokeEllipse:
248868896[/quote]

@300674:@Sam Rowlands

7) Check your console; my Sierra machine is a pig; but I found that there’s the code for the Touchbar trying to connect to the Touchbar every few second, on a machine that doesn’t have a Touchbar. I need to manually disable that POS.

You mean launchd restarting nowplayingtouchUI? How do you disable that? I even reinstalled my iMac recently because I had a lot of these things going on, and now – I don’t know what might be triggering this –, sometimes it falls back into this behavior again.

[Michel_Bujardet]

Graphics are not the only snail. I updated last night to a new version of 10.12.2 (16C32e) and this morning, it took about an hour for my iMac to become fully operational after showing the dock, but nothing else.

[Ulrich_Bogun]

Wow! I experience different kind of fun with Sierra: Sometimes when I cut Xojo code into the clipboard and want to insert it in a different place, it inserts whatever I copied into the clipboard before that! I used to have a clipboard manager installed. Guess I should reinstall it – did never have that before.
Sierra.
Best. Update. Ever.
Does anyone really use Siri on his Mac?

[Michel_Bujardet]

@300733:@Ulrich Bogun

Does anyone really use Siri on his Mac?

Did you say ? What ? Is it this sort of Cortana I don’t use either with Windows 10 ? I do talk to my computers, but just to swear at them, and I don’t want them to talk back

[Richard_Nicolella]

Wow. Here’s another fly in the ointment. I was making a demo app for an Apple bug report, and when I set Retina mode in AppWrapper, the performance of DrawPicture suddenly took a huge hit on BOTH ElCap and Sierra. I tried it with both 32 and 64 bit. Same. Tried with Sam’s wantslayer code. Same.

So the bad news is that Retina imposes a huge hit on DrawPicture performance. Up to 70X on 32bit ElCap.
The good news is that Retina apps take less of a hit on Sierra than ElCap. Only 26X on 64bit Sierra - if that can be considered good!

Maybe this is just expected Retina overhead. Not sure. And I don’t think this particular issue is what’s killing my grid controls, since I don’t use many pictures. But the difference is just amazing to me, and another thing to consider when making Retina apps.

Here’s my results:

64bit NonRetina -> Retina
El Cap 60 -> 2847 = 47X
Sierra 120 -> 3140 = 26X

32bit NonRetina -> Retina
ElCap 55 -> 3815 = 70X
Sierra 314 -> 4497 = 14X