Graphics lag in OSX

[j_iglar]

Does anyone know what would cause a graphics lag in OSX? I'm having students build a flappy bird clone scroller - very simple, with small png files. On Ubuntu, the game runs fine. On OSX (different versions 10.8 and 10.10 for sure), it's very slow with a noticeable lag. Same thing when saved as standalone app. (Haven't checked Windows yet.)

I've looked it up and found some references to the scroller layers http://forums.livecode.com/viewtopic.ph ... 90&p=72004
All control items have layer set to "static" - even if I group them and make that group "scrolling" the performance is still poor.

Any advice will be greatly appreciated.

(We're using version 7)

thanks!
John Iglar

[bn]

Hi John,

welcome to the forum.

There are many factors determining the speed of animation. It is difficult to tell what would cause a slowdown and what to change without knowing anything about the code.

Since you can not yet upload a stack (I think you need 8 or so posts) you might want to describe exactly how the images for animation are loaded, how large they are and sample code of the animation.

Is there more than one animation running at a time?

You could save the stack as a legacy stack in 5.5 format and try to use 6.7.0 version to built the standalone to see if it runs better on Macs. Livecode 7 is not yet up to the speed of 6.7. But is improving.

In LC 7 some techniques are faster than others.

Kind regards
Bernd

[j_iglar]

Thanks very much, Bernd. Much appreciated. I hope to be more active in the forums now that I'm getting a bit beyond basic noob stage with Livecode!

Meanwhile, here's a more detailed description:
I'm having my students build a clone of FlappyBird, using the techniques from Udemy's LiveCode 101 course. It includes 5-6 png files that we're using as button icons. Nothing very heavy. Each one is around 5kb. We've put the graphics in a substack, and then used their ID's to make them the icon for buttons on the mainstack.

The animation Is pretty simple: a button with a png file moves up and down (the bird). Some other buttons with png files scroll past, right to left. Maximum 11 buttons moving at a time. Here's a sample handler (moving 8 of the scrolling images/buttons):

Code: Select all

on columnsMove
   repeat with counter=1 to columnNumber
      put "columnbottom" & counter into tcolumnDown
      put "columntop" & counter into tcolumnUp
      put the right of button tcolumnDown - columnSpeed into tcolumnLocation
      if tcolumnLocation < 0 then ##this means the column moved off screen, so send it to the end
         add columnDistance * columnNumber to tcolumnLocation
         ##paste in the randomize gap code from columnsSetup
         put 200 + random(columnVary) into tcolumnHeight
         set the bottom of button tcolumnUp to tcolumnHeight
         set the top of button tcolumnDown to tcolumnHeight + columnGap
      end if
      ##check to see if the column has passed the bird and then increase the score
      put the left of button "bird" into tbirdLocation
      if tcolumnLocation < tbirdLocation and tcolumnLocation > tbirdLocation-columnSpeed then addScore
      
      set the right of button tcolumnDown to tcolumnLocation
      set the right of button tcolumnUp to tcolumnLocation
   end repeat
end columnsMove

Here's the main looping handler (I tried removing the delay of sending the handler back to itself - didn't change the operation):

Code: Select all

on flapBird
   ##this code moves the bird up and down
   put the bottom of button "bird" into tnewPosition
   add birdDirection * birdSpeed to tnewPosition
   set the bottom of button "bird" to tnewPosition
   
   cityMove
   columnsMove
   checkCollision
   ##loop this code so the bird is always moving
   if gameRunning then
      send flapBird to me in 0.02 seconds
   end if
   
end flapBird

Using the same files and the same code, the program runs perfectly smoothly on Ubuntu. On OSX (I checked using 10.7.5, 10.9 and 10.10) it is noticeably slow. It is a bit more slow with more icons, but even at the minimum of 3 icons (visible - the other 8 are offscreen), it is quite laggy. I haven't had the chance to check Windows yet, but the difference between Ubuntu and OSX leads me to believe it's an OSX-specific issue. Is it the OSX graphics engine? I saw some old references to the Mac's Quartz engine.

When we built as a standalone app, we still saw the same lags in OSX (and none in Ubuntu).

Again, thanks for the help.
John

[bn]

Hi John,

I see a lot of changing of locations in columnsMove without lock screen. That could mean a screen update for each move. Screen updates are costly in time.

Could you try a lock screen at least in columnsMove

Code: Select all

on columnsMove
lock screen
repeat
....
end repeat
unlock screen
end columnsMove

But actually I think it would be even better to enclose handler flapBird with lock screen. Not knowing all the code but it should handle all the presumed screen updates in cityMove and checkCollision also. If that works columnMove does not need a lock screen/unlock screen pair.

Code: Select all

on flapBird
lock screen
...
...
unlock screen
end flapBird

This would take a lot of screen updates out and should make the the game faster.
It used to be that on Mac changing the location of an object within a tight repeat loop would not update the screen. But with the rewrite of 6.7 / 7.0 the screen is updated with each changed location. On Windows this was always the case, if I remember correctly. Maybe on Linux screen updates happen after all handlers are finished (in your case when flapBird is done). That would explain the difference in speed you see. But that is just a guess.

In any case, judicious use of lock screen / unlock screen can do wonders.

Kind regards
Bernd

[jacque]

I think the main problem is that the moving objects need the layermode to be dynamic. A static mode is for objects that don't move, and scrolling is primarily for fields or groups. Dynamic mode is for objects that need to be updated frequently as their positions change.

[j_iglar]

Dear Bernd,

Doh! I told you I was mostly a noob. "Lock screen" - of course, that's it! Just tested and viola. All fixed.

Jacques, I tried the dynamic layer for all elements - didn't change the performance at all. It's the locking screen.

Interesting that Ubuntu doesn't need that code. I will test Windows as well. (Also interesting: I though that putting the unlock screen at the end of my flapBird handler wouldn't work because it references itself, but because of the delay it's OK. (If I didn't include the "in 0.02 seconds" at the end of "send flapBird to me" then it locks the screen until you crash.)

Many thanks for the assistance!

regards,
John

[bn]

Hi John,

glad it helped.

BTW the code does not look like "mostly a noob"

(If I didn't include the "in 0.02 seconds" at the end of "send flapBird to me" then it locks the screen until you crash

you might know this but the crash is to be expected.
The two variants of the "send" command, the simple "send" and "send in time" are completely different in certain ways.
"Send in time" is active after your handler finishes (that is probably what you mean by delay. The handler that issues "send in time" is not affected by "send in time". Time is active after the handler finishes. Then the engine gets a break and can do its clean up and after that a "send in time" can do its work.
Whereas the simple "send" command is executed right from within the handler that issues it. The handler stops its flow of execution and branches into the send command, only after the send command is finished the issuing handler goes on. In your case it never stops and the crash is the result. Effectively creating an infinite loop.
(when doing animation I prefer to time in milliseconds instead of seconds. 40 milliseconds is a framerate of 25 and it is for me easier to play with milliseconds to fine tune performance But that is entirely a matter of taste)
Kind regards
Bernd