I implement linear animation for lot of objects on SurfaceView and found the following issue: on Samsung S4 and S3 the animation is quirky, but FPS is near 60. On other devices works perfectly.
After I disabled hardware acceleration in Manifest it worked much better, but sometimes the screen is flickering.
Please advice where might be the root of problem. Thanks!
upd: as for code - I don't create any objects in realtime but reusing the ones from object pools.
Related
I do not know what could it be, but does not look like a performance issue (like doing too much work on the background) because there is no message on LogCat saying Slow measurement, Frames skipped or ConstraintLayout issues. The app animations work perfectly. But, unfortunately, all the clickable elements that I added on the xml:
android:clickable="true"
android:focusable="true"
android:foreground="?attr/selectableItemBackground"
are too slow. That slow, that whenever I click, instead of the smooth animation that moves and starts on the exact pixel I click on, it appears an awful shadow and remains like so for a while (~2 sec).
If it is indeed an android performance issue, how to debug it? Also, I do not know where to start and which information I need to add in order to add valuable information to this question but, if needed, please, ask for it and I will try to add as much information as possible.
The only thing I could say in advance is I am using MVVM and coroutines, so there is no performance issues on that matter, but maybe only UI related?
EDIT:
Samsung J2 Prime and Samsung Galaxy Note 3 work good, all animations are good (even though is a small and old device)
Motorola Zoom and Redmi Note 8 Pro are working with laggy animations (animations are meant only the clickable animation (Ripple effect), the ConstraintLayout animations are working smooth.
I started playing around with ARCore through unity and testing on a Samsung galaxy S8.
Everything seems to be working fine but the video image that is displayed in the background (done automatically by ARCore) appears stretched vertically. I know the camera aspect on that device doesn't match the weird aspect of the phone's screen but I couldn't find a way to work around this.
This also happens when I build the small sample that comes with the ARCore package. Anyone else run into this?
Seems like a bug in the Unity implementation of ARCore according to this thread.
For those interested, We actually ended up doing fancy shader work to 'un-stretch' the image while pre-stretching all our content so we end up with a correct image - pretty ugly solution and I will happily yank this part out of the project as soon as a fix is issued.
I use LibGDX for rendering a game. I discovered a strange issue on Samsung S3. When touching a screen FPS goes down and animation jumps.
On other devices the app works smoothly. Touch callback is very fast and shouldn't affect a performance.
For adding touch support I use
Stage stage = new Stage(new FitViewport(Gdx.graphics.getWidth(),
Gdx.graphics.getHeight()));
Gdx.input.setInputProcessor(stage);
Could you please advice what might be the root of the issue?
Posting the answer in order to help others..
When enabling Show Touches setting in Developer Options be aware that it might decrease FPS of your game. It was my case.
(I tried to stuff the question with keywords in case someone else has this issue - I couldn't find much help.)
I have a custom View in Android that contains an LED bargraph that displays levels received via socket communication. It's basically just a clipped image. The higher the level, the less clipped the image is.
When I update the level and then invalidate the View, some devices seem to "collect" multiple updates and render them in chunks. The screen visibly hesitates for say 1/10th of a second, then rapidly paints multiple frames, and then hesitates again. It looks like it's overwhelmed and dropping frames.
However, when changing another UI control on the screen, the LED bargraph paints much more frequently and smoothly. I'm thinking Android is trying to help me by "collecting" multiple invalidations and then doing them all at once. Perhaps by manipulating controls, I'm "increasing" my frame rate simply by giving it "more to do" so it delays less between actual paints.
Unlike animation (with smooth transitions) I want to show the absolute latest value as quickly as possible. My data samples aren't faster than 10-20fps anyway.
Is there an easy way to "force" a paint at certain points, or is this a limit of how Views work? Should I be implementing this in a SurfaceView instead? (I have not played with that yet... want advice first.) Thanks in advance for suggestions.
(Later that same day...)
Update: I found a page in the Docs that does suggest implementing my widget as a SurfaceView is the way to go:
http://developer.android.com/guide/topics/graphics/2d-graphics.html
(An hour after that...)
SurfaceView seems overkill for what I want to do. The best-practice method is to "own" the whole canvas, but I have already developed the rest of my controls and layouts and they work well. It must be possible to get some better performance with what I have, especially since interacting with the UI makes the redraw speed satisfactory.
It turns out SurfaceView was the way to go. I was benchmarking on an older phone which didn't help. (The frame rate using a standard View was fine on an ASUS eeePad). I had to throw away some code, but the end result is smoother and faster with SurfaceView. Further, I was able to re-use more code than I expected and actually dramatically simplified my multitouch handling code (since everything I want to touch is in the same SurfaceView.
FYI: I'm still only getting about 15fps on Droid X, but half of the CPU load appears to be data packet processing. The eeePad is doing almost 40fps now -- and my data rate is only 20 samples/sec.
So... a win I guess. I want the Droid X to run better, but it flies on a real tablet.
I am trying out the (latest) Android SDK, and noticed some strange behavior.
I've written a skeletal SurfaceView app: Activity, SurfaceView and a rendering thread. It doesn't actually do any painting, and only writes out the framerate to logcat once a second. When it runs in portrait mode, I get around 60 fps. However, when I flip it to landscape the framerate drops to about 30 fps.
I have also tested it on the LunarLender sample, and got similiar results. All of the testing are done on the emulator, since I don't have a physical device.
What's it all about? I can't seem to find any mentioning to this on Google, have anyone else experienced that? Is it just an emulator quirk or does it apply to physical hardware too?
Guessing here- in landscape mode, is there extra "blank" space on either side of the rendered content? If so there could be an effective increase in the amount of processing just to paint the screen. Don't know if that should account for a 50% decrease in framerate, but it's possible.
Another guess- landscape mode may be deliberately throttled because it's intended primarily for video viewing. No reason to go up to 60fps for 30fps content. Configuration?