@Dave S, both about the same:
early 2015: i7-5557U dual core 3.1 GHz, 16GB RAM, 1TB SSD, Intel Iris Graphics 6100 1536 MB, Retina yes
2018: i7-8559U quad core 2.7 GHz, 16GB RAM, 512GB SSD, Intel Iris Plus Graphics 655 1536 MB, Retina yes
both running under 10.14.2
both running the same version of Xojo?
same version 2018R4, same behavior with compiled code.
Argh !
I recall clearly the two images but forget the text. Sorry folks.
It appears to me that you’re double buffering an already double buffered interface (which may or may not actually be triple buffered). For best performance you should be drawing directly to the canvas.
I see in the next code snippet, you’re recreating images, don’t do that unless you absolutely need to. Each time you create a new image, it has to allocate memory for it, populate it and so on. Re-use the images as much as possible. The OS will automatically cache images for drawing a second time, so if you can re-use the same image (without modification to the image) the drawing will be faster.
You’d have to ask Tim Cook. Earlier this year I bought a 2017 15" MacBook Pro with TouchBar, I knew this machine should be faster than my 8 year 15" MBP, but it didn’t feel that way. Sure Geekbench showed it being faster, but in reality it just didn’t ‘feel’ faster (I know that’s subjective), it was just one of the many reasons as to why I returned it after 4 days.
Xojo’s graphics performance is really close to what you’d get with Obj-C or Swift, IMHO it comes down to a couple of things.
The screenshots show the instruments inside of groupboxes, I vaguely remember something (but can’t find it now) about there’s some bugs with them on Mojave. Try removing them.
You could also try using a different canvas for each key of the instrument, although invalidate should only signal to the macOS that a section of the canvas needs recopying to the graphics card.
Interesting software. Everything is fine on my 5k Retina iMac.
I think that Sam’s guess is correct. Try to simplify your drawing. Or something is wonky with your MBP.
In general: a manual would help or at least some instructions. The software looks rather Windows-ish. The music is really nice.
I haven’t seen the app itself
The instrument image is static, but you want transparent rectangles to appear over parts of it?
Try this:
Create the instrument image, and make it the backdrop of a canvas.
In the PAINT event of a canvas, try this:
// here I create 2D shapes every time.
//It may be faster to keep them alive as static or global and just change their size and position
dim arrKeys(9) as rectshape
for i as integer = 0 to 4
arrKeys(i) = new RectShape
arrKeys(i).Width = gKey(i).Width
arrKeys(i).Height = gKey(i).Height
arrKeys(i).FillColor = RGB(255,0,0) //red
arrKeys(i).Fill = 50 // transparent
//object2ds draw based on the CENTRE, so offset by half the width and height
//im not sure about exactly *where* you want to place them
g.DrawObject (arrKeys(i), gRect(i,0) - gKey(i).width/2, gRect(i,1) - gKey(i).Height/2 )
next
Sam: [quote]This year I bought a 2017 15" MacBook Pro with TouchBar, I knew this machine should be faster than my 8 year 15" MBP, but it didn’t feel that way. Sure Geekbench showed it being faster, but in reality it just didn’t ‘feel’ faster (I know that’s subjective), it was just one of the many reasons as to why I returned it after 4 days.[/quote]
I just had the exact same experience. The other main reason I sent it back was I couldn’t use any peripherals with it… 4 USB-C ports are fine if the rest of the world uses USB-C, but having to buy an adaptor to make any standard device work… that’s crazy.
Overnight I lost access to my printer, external HD, CD drive, camera…
@Sam Rowlands, thanks for looking at it!
You’re right, the way to do it are remains of having it running on windows without flicker. But as I’ve re-done the whole in .net C# long ago, there’s no need anymore to do the double buffering myself.
The recreating of the images only happens on window size changes, else they’re used from the existing array, but drawing the keys direct to the canvas (actually just needed to move 2 lines of code to the paint-event), cuts the needed time to a third, average 0.73 ms on the MBP2015, 2.08 ms on the MBP2018, so fast enough now but still around 3x slower!
There’s another finding, the xojo timer seems sensitive to the new true tone sensors. When I cover the camera or move my hand close to it, the timer stops for a moment and then continues, but only if it is the foreground application. If it’s not the active application, it just keeps running. Any idea what this could caused by?
@Beatrix Willius, thanks for the feedback!
I know, some documentation would help, but as the target user is quite specific, she/he’ll know how to use it. It’s mainly built as a “sparring partner” for practicing those special balinese instruments. As no set of instruments is tuned the same, it’s important that the keys can be tuned individually. Originally the codebase was written with GFA-basic on Atari in the 90s and I kept it running with emulators for years before I did it with Xojo (Realbasic).
Moving the drawing direct to the canvas has solved the speed issue for the MBP2018, but there’s still this factor 3 slowness of the new computer, and this weird reacting to movements in front of the camera.
btw, the app is also available as “Gamelan Gender (lite)” for iOS and android, some more (still not enough) instructions there under “Info”
@Jeff Tullin , thanks for looking at it!
That’s about what I’m doing now, except not creating the images in the paint event but drawing them direct to the canvas instead of drawing to picture first. It does speed up remarkley, but there’s still this 3x difference MBP2015 --> MBP2018…
Just found the culprit for the strange stops on moving in front of the camera. If I set the control strip/touch bar to show just the function keys the issue is gone. Not sure if this is a bug in the Xojo-framework though…
Considering the Xojo framework sits atop the various Apple frameworks, I would be inclined to think that this is an Apple issue, where it’s probably (although I have no evidence) polling the application demanding it update it’s touchbar elements, that it doesn’t have. The Touchbar is buggy and has caused many issues for developers.
Glad to hear it helped, that 3x slowdown really does sound like an issue with the machine to me. If your previous MacBook was non-retina, it would make sense, but earlier on you stated it was retina, and with older hardware it shouldn’t be faster. My guess is either a bad driver or that integrated graphics chip on the 2018 is really designed to either fit in a smaller chassis or to use as less power as before (so Apple can claim 10 hours on a physically smaller battery).
I would look into finding something that can benchmark the GPU.
[quote=419035:@Jeff Tullin]I just had the exact same experience. The other main reason I sent it back was I couldn’t use any peripherals with it… 4 USB-C ports are fine if the rest of the world uses USB-C, but having to buy an adaptor to make any standard device work… that’s crazy.
Overnight I lost access to my printer, external HD, CD drive, camera…[/quote]
I had ordered a bunch of adapters to go with the machine, I would have appreciated it it still included at least one USB-A and a SD Card slot (all 4 of my cameras use SD cards). Ultimately it came down to the fact that it wasn’t a machine I wanted to own, it’s performance was underwhelming for a 5 year newer model, the keyboard is unreliable (every key still works on my 2012, but my 2015 is now getting ready for it’s 3rd keyboard), the ports were inconvenient, the TouchBar is a joke, the battery life is a huge disappointment (it got the same battery life as my 2012, which needs a new battery), and at that time, it still didn’t have enough RAM. Apple increased the price and at the same time obliterated the value of the machine, I just didn’t feel it was worth $4,000. So I’m sticking with my 2012 until either it completely dies, or Apple actually wise-up and make a MacBook Pro.
I suspect something similar but couldn’t find another application behaving the same, so I thought it might be something Xojo specific, needing maybe a key, telling the OS that the application doesn’t use touchbar elements?
I did some tests, all saying that it performs faster. But that’s maybe just for 3d and metal rendering, not this trivial 2d rectangle drawing;-)
Just some additions: after I’ve optimised my code, now drawing RectShapes (thanks to Jeff Tullin) and removing the unnecessary clearrect, as it is enough just to not draw, the issue with touchbar polling has vanished. My code might have been to heavy on the UI-thread, so the polling didn’t get it’s answer on time.