-
Physics bodies created in the same location creates too many collision arbiters when added to the space, and initialization takes too long Solution: ensure that they are positioned separately before adding to the space. Note, if there are so many particles that they overlap, then collision is noticeably slow. Change-Id: I88f8ce970bcceb90b213d0f9999400a4e2134944 Signed-off-by: David Steele <david.steele@samsung.com>
-
Added option to execute physics or animation benchmark. Change-Id: I5ecf677cb296e02fecc1fa2287da2141bdbcf191 Signed-off-by: David Steele <david.steele@samsung.com>
-
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