Android: Application becomes unresponsive after short delay - android

I've noticed my whiteboard app becomes 'dormant' after a few seconds of no interaction, so that when something is newly drawn, there is horrible lag. This is without switching away from the app at all - I run it, it's there, I can draw and undo. But if I don't use it for 10 seconds and then try and draw a circle, there can be a second or so of wait before it updates and I get a straight line from start point to current position. So the code to start drawing is instant when the view is touched, but the updates aren't happening for a good while yet.
The code is effectively the Fingerpaint demo drawing onto a custom bitmap, and I copy this bitmap to the view. I undo by copying the bitmap just before drawing starts. I have disabled the undo code to see if that was the issue, but the delay is still there, only far less pronounced. I notice the same lag sometimes happens in the Fingerpaint API demo.
Anyone know why this is? Is there some odd setting I don't know about which causes an active app to go to sleep?

Related

Why are my map marker ObjectAnimators getting canceled?

The app I work on animates map markers after they are added to the screen using ObjectAnimators. The animation replaces the icon with progressively larger or smaller bitmaps. About 20% of the time, it will randomly cancel the animation, leaving it only partially enlarged or shrunk. I know it's getting canceled because a) the animation doesn't complete and b) if I add an AnimatorListener, then onAnimationCancel() is called in those times.
It doesn't seem to be related to garbage collection, to other pins (it can happen when only one pin is placed on the screen), to other code that runs while the animation is in progress.
They are not set to autoCancel, and even if they were, it wouldn't be triggered because multiple identical animations are not being started.
Any idea at all why this would happen? Has anyone ever seen animations being canceled randomly and unexpectedly?
Well, I feel like an idiot--I finally realized why this was happening!
ObjectAnimators only have a weak reference to their target object.
If you don't maintain a separate reference to the object being animated in some other variable, then sometimes it will be garbage collected before the animation is finished. The next iteration of the ObjectAnimator will attempt to update the object, fail because the target object is null, and then it will cancel the animation.
The solution, then, is simply to ensure you have a variable referencing that object, at least until the animation is complete.
Hope this helps--I'm sure I can't be the only one that's run into this issue!

Animation ist only smooth when ontouchevent is called

i'm making my first 2d sidescroller game using a surfaceview and a canvas to draw things on (a lot of primitives put in different path objects).
my game loop uses fixed timesteps with linear interpolation. i don't create any objects during the game. i've been improving my code for 3 weeks now, but my animation is still not all the time smooth. it's ok, but every few seconds there are a lot of little hicks for about 1 or 2 seconds.
what i recognized is when i move my player (this means touching the screen), the little hicks disappear for as long as i touch the screen and move my player.
this means as long as ontouchevent of the surfaceview is called, the animation is smooth.
i dont understand this and i want a smooth animation. can somebody help me?
This sounds like a known issue on certain devices. See e.g.:
Android SurfaceView slows if no touch events occur
Animation glitches while rendering on SurfaceView
Android thread performance/priority on Galaxy Note 2 when screen is touched/released
The problem is that the system is aggressively reducing clock speeds to save power when it doesn't detect interaction with the user. (Qualcomm in particular seems fond of this.) The workaround is to drop frames when necessary. See this article on game loops, and a Choreographer-based trick demonstrated in Grafika's "record GL app" activity (in doFrame()).

Android: for canvas animation, better have 1 big thread, or a number of small threads

i make an app which would fire different small animation, such a falling rotating star or a like a text floating from bottom to top, animated with canvas on a surfaceview
they are all constant once fired,
so i planned 2 ways for that, 1 is a big thread which
handles them all animations, updates each after each other animation 1 after 1
or having for each kind of animation such as a falling star, have it's own thread set up, and at each given point the main activity could have a command go on one of the threads, creating him, and starting, and than forgetting about him, letting him run in the background and at the end of the animation that thread will end it self.
so i don't have to worry about storing each fired threads and such, cause i don't know how many could start at a given time.
so will it be more memory efficient to fire random small short threads or have 1 big thread to handle it all? will it work more smoothly and better?
the animations are simply for visual enchantment and does nothing else, neither does it interact with other animations it simply starts, loops, ends.
i hope u understood :\
You probably want a SurfaceView with one thread handling all of your drawing. Having one thread per animation seems overly-complicated. You can certainly have one method per animation type, e.g. renderStars(), renderText(), etc. that are called whenever your one animation thread renders.
Recommended reading:
The SurfaceView documentation
The Canvas and Drawables API Guide - I've linked to the "On a SurfaceView" section, but you should probably read most of the document.
The Lunar Lander sample app - The online code is currently 404-ing after Google recently revamped their developer site, but this link shows you where to find the code in the SDK manager.
During animation you will have to update your UI on UI Thread you cannot use a different thread for running animations. However, for intensive animation you must use a Gaming Engine or write your own Game Thread, that will first update data of objects as per animation formulas and afterwards draw them on UI thread.

android problem with thread

I am working with a drawing application. ON A CANVAS i able to draw something as free hand.
What i am doing here, i just store the paths in a List<path> and drawing on canvas synchronized by a thread.
when i am starting to draw for 1st time it is so smooth and speed also, but as paths are increased List<Path> size also increased so it becomes so slow , so terrible.
if i clear the List then again it becomes smoother.
But i want for every time it should be smoother. How can i do it?
IS there any way?
Thank you
I think if you are using invalidate to refresh the screen on a View, only invalidate the area where you drew the new line. So the system will not keep drawing everything. Other option is you handle the event and you keep one list for your undo redo purposes and another smaller detailed list for actual drawing.

What happens in the system when canvas.drawBitmap is called?

I have a scrollable and zoomable map which has a low res copy of the map which is drawn when the zoom scale is small and a tile system when the user zooms in past a certain point. The problem im having is that the very first time the tiles are drawn there is a short, but noticable lag. After that initial lag everything is smooth. The GC isnt running, and all the bitmaps are loaded at launch time. Any idea what exactly is going on so i can take care of the lag? Or any way for a work around? Thanks. Heres the code below:
canvas.drawBitmap(map, null, bgRect,paint);
if(matrix[0]>.9){
mapPicture = makeMyMap(xScale,yScale); //make/update our map.
mapPicture.draw(canvas);
}
Try switching on tracing with DDMS to establish which methods take a long time on the first draw and see how they compare with the subsequent draws.
It's possible that drawBitmap is triggering the platform level up-scale / down-scale of the images on first draw rather than load - but that's speculation on my part.

Categories

Resources