Lots of allocations in Libgdx slow down game and cause sprite-jolts

Question

I found out that LIBGDX allocates a lot of variables (not from any of my methods). I just ran the game for a few seconds and I've already got 32000 rows in DDMS->Allocation Tracker. The methods that allocate are getPalmRejection, createFromParcel and nativeReadString. Is it normal to have this many allocations in just a couple of seconds?

I get 60FPS but sometimes it drops to 58-59 and that is important because I use framerate-independent movement in my game and I get alot of sprite-jolts (sprite-jumps) when this FPS drop happens.

Here are the stack traces :

**createFromParcel**
  at android.graphics.Rect$1.createFromParcel(Rect.java:562)    
at android.graphics.Rect$1.createFromParcel(Rect.java:557)  
at com.samsung.android.multiwindow.MultiWindowStyle.readFromParcel(MultiWindowStyle.java:278)
at com.samsung.android.multiwindow.MultiWindowStyle.<init>(MultiWindowStyle.java:141)   
at com.samsung.android.multiwindow.MultiWindowStyle$1.createFromParcel(MultiWindowStyle.java:284)   
at com.samsung.android.multiwindow.MultiWindowStyle$1.createFromParcel(MultiWindowStyle.java:282)   
at com.samsung.android.multiwindow.IMultiWindowFacade$Stub$Proxy.getMultiWindowStyle(IMultiWindowFacade.java:467)   
at com.samsung.android.multiwindow.MultiWindowFacade.getMultiWindowStyle(MultiWindowFacade.java:53) 
at android.app.ActivityThread.getAppMultiWindowStyle(ActivityThread.java:5368)  
at android.app.ContextImpl.getAppMultiWindowStyle(ContextImpl.java:2698)    
at android.content.ContextWrapper.getAppMultiWindowStyle(ContextWrapper.java:690)   
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:6324)  
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:6307)   
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6278)  
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6243)  
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:6483)  

**<init>**
  at com.samsung.android.multiwindow.MultiWindowStyle.<init>(MultiWindowStyle.java:40)  
at com.samsung.android.multiwindow.MultiWindowStyle$1.createFromParcel(MultiWindowStyle.java:284)   
at com.samsung.android.multiwindow.MultiWindowStyle$1.createFromParcel(MultiWindowStyle.java:282)   
at com.samsung.android.multiwindow.IMultiWindowFacade$Stub$Proxy.getMultiWindowStyle(IMultiWindowFacade.java:467)   
at com.samsung.android.multiwindow.MultiWindowFacade.getMultiWindowStyle(MultiWindowFacade.java:53) 
at android.app.ActivityThread.getAppMultiWindowStyle(ActivityThread.java:5368)  
at android.app.ContextImpl.getAppMultiWindowStyle(ContextImpl.java:2698)    
at android.content.ContextWrapper.getAppMultiWindowStyle(ContextWrapper.java:690)   
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:6324)  
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:6307)   
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6278)  
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6243)  
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:6483)  
at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:185)  
at android.view.InputEventReceiver.nativeConsumeBatchedInputEvents(Native Method)   
at android.view.InputEventReceiver.consumeBatchedInputEvents(InputEventReceiver.java:176)   


**getPalmRejection**
  at android.view.ViewRootImpl.getPalmRejection(ViewRootImpl.java:3895) 
at android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:6389)  
at android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:6307)   
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6278)  
at android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:6243)   
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:6483)  
at android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:185)  
at android.view.InputEventReceiver.nativeConsumeBatchedInputEvents(Native Method)   
at android.view.InputEventReceiver.consumeBatchedInputEvents(InputEventReceiver.java:176)   
at android.view.ViewRootImpl.doConsumeBatchedInput(ViewRootImpl.java:6456)  
at android.view.ViewRootImpl$ConsumeBatchedInputRunnable.run(ViewRootImpl.java:6502)    
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:803)    
at android.view.Choreographer.doCallbacks(Choreographer.java:603)   
at android.view.Choreographer.doFrame(Choreographer.java:571)   
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:789) 
at android.os.Handler.handleCallback(Handler.java:733)

1.createFromParcel

2.getPalmRejection

3.<init>

EDIT: One very probable cause is the MultiWindow feature of Samsung devices . Another possible cause of the allocations is in the methods of the touchDown event of the game screen:

@Override
public boolean touchDown (int x, int y, int pointer, int button) {
    if ( (!spaces_can_explode && !paused_game_screen) && !spaces.exploded_finished && hud_display.startTimerFinished){
        hud.touchDown(x, y, pointer, button, spaces, spaceship_bounding_rectangle, display_fud_camera, hud_display.startTimerFinished);
    }
    return false;
}

public void touchDown(int x, int y, int pointer, int button, Ship spaces, Rectangle shootHud, OrthographicCamera hud_cam, boolean startTimerFinished){
    hud_cam.unproject(touchPoint.set(x, y,0));
    pressed_middle_shoot = shootHud.contains(touchPoint.x, touchPoint.y);           
    if(!(pointer>1) && spaces.touch_upped){
        pressed_left = (x < screen_sizewp3) && !pressed_middle_shoot;
        pressed_right = (x > screen_sizewo2p3) && !pressed_middle_shoot;            
        pressed_middle = (!pressed_left && ! pressed_right);
        if(!spaces.reversed_rotation ){
            if(pressed_middle){
                pressed_shoot = pressed_middle_shoot;
                spaces.pressed_shoot = pressed_middle_shoot;
                pressed_accel = !pressed_shoot;
                spaces.pressed_accel = !pressed_shoot;
            }
            else if(pressed_left && !pressed_right){
                if(spaces.sprite.getX() > spaces_maxleftplus){
                    spaces.touchDOWN(x, y, pointer, button, pressed_left, pressed_right, pressed_middle);
                }
            } else if (pressed_right && !pressed_left){
                if(spaces.sprite.getX() < spaces_maxrightminus){
                    spaces.touchDOWN(x, y, pointer, button, pressed_left, pressed_right, pressed_middle);
                }           
            }
        }
    }       
    pressed_left_hud = pressed_left;   
    pressed_right_hud = pressed_right;
    pressed_shoot_once = pressed_middle_shoot;
}

Can you include the full backtrace from one of these? Its not clear what is calling these routines (Libgdx doesn't generally use the Android graphics objects.) — P.T., Mar 26 '15 at 20:57
I still used AllocationTracker because I don't know quite well how to backtrace. But, I have pin it down to the TOUCH screen event: every time I touch the screen I get all those allocations. I have some `OrthographicCamera.unproject` and `Rectangle.contains` methods in my game screen's **touchDown** event . Could those be the cause? Can I optimize those in some way? — gogonapel, Mar 26 '15 at 21:39
@ rbennett485. I accelerate in my game by touching the screen . When that happens there is a slight jolt of some of the sprites , yes. — gogonapel, Mar 26 '15 at 21:41
@gogonapel the AllocationTracker shows a backtrace for each allocation point. (That's the barely-readable-to-me bottom window in DDMS.) Please copy a full stacktrace from one of the allocations into your question. — P.T., Mar 26 '15 at 22:00
you can simplify the code a bit by removing " ? true : false ". Also this !pressed_middle can be removed from the if clause when there is also a test for pressed_left / pressed_right — uwe, Mar 26 '15 at 22:36
Are you using "Multi-window" mode on your Samsung device? It looks like that might be the root cause? — P.T., Mar 26 '15 at 23:32
http://stackoverflow.com/questions/29290757/how-to-completely-disable-multiwindow-support-in-libgdx-game — gogonapel, Mar 26 '15 at 23:36
@gogonapel fair enough, but the point I was trying to make was that you shouldn't be able to notice jittering from a 2fps difference - this suggests that although you may have a problem with memory allocations, this isn't really the cause of your jolt. Instead it is probably something to do with how your acceleration is implemented in the code — rbennett485, Mar 27 '15 at 10:35
I only get this pb on samsung s4: allocations and frame drop. Other phones are ok and they are considerably worce performance-wise hardware-wise. — gogonapel, Mar 27 '15 at 11:54
Looks like its 100% a Samsung problem. I think you can close this as a dup of your more targeted question. — P.T., Mar 27 '15 at 17:36

Lots of allocations in Libgdx slow down game and cause sprite-jolts

0 Answers0

Linked