MacBookPro 13" 2018 retina enabled, timing lag

  1. 4 weeks ago

    My gamelan emulation app Midi Gender shows terrible timing lags if retina is on. Compiled with 2018r4 it gets a bit better, but is still far from good. On my MacBookPro 13" early 2015 I can't see this behaviour, anything that can be done? Setting resolution to low can't be the solution..

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

  2. Beatrix W

    Dec 22 Pre-Release Testers Europe (Germany)

    Show us some code how you do Retina drawing.

    Otherwise, install the Instruments part of XCode and have some fun with the Time Profiler.

  3. Sascha S

    Dec 22 Pre-Release Testers, Xojo Pro Germany

    Maybe better put the code in a Thread to make it more independent from the UI Thread and work with the Priority.

  4. Hi Beatrix, thanks for replying.
    It is a custom control with a photo of the real instrument with bronze keys in background. When a keys are active, I draw corresponding rectangles with transparency to a Picture and in the Paint-event the complete picture gets drawn to the control and the Paint-event is triggered by me.Invalidate(theRect, false)

    Draw Gender ()

    for i = 0 to 9
    
    if gKeyChanged(i) then
    if gKeyActive(i) then
    pGender.Graphics.DrawPicture gKey(i), gRect(i,0), gRect(i,1)
    else
    pGender.Graphics.ClearRect(gRect(i,0) - 2, gRect(i,1) - 2, gRect(i,2) + 3, gRect(i,3) + 3)
    end if
    me.Invalidate(gRect(i,0), gRect(i,1), gRect(i,2)+4, gRect(i,3)+4, false)
    end if
    
    next

    Paint ()

    g.Transparency = 60
    g.DrawPicture pGender, 0,0

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

  5. Hi Sascha, I've done a lot of versions with threads, custom timers a.s.o. None was really successful. And it does not really help to have the playing without timing issues, but have the graphical indication of the playing not on time, as this is a important part of the app. Maybe Xojo is not really the language to do realtime code and I'll have to port it to obj C or Swift....

  6. Addition to the code. The key pictures are drawn like this:

    for i = 0 to 4
    gKey(i) = New Picture(gRect(i, 2), gRect(i, 3))
    gKey(i+5) = New Picture(gRect(i + 5, 2), gRect(i + 5, 3))
    gKey(i).Graphics.ForeColor = &cb0b0b0
    gKey(i).Graphics.FillRect(0,0,gKey(i).Width,gKey(i).Height)
    gKey(i+5).Graphics.ForeColor = &cb0b0b0
    gKey(i+5).Graphics.FillRect(0,0,gKey(i+5).Width,gKey(i+5).Height)
    
    gKeyChanged(i) = true
    gKeyChanged(i+5) = true
    next
  7. As to see in attached profiler screenshots, the new MBP needs more than 3 x longer to render the gender control:

    -image-

    -image-

  8. Dave S

    Dec 22 San Diego, California USA

    in your DrawGender routine what is "ME"? Incomplete code makes it difficult to understand you problem.
    But depending on what ME is... that INVALIDATE may be causing recursive loops that waste time.

    Based on another topic here recently. it seemed that HighSierra was forgiving about somethings, and when Mojave tightened things up, Xojo code that had previously worked now crashed... but it was becuase the code was using Invalidate in improper places.

  9. Hi Dave, thanks for looking at. ME is the custom control, it's Super is Canvas, so just triggers the paint event. As already stated, both of my MBPs run under 10.14.2, there was no change in performance on my older device, I can see it only on my new one. And as you can see from my screenshots, it effectively takes 3 times as long for the paints.

  10. Sorry for confusion, had marked the screenshots wrong, fixed now...

  11. Beatrix W

    Dec 22 Pre-Release Testers Europe (Germany)

    It's really hard to say where the problem might come from. The code doesn't really scream "I'm slow". How large are the images that you show? How many canvases do you have? What is causing your code to be called 1731 times? Could it be that you have refreshes in your code that cause repainting? Have you tried to make a more simple version of your window?

  12. Dave S

    Dec 22 San Diego, California USA

    remember that a retina version of an image is in fact 4x larger than its non-retina counterpart

  13. Emile S

    Dec 22 Europe (France, Strasbourg)

    Did you try Profiling your code ?

  14. @Beatrix W, it's a music app, and 1731 times represent note on/off events needing highlight/unhighlight the keys, I don't think there are any more than needed;-)
    But my question is: why is it so much slower on the new MBP?

  15. Dave S

    Dec 22 San Diego, California USA

    @Emile S Did you try Profiling your code ?

    Emile... look at his posts towards the top

  16. @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?

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

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

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

  20. Newer ›

or Sign Up to reply!