Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad frame rate on poor android devices #4

Open
mgsx-dev opened this issue Mar 24, 2017 · 2 comments
Open

Bad frame rate on poor android devices #4

mgsx-dev opened this issue Mar 24, 2017 · 2 comments
Assignees

Comments

@mgsx-dev
Copy link
Owner

mgsx-dev commented Mar 24, 2017

about 30 to 45 Fps on all rainsticks except "Big grains" on my Asus tablet.

Have to investigate where are the bottlenecks :

  • unnecessary drawings (bugs from KIT) ?
  • physics ?
  • background shaders ?
  • multiple clear screens ?
  • Ball blendings ?
  • Too many impact particles ?
@mgsx-dev mgsx-dev self-assigned this Mar 24, 2017
@mgsx-dev
Copy link
Owner Author

It appear that pdSend methods takes a lot of time. When rainstick is idle, there are just 3 calls. When I disable them, frame rate get to normal.

I pushed some benchmark tests for both android and desktop and it appear that issue is in engine itself. For instance the sendFloat method take 10 times when calling "kit-freq" than "kit-mixa-dry".

note I benchmarked gdx-pd as well (without audio engine) and time spent in send methods are reasonable, there is some issues with sendList/sendMessage though, see mgsx-dev/gdx-pd#10

Another observation is that Box2D takes lot of time as well specially with polygon shapes, circles give better results.

Global observations, it appear that frame rate issue seams to be caused by a global load :

  • high pd message frequency
  • lot of box2d dynamic bodies and lot of jni calls to box2D
  • lot of blending
  • the audio engine might be part of it (25 + 10 + 1 = 35 stereo polyphonic voices)

What I can do to quickly improve things is to avoid jni calls and pd message processing as much as possible :

  • avoid calls to pd if values doesn't changed (mix and formants)
  • caching some box2D information (mass, position at each frame).

mgsx-dev added a commit that referenced this issue Mar 25, 2017
* use ball mass cache
* reject with square velocity
* avoid vector copy
* use impact position instead of ball position for stereo computation
@mgsx-dev
Copy link
Owner Author

Ok I have better results now but I suspect the fill rate now : lot of blending when lot of long living impacts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant