I am working on an android canvas game and have noticed a lagspike just as the main game form is being drawn. It started just after I started sprinkling synchronized(surfaceHandler) around different parts as an attempt to battle concurrent array modification. Did I over synchronize? What is the rule of thumb on when to synchronize and when not to, and when should visible data be modified?
Also is it possible that the spike is caused by something else? The draw method executes while this is happening, but no touch interaction is possible (most, if not all, of the touch method is synchronized).
Advice?
I think that as long as you are generated a canvas from the surface holder in one area, you shouldn't have to synchronize. This may or may not be causing the lagspike. If you are using surfaceHandler in multiple threads, you may want to condense all your drawing into one thread or you will need to keep the synchronize.
Related
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.
I'm writing a simple 2D game engine and rendering various objects to a locked SurfaceVew by calling Canvas.drawBitmap (all the same source bitmap but generally not with 1:1 source to destination scaling).
Everything appears to work as expected until there are a lot of calls per frame to drawBitmap. When this happens I occasionally see a stall (100mS or so) accompanied by an effect that looks as if several frames of rendering have occurred together, i.e. some objects will be drawn twice at two screen locations or a pair of objects moving at the same speed will appear to momentarily get closer together or further apart.
The application is structured as follows (simplified for the sake of example);
initialiseGameObjects();
while(quit==false)
{
processGameLogic(); // update object positions
Canvas c = surface_holder.lockCanvas();
if (c != null) {
drawGameObjects(c); // draw all objects
surface_holder.unlockCanvasAndPost(c);
}
}
As I understand it, the Canvas is a holder for draw requests which get executed when the Post is issued. Presumably there is a limit to the number of requests it can hold and I'm wondering if I'm exceeding this limit (I'm drawing up to a hundred small bitmaps depending on what's on screen at any one time) and inadvertently provoking some kind of flush and upsetting the double buffering in some way, although I've not managed to find any documentation to confirm or disprove this.
Does anyone have any idea what might be going on?
Regards,
Steve
You need to sychronize calls to canvas drawing. Check this example of a game driving thread: OnDraw() is not fired, nothing is drawn in surfaceView - Android
EDIT:
However I think it may be related to this problem:
Android SurfaceView/Canvas flickering after trying to clear it
After getting help with starting android pong, I realized that I painted myself into a corner.
For reference on the code(Its long) and advice, here is a link to the last thread Updating player score in an android game
Basically the frame rate is halved when i touch the screen. I think it is due to updating everything or drawing on the canvas. This also lends itself to bad communication between the pieces of the application(the view, frame, and oncreate). Is there a recommended way to create an android 2d game? This is based off the lunar landing game and it seemed fine but when i tried to recreate it , it seemed much worse. I could not find a lot of resource on a best practice for drawing and so far this seems a bit discouraging.
So in short
How would you modify the code posted in the link to improve performance? Or did I paint myself into a poorly made corner, and it is time to start a new? If so , how?
Thanks
You don't need invalidate() in onTouch because you are already running a frame animation by the additional thread.
Try to define all the fixed values/variables in the constructor of the SurfaceView or in onSizeChanged() where you know the size of the canvas and bitmaps loaded, so not to make any unneccesary variable creation, requests or calcualtions in onDraw, onTouch or other methods to handle game logic, otherwise it will slow down.
In my app I am drawing bus routes on top of a MapView. The routes have anywhere between a dozen and a few hundred GPS coordinates that describe the route that the bus takes.
The problem I'm having is that once I draw out all these lines panning/zooming the MapView is incredibly slow (even clicking the 'Back' button takes a minute to happen).
I'm not sure how relevant it is, but I put in some debug code then checked the logcat output and the MapView is repeatedly calling the draw() method of the Overlay whether anything has changed or not. This is happening several times a second and is causing a massive amount of garbage collection to happen (2-3 MB every second).
Does anyone have any ideas/suggestions for a method to try and speed this up?
I have only used ItemizedOverlay, not Overlay, so these suggestions are pure conjecture. Heck, I haven't even done much with the 2D graphics API.
Obviously, the best answer is to get it to stop calling draw() all the time. Try logging some stack traces and see if you can figure out what is triggering all of the draw() calls. For example, in the Android Google Groups recently, somebody noticed that Chronometer causes widgets in the same UI to be redrawn every second. While I can see you don't have a Chronometer, you might be able to figure out some root cause to the draw() calls that you can correct.
Assuming that does not help, I am guessing that the test for "whether anything has changed or not" is some combination of getLatitudeSpan(), getLongitudeSpan(), getZoomLevel(), and maybe other MapView methods. And, I am assuming that on every draw() you are iterating over your GPS points and drawing the route. If so, you could try:
When you really do draw, draw first to a Canvas backed by a Bitmap, then apply the Bitmap on the Canvas you are handed in draw(), and cache that Bitmap.
Track what combination of values were used in the last draw(), and if the next draw() is the same, just reuse the existing Bitmap. Else, go to step #1, making sure to release the Bitmap (or reuse it, if that's possible).
I am guessing that with graphics acceleration, blasting a Bitmap onto the Canvas is cheaper than iterating over the coordinates and drawing lines. And, by caching the Bitmap, you will save on garbage generation.
Anyway, just a thought.
There are two draw methods in the overlay class. One with 3 arguments and one with 4 arguments. You have to override the draw method with 3 arguments.
Overriding the method with 4 arguments will slow down your application. This is exactly, what happened to me. It seems, where are examples around in the internet with the same error.
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.