I am writing an Android application that needs to rotate the screen as many times as possible in a certain period of time.
I can rotate the screen fine with setRequestedOrientation(int). The problem I am having is that if I try and rotate the screen in the last call to Activity, onWindowFocusChanged(boolean), the screen cannot keep up with the amount of times setRequestedOrientation is called.
My logcat is showing me that I am getting roughly 5-10 "Setting rotation to [0|1|2|3]" before I get one complete screen rotation.
Here's what I have tried:
Using view to request focus and using a OnRequestFocusChanged Listener
Rotating screen in a child thread to run runOnUiThread to add to main thread message queue
View.post
I know iv'e tried other stuff, but I forget, those are the most recent, and as you can tell I'm getting desperate.
So, is there a way to make sure that the Activity has fully rotated and is accepting user input? Maybe there is a way to check and see if the Activity is looping and waiting for input? Any help here would be absolutely great! Thanks guys.
Related
I am using SurfaceView with ndk+openGL, when press screen rotate button of the emulator,
i received SurfaceChanged event from SurfaceHolder.Callback, then i post a redraw message via Handler, and the Handler redraws the screen with new display metrics via JNI native code, but the display is broken, as the picture shows.
I sure that the native OpenGL drawing code already draws one frame, after press rotate button and before screen rotation finish, but don't know why the display is broken.
I'm not so familiar with android, could someone help me. thanks.
EDIT:
when i make some touch events to trigger new frames, the display got fixed.
so i'm thinking is there a rotate finish event, so i can force draw one frame to fix this issue.
Problem solved.
Override the surfaceRedrawNeeded method of SurfaceHolder.Callback2, it will be called after rotate finished.
I am struggling with a quite rare problem.
Here it goes:
I have a SurfaceView and there is a JNI-side thread that handling the rendering operations on it (Let say Render-thread). For "some" reason I need to rotate my drawings by myself inside the render-thread. To achieve this, the render thread queries the rotation status from the android framework. And I can see the rotated screen whenever the device is rotated, but there is a problem: if I rotate the device, the screen rendered by Render-Thread is rotated, but Android UIs (such as notification bar, toast message, etc) are not rotated (Of course!). To resolve this problem, I use setRequestedOrientation function to tell the Android to rotate my Activity. Then I can also see the properly rotated Android UIs. At this moment, my real problem happens: The race between Render-Thread and Android's screen rotation stuff (I guess surface flinger?).
Apparently, if I call setRequestedOrientation function, Android framework rotates the screen by itself, while my Render-thread is also drawing the rotated screen. And this results in a glitch.
My question here is that:
Is there a way to tell Android framework not to rotate the SurfaceView while I'm still calling setRequestedOrientation?
I'm looking a minimising battery usage in a game I'm developing, and battery usage is something that's very hard to measure accurately, so I was hoping someone in the know might be able to answer this.
Is it likely to be worth my implementing a system where I don't render when there are no updates to what's displayed on the screen? Something like
updated = false;
for each component
updated |= component.update();
if (updated)
render();
This is the kind of thing that's much easier to add at the start, if it'll be worthwhile, than to try to add in at the end if it's required.
If I was rendering through the CPU then I'd definitely say it was worth doing, but through the GPU I'm not so sure. Will in save an insignificant amount of battery compared to things like the screen being on?
edit:
A bit of clarification. I'm creating a word game, so a lot of the time the user is going to be staring at a motionless screen looking for words. Depending on the mode the game is being played in, something could happen on the screen that isn't triggered by user input. For example, a new object appearing on the screen every 5 seconds. Rendering 300 frames where nothing happens every 5 seconds seems a real waste and is something I'd like to avoid.
I don't know if your method does minimize the battery usage, but i think it would be better to disable continuous Rendering by calling Gdx.graphics.setContinuousRendering(false); in the Applicationlisteners create or something like this.
By doing this you stop the gameloop from calling your render() method. It is then only called in the following situations:
On Input (Keypress, touchdown...)
On a call of Gdx.graphics.requestRendering();
On a call to Gdx.app.postRunnable()
Read this for more informations.
EDIT:
I have now read your edit. Well "Puzzle game" sounds a bit generally for me. If you are sure, that the user will be staring at a motionless screen for a long time, to find a possible solution, then maybe the non-continuous rendering is the right way. But if it is (for example) a platformer with some puzzle elements, the user will probably move the whole time and solve the puzzle "on the fly". In this case i would redner normally.
Also you have to think about the other logic, outside of the current view:
Again the example with the platformer: If you have to solve a puzzle to open a door or whatever, behind this door maybe some monsters are waiting for you to come. So if they patrol arround, you have to update their possitions, even if they are outside of the view (behind the door, outside of the building...). In this case again i would not use non-continuous rendering.
The timer you mentioned, will call render(), if it is fired. See this for reference.
To run something, without calling render() you need to run it on another Thread, so for this use java.util.Timer instead of libgdx Timer.
EDIT: As you have now replaced "puzzle game" with "word game" i think i know what you mean.
Normally you only need to render, when an input event is fired. But as much as i understood you want some objects to appear on screen (to make it more interesting than a motionless picture?). For this you need to use a Timer, i am not sure if libgdx Timer could do this, if not you can use java.util.Timer and when a Timerevent gets fired you just call requestRendering() and in your render update gamelogic and the redraw.
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?
After getting so much help from Stack-Overflow I'd like to share back some of my experience:
I spent hour of debugging with one special
09-18 08:11:37.177: DEBUG/SEC_Overlay(128): overlay_setPosition(-1) 03,680,90,120 => 503,680,90,120
09-18 08:11:37.177: INFO/SEC_Overlay(128): Nothing to do!
This is logged each time the GLSurfaceview is updating. But only when the GLSurfaceview is used in combination with a relative Layout and a camera preview. This is combination is essential for the AndroAngelo App. On the main screen I have the radial OnScreenMenu overlayed onto the GLSurface view and on the calibration screen I put the result of the image detection onto the preview.
It decreases the performance essentially.
What to do?
I really did not went to the ground of it. It appeared two times. The second time it just disappeared after a restart of the eclipse. The first time maybe also, but I played around with camera parameters. And then it disappeared.
It comes back from time to time. It seems to be something in the phone. Each time it appears, i simple reboot the Android device and it is gone afterwards.