-
Since we were create new animations every PropertyNotify, and at that time, we iterate whole balls. If event thread time delayed (~= the ball is very much) event callback stacked a lot, and then break the app. To avoid it, we make the number of animations relative with ball + change the animation only if we need, not always. It will reduce the event thread overhead. Change-Id: Ic6da267e827d012c9e68c7d64594596f3617233a Signed-off-by: Eunki, Hong <eunkiki.hong@samsung.com>
-
When we are running on animation ball, mPhysicsAdaptor don't have body. If then, when we resize the window, it will be asserted Change-Id: I2c71a2b1e845d7257f581fcc41f997794ee78fa5 Signed-off-by: Eunki, Hong <eunkiki.hong@samsung.com>
-
First 30s, runs N balls using Animation & property notification that don't interact, Second 30s, runs N balls using 2D Physics and collisions. N by default is 500, but can be changed on the command line. FPS tracking is automatically switched on for this benchmark (Also changed CMakeLists.txt to be able to work as a subdirectory in a multi-repo build) Change-Id: Iccee1d40650563e3f45e021b4fb3fff871cc393e
