MacBookPro 13" 2018 retina enabled, timing lag

  1. ‹ Older
  2. 4 months ago

    Dave S

    Dec 22 San Diego, California USA

    @Emile S Did you try Profiling your code ?

    Emile... look at his posts towards the top

  3. @Dave S, it's no images, just rectangles with transparency, and yes they're 4x as big when retina enabled, but why is it handled fine on my 2015 MBP?

  4. The image size depends on app scaling, smallest is 310 x 155 but can easily scaled up to 620 x 310 and it's two instruments, so this twice:
    My app is here: https://itunes.apple.com/app/midi-gender/id892243181?mt=12
    use the promo codes below:
    XLLTWYYW4JW9
    H7LPPNAW94T3
    WPNLK647RMWJ
    MW7FJ3646ELF
    6RPYE3J34JPP

  5. Beatrix W

    Dec 22 Pre-Release Testers Europe (Germany)

    I did the last code and will have a look at your app tomorrow. I have 2 computers one with Retina and one without.

  6. Dave S

    Dec 22 San Diego, California USA

    @Otmar K but why is it handled fine on my 2015 MBP?

    detail the differences between the two machines?

    CPU?
    RAM?
    Retina?
    macOS?
    HDD vs SSD?
    Graphics GPU/Ram?

  7. @Beatrix W, thanks! Just for the record, it's running under retina fine since years, it's just the new MBP that should actually be much faster has troubles. Best to test the performance, load the song "Sekar Sungsang Sukawati". The Sukawati-Style has more polyphony, so more keys to render.

  8. @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

  9. Dave S

    Dec 22 San Diego, California USA

    both running the same version of Xojo?

  10. Edited 4 months ago

    same version 2018R4, same behavior with compiled code.

  11. Emile S

    Dec 22 Europe (France, Strasbourg)

    @Dave S look at his posts towards the top

    Argh !

    I recall clearly the two images… but forget the text. Sorry folks.

  12. Sam R

    Dec 22 Pre-Release Testers, Xojo Pro Answer Hengchun, Pingtung, Taiwan

    @Otmar K I've done a lot of optimisations when retina came mandatory, and as I've stated, it's working fine on my older MBP, just the new more powerful MBP 2018 seem not to like the picture drawing...

    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.

    @Otmar K But my question is: why is it so much slower on the new MBP?

    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.

    @Otmar K Maybe Xojo is not really the language to do realtime code and I'll have to port it to obj C or Swift....

    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.

    1. Have you tried other graphics apps on the new MBP, maybe it's faulty or it really is just a gimped machine designed for web browsing?
    2. The implementation probably has something to do with it.

    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.

  13. Beatrix W

    Dec 22 Pre-Release Testers Europe (Germany)

    Interesting software. Everything is fine on my 5k Retina iMac.

    • The canvases are small. So canvas size can't be the problem.
    • The painting in the canvases just masks them a bit. So no complicated calculations either.

    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.

  14. Jeff T

    Dec 22 Pre-Release Testers Midlands of England, Europe
    Edited 4 months ago

    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:

    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.

    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...

  15. @Sam R, 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?

  16. @Beatrix W, 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"

  17. @Jeff T , 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....

  18. Edited 4 months ago

    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..

  19. Sam R

    Dec 23 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    @Otmar K 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.

    @Otmar K 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.

    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.

    @Jeff T 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...

    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.

  20. @Sam R 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.

    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 would look into finding something that can benchmark the GPU.

    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;-)

  21. 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.

or Sign Up to reply!