Testing frame rate with many moving graphics objects

[OpenXTalkPaul]

This stack is a demo that comes with the IDE (its old), but it can help get an idea of how laggy your frame rate will get when you add too many objects to a card and try to move them all in sync, and will give an idea of just how many are too many.
Like all the 'classic controls' it uses Cairo Graphics rendering. Widgets actually use a differnet rendering engine, libSkia for the graphics library, which is newer, faster, and does nicer sub pixel rendering IMO,
Something like this demo but as a widget would be much faster, and probably could handler more 'objects' without lagging.

Balls.oxtstack

(17.93 KiB) Downloaded 28 times

[xAction]

Wow, that's so super cool. Runs crazy fast. About 1400 balls and it lags. Maybe before that. But 400 or so was fine.

Oh code gold!

## Work out how long this loop took and based on this value, call the next loop.
## If this loop overran, make sure to tell the next loop.

get kBouncePollRate - (the milliseconds - tStartTime) - pTimeMissed
send "bounceBalls" && max(0, it * -1) to me in max(0, it) milliseconds

[OpenXTalkPaul]

Wow, that's so super cool. Runs crazy fast. About 1400 balls and it lags. Maybe before that. But 400 or so was fine.

Oh code gold!

## Work out how long this loop took and based on this value, call the next loop.
## If this loop overran, make sure to tell the next loop.

get kBouncePollRate - (the milliseconds - tStartTime) - pTimeMissed
send "bounceBalls" && max(0, it * -1) to me in max(0, it) milliseconds

Yeah, and it also illustrates Object Oriented Programming where you send messages to objects.
That line "kBouncePollRate - (the milliseconds - tStartTime) - pTimeMissed" is exactly what I was talking about in that other thread. To (try to) maintain to constant rate you should subtract the time you took to do stuff from the loop iteration time ( the next message send time ).