The question is when should i use postInvalidateOnAnimation() over postInvalidate()?
Doc says about postInvalidateOnAnimation(): Cause an invalidate to happen on the next animation time step, typically the next display frame.
But what is next animation time step/next display frame? When will it be called?
I've been puzzling over an animation glitch and stumbled upon this question. Tried to answer below:
What is the next display frame?
This is when all the drawing, layouts and inputs are processed.
The concept of vertical syncing (VSync) is used in the Choreographer class after Android 4.1. This is a signal that is sent traditionally from hardware to say the screen is ready to be redrawn. (It's originates in Cathode Ray Tubes) This is typically around 60Hz on monitors.
The Choreographer is the 'UI threads' message handling loop. On every VSync, the UI messages are processed. These messages will handle inputs and redraw the display. (The Choreographer will also do other things such as skipping frames if the UI is running too slow - this is a common message on the debug console!)
This message loop handling constitutes a frame. When will it be called - every 1/60th of a second on a 60Hz frame rate.
This video
from Google I/O 2012 describes this vsync and the choreographer in more detail.
What is the difference between postInvalidateOnAnimation() over postInvalidate()?
When smooth animations are required use postInvalidateOnAnimation, when redraw is required use postInvalidate().
Reasoning:
This was quite hard to answer, both of these methods are for threads communicating with the UI Thread. So I dug into the Choreographer code
and found this in doFrame()
doCallbacks(Choreographer.CALLBACK_INPUT, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_ANIMATION, frameTimeNanos);
doCallbacks(Choreographer.CALLBACK_TRAVERSAL, frameTimeNanos);
postInvalidateOnAnimation will put a callback into the animation callbacks and postInvalidate will will put into the traversal callbacks.
The key difference for me is that the animation callbacks are called before the traversal callbacks (layouts, draws).
This means that animation call backs will be called at almost exactly 60fps (processed first) whereas the traversal callbacks may have some small jitter as the layouts and view drawing is done (less than 1/60 second jitter but probably still noticeable)
Take a look at this class: http://developer.android.com/reference/android/view/Choreographer.html
Short desc from the docs:
Coordinates the timing of animations, input and drawing.
The choreographer receives timing pulses (such as vertical synchronization) from the display subsystem then schedules work to occur as part of rendering the next display frame.
Applications typically interact with the choreographer indirectly using higher level abstractions in the animation framework or the view hierarchy. Here are some examples of things you can do using the higher-level APIs.
Related
I am trying to capture the screen shot of my android application from onDrawFrame function of my Renderer. But it is dropping the frame and freezing the application till the process is complete. I am trying to do it on a different thread but no success. Is it possible to get the screen shot on a different thread.
You can't perform the glReadPixels() from another thread, because the EGL context can only be current in one thread at a time, and you have no control over it with GLSurfaceView.
However, 95+% of the time spent grabbing a screen shot from GLES is spent on PNG/JPEG compression and disk I/O. So if you make the glReadPixels() call from onDrawFrame(), and then hand the data off to a new thread, you should be able to continue running while the screen shot is processed in the background.
As already mentioned a direct read may be impossible from another thread but there are other ways.
Instead of drawing your scene directly to the surface view you may draw it to a frame buffer object (FBO) with attached texture and then redraw the texture to your main buffer. This is a pretty standard procedure for post processing and such and does not have a high performance impact. To realize this you actually just need to look into how to create the FBO, bind it before the drawing begins and the rest of your code should keep as it is. Then also add the code to redraw the FBO texture on the screen by binding the main buffer (index 0 should do).
For the screenshot on a separate thread you now need to create a new thread and a new context which is set on that thread. The new context must be shared with the main one (I believe there is a constructor that accepts the main context for that) so you may share the texture. Now the fun part: When you want to take the screenshot you need to create a new texture, attach the new texture to the FBO, detach the old texture. By doing so you kind of steal the texture to which the content is drawn and you can do whatever you want with it and on any thread you want. So put it into your secondary thread and on that context you may create another FBO, bind it and read the pixels from it on that thread. Do not forget to cleanup though.
Some caution is advised though. This kind of procedure may be good when you make a relatively small amount of screenshot. If one screenshot is not completely done before another one begins you will inflate in memory usage and your app will most likely crash. So be careful not to do that, create some kind of locking mechanism or limit the number of screenshot processing in progress. And this is not just for openGL, the same issue may occur when simply encoding the image data.
And just a note on your original idea: Even if you could use the surface view on a separate thread and read pixels from its main buffer you may not expect you will get a good result. The buffer may be drawn to while you are reading so it would be possible you would get chunks of data from different frames. Still this is just in theory because the truth is the buffer would simply be locked and your application would crash while trying to access it. So this is in no way possible and even if it was the result would be unpredictable.
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()).
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.
So in my game my View gets drawn an inconsistent rates. Which in turn makes it glitchy. Ive been running into alot of problems with the invalidate(); meathod. Any simple ideas- Everywhere i look I get thrown up on by tons of intense code.
You haven't provided us with much information, specifically code.
A few things you could do are:
Set the initial frame rate to the lowest value you observe your application runs at, i.e., if currently set to 1/60, but the frame rate continuously dips to 1/30, set to 1/30 etc.
Rework your drawing calls to be more efficient.
Try to combine multiple transformations into a single transformation by multiplying matrices, i.e. if you need to scale, translate, and rotate, multiply those three matrices together and apply that single transformation to the vertices instead of applying three separate transformations.
Try not to iterate through entire lists/arrays if unnecessary.
Attempt to use the lowest level / most primitive structure possible for anything you have to process in the loop to avoid the overhead of unboxing.
[edit on 2012-08-27]
helpful link for fixing you timestep: http://gafferongames.com/game-physics/fix-your-timestep/
It sounds like your game loop doesn't take into account the actual time that has passed between iterations.
The problem is the assumption that there is a fixed amount of time between loop iterations. But this time can be variable depending on the number of objects in the scene, other processes on the computer, or even the computer itself.
This is a common, somewhat subtle, mistake in game programming, but it can easily be remedied. The trick is to store the time at the end of each draw loop and then take the difference of the last update with the current time at the start. Then you should scale all animations and game changes based on the actual elapsed time.
I've wrote more about this on my blog a while back here: http://laststop.spaceislimited.org/2008/05/17/programming-a-pong-clone-in-c-and-opengl-part-i/
Part II specifically covers this issue:
http://laststop.spaceislimited.org/2008/06/02/programming-pong-in-c-and-opengl-part-ii/
When is it necessary, or better to use a SurfaceView instead of a View?
Views are all drawn on the same GUI thread which is also used for all user interaction.
So if you need to update GUI rapidly or if the rendering takes too much time and affects user experience then use SurfaceView.
A few things I've noted:
SurfaceViews contain a nice rendering mechanism that allows threads to update the surface's content without using a handler (good for animation).
Surfaceviews cannot be transparent, they can only appear behind other elements in the view hierarchy.
I've found that they are much faster for animation than rendering onto a View.
For more information (and a great usage example) refer to the LunarLander project in the SDK
's examples section.
updated 05/09/2014
OK. We have official document now. It talked all I have mentioned, in a better way.
Read more detailed here.
Yes, the main difference is surfaceView can be updated on the background thread. However, there are more you might care.
surfaceView has dedicate surface buffer while all the view shares one surface buffer that is allocated by ViewRoot. In another word, surfaceView cost more resources.
surfaceView cannot be hardware accelerated (as of JB4.2) while 95% operations on normal View are HW accelerated using openGL ES.
More work should be done to create your customized surfaceView. You need to listener to the surfaceCreated/Destroy Event, create an render thread, more importantly, synchronized the render thread and main thread. However, to customize the View, all you need to do is override onDraw method.
The timing to update is different. Normal view update mechanism is constraint or controlled by the framework:You call view.invalidate in the UI thread or view.postInvalid in other thread to indicate to the framework that the view should be updated. However, the view won't be updated immediately but wait until next VSYNC event arrived. The easy approach to understand VSYNC is to consider it is as a timer that fire up every 16ms for a 60fps screen. In Android, all the normal view update (and display actually but I won't talk it today), is synchronized with VSYNC to achieve better smoothness. Now,back to the surfaceView, you can render it anytime as you wish. However, I can hardly tell if it is an advantage, since the display is also synchronized with VSYNC, as stated previously.
The main difference is that SurfaceView can be drawn on by background theads but Views can't.
SurfaceViews use more resources though so you don't want to use them unless you have to.
A SurfaceView is a custom view in Android that can be used to drawn inside it.
The main difference between a View and a SurfaceView is that a View is drawn in the
UI Thread, which is used for all the user interaction.
If you want to update the UI rapidly enough and render a good amount of information in
it, a SurfaceView is a better choice.
But there are a few technical insides to the SurfaceView:
1. They are not hardware accelerated.
2. Normal views are rendered when you call the methods invalidate or postInvalidate(), but this does not mean the view will be
immediately updated (A VSYNC will be sent, and the OS decides when
it gets updated. The SurfaceView can be immediately updated.
3. A SurfaceView has an allocated surface buffer, so it is more costly
One of the main differences between surfaceview and view is that to refresh the screen for a normal view we have to call invalidate method from the same thread where the view is defined. But even if we call invalidate, the refreshing does not happen immediately. It occurs only after the next arrival of the VSYNC signal. VSYNC signal is a kernel generated signal which happens every 16.6 ms or this is also known as 60 frame per second. So if we want more control over the refreshing of the screen (for example for very fast moving animation), we should not use normal view class.
On the other hand in case of surfaceview, we can refresh the screen as fast as we want and we can do it from a background thread. So refreshing of the surfaceview really does not depend upon VSYNC, and this is very useful if we want to do high speed animation. I have few training videos and example application which explain all these things nicely. Please have a look at the following training videos.
https://youtu.be/kRqsoApOr9U
https://youtu.be/Ji84HJ85FIQ
https://youtu.be/U8igPoyrUf8
Why use SurfaceView and not the classic View class...
One main reason is that SurfaceView can rapidly render the screen.
In simple words a SV is more capable of managing the timing and render animations.
To have a better understanding what is a SurfaceView we must compare it with the View class.
What is the difference... check this simple explanation in the video
https://m.youtube.com/watch?feature=youtu.be&v=eltlqsHSG30
Well with the View we have one major problem....the timing of rendering animations.
Normally the onDraw() is called from the Android run-time system.
So, when Android run-time system calls onDraw() then the application cant control
the timing of display, and this is important for animation. We have a gap of timing
between the application (our game) and the Android run-time system.
The SV it can call the onDraw() by a dedicated Thread.
Thus: the application controls the timing. So we can display the next bitmap image of the animation.