I want to draw (4 or 5) real-time charts visualizing a lot of data (a new value every 30ms) within 15 minutes. I am using Path but it seems to work very slowly when I want to display over 20000 values and translate the canvas and it gets worse every second. I also tried using drawLine but it doesn't work fluently at all.
Does anyone have any ideas about a better solution than Path? Or maybe I am doing something wrong? My current solutio is : I initialize the Path in the beginning and then just add a new line to it every time I get a new value, then I translate the canvas.
Displaying a path of 20 000 values will probably be slow whatever you use, even in OpenGL, it's just a lot of data to send to the graphics chip to draw...
The "correct" way to do it (performance-wise) is probably to cache as much stuff as possible, and draw only what needs to be drawn. You could for example draw to a bitmap the first N points, and then only use a path for the next M points (and draw the bitmaps for the previous ones). Drawing a bitmap is pretty fast. So once in a while, you could just refresh your bitmap (which will take a bit more time) and then plot the remaining points.
You could also decide to have a shorter path : do you really need 20 000 values ? Couldn't you be grouping points 5 by 5 or 10 by ten (or even more) ? Currently, the screens are at most 1280 pixels wide anyways...
Are drawing all of that in every onDraw()? That's why it's slow. First of all, nobody can see changes every 30ms. So keep drawing updates into a cache bitmap, then call invalidate(). Then in onDraw() just copy that bitmap onto the canvas.
Drawing over 20000 lines with canvas is going to be slow, no matter what. My bet is that you have to go with openGL on this one. This link might be helpful: http://obviam.net/index.php/opengl-es-with-android-switching-from-canvas-to-opengl/
Related
I noticed on MIT app inventor that there is no way to clear a canvas without using the .clear method. This means that you would have to manually redraw the whole screen every time you update it, right? So, what do you do in order to avoid blinking when you redraw your objects. Is there a way to have a whole canvas behind the first in order to avoid blinking, and then update it, or do you just have to deal with the blinking how it is.
I realize that it is quite possible to make an array/list of every pixel on the screen, with an int for the RGB value of each pixel, and then just draw to that list. Then you can simply copy the array to the screen to render. I think this would be excessively slow and tedious in a language as simple as MIT app inventor.
what you could do is to store your canvas as image and later assign that image to the canvas background again... see also How to Save a Canvas
You also might be interested in Scott's Paintpot mod undo and redo example here
I realize that it is quite possible to make an array/list of every pixel on the screen, with an int for the RGB value of each pixel, and then just draw to that list.
exactly, this will be slow
btw, you can find more Canvas examples (and also other stuff) from Scott here
Currently I am doing app allowing user to draw. Simple think, just extend Canvas class and most of the thing is done.
That was my initial thinking and idea. But as the canvas is rather small because this is only what user see on the screen there is not much possible space to draw. Going through documentation I found translate() method allowing me to move canvas. What I did find out is when I move it, there is some kind of blank space just as you would move piece of paper. I understand that this is totally normal, as I've said before - canvas is only "the screen".
My question is - is there a possibility to make something like infinite canvas so you can make a huge painting and move everything around?
Before this question I was thinking about two things how something like this can be done:
Move all objects on canvas simultaneously - bad idea, because if you have a lot of them then the speed of moving is very bad.
Do something similar as it is done in ListView when you move it (or better see on the screen) only views that are on the screen together with one before and one after are loaded to memory and rest is uploaded dynamically when needed. I think this is the best option to achieve this goal.
EDIT:
Question/answer given by Kai showed me that it is worth to edit my question to clarify some of the things.
Basic assumptions about what can be done by user:
User is given opportunity to draw only circles and rectangles with some (around 80%) having drawable (bitmap) on them on canvas.
I assume that on all screens there will be maximum 500-800 rectangles or circles.
First of all thinking about infinity I was thinking about quite big number of screens - at least 30 on zoom 1x in each side. I just need to give my users bigger freedom in what they are doing.
On this screen everything can be done as on normal - draw, scale (TouchListener, ScaleListener, DoubleTapListener). When talking about scaling, there is another thing that has to be concerned and connected with "infinity" of canvas. When user is zooming out then screens, or more precise objects on the invisible "neighbours" should appear with proper scaling as you would zoom out camera in real life.
The other thing that I've just realised is possibility of drawing at small zoom level - that is on two or three screens and then zooming in - I suppose it should cut and recalculate it as a smaller part.
I would like to support devices at least from API 10 and not only high-end.
The question about time is the most crucial. I want everything to be as smooth as possible, so user wouldn't know that new canvas is being created each time.
I think it really depends on a number of things:
The complexity of this "infinite canvas": how "infinite" would it really be, what operations can be done on it, etc
The devices that you want to support
The amount of time/resource you wish to spend on it
If there are really not that many objects/commands to be drawn and you don't plan to support older/lower end phones, then you can get away with just draw everything. The gfx system would do the checking and only draws what would actually be shown, so you only waste some time to send commands pass JNI boundary to the gfx system and the associated rect check.
If you decided that you needs a more efficient method, you can store all the gfx objects' positions in 4 tree structures, so when you search the upper-left/upper-right/lower-left/lower-right "window" that the screen should show, it'll fast to find the gfx objects that intersects this window and then only draw those.
[Edit]
First of all thinking about infinity I was thinking about quite big
number of screens - at least 30 on zoom 1x in each side. I just need
to give my users bigger freedom in what they are doing.
If you just story the relative position of canvas objects, there's practically no limit on the size of your canvas, but may have to provide a button to take users to some point on canvas that they are familiar lest they got themselves lost.
When talking about scaling, there is another thing that has to be
concerned and connected with "infinity" of canvas. When user is
zooming out then screens, or more precise objects on the invisible
"neighbours" should appear with proper scaling as you would zoom out
camera in real life.
If you store canvas objects in a "virtual space", and using a "translation factor" to translate objects from virtual space to screen space then things like zoom-in/out would be quite trivial, something like
screenObj.left=obj.left*transFactor-offsetX;
screenObj.right=obj.right*transFactor-offsetX;
screenObj.top=obj.top*transFactor-offsetY;
screenObj.bottom=obj.bottom*transFactor-offsetY;
//draw screenObj
As an example here's a screenshot of my movie-booking app:
The lower window shows all the seats of a movie theater, and the upper window is a zoomed-in view of the same theater. They are implemented as two instances of the same SurfaceView class, besides user input handling, the only difference is that the upper one applies the above-mentioned "translation factor".
I assume that on all screens there will be maximum 500-800 rectangles
or circles.
It is actually not too bad. Reading your edit, I think a potentially bigger issue would be if an user adds a large number of objects to the same portion of your canvas. Then it wouldn't matter if you only draw the objects that are actually shown and nothing else - you'd still get bad FPS since the GPU's fill-rate is saturated.
So there are actually two potential sources of issues:
Too many draw commands (if drawing everything on canvas instead of just drawing visible ones)
Too many large objects in the same part of the screen (eats up GPU fill-rate)
The two issues requires very different strategy (1st one using tree structures to sort objects, 2nd one using dynamically generated Bitmap cache). Since how users use your app are likely to different than how you envisioned it to be, I would strongly recommend implementing the functions without the above optimizations, try to get as many people as possible to do testing, and then apply optimizations to each of the bottlenecks you encounter until the satisfactory performance is achieved.
[Edit 2]
Actually with just 500~800 objects, you can just calculate the position of all the objects, and then check to see if they are visible on screen, you don't even really need to use some fancy data structures like a tree with its own overheads.
I need to draw an array of lines in overlay. Currently, I use canvas and bitmap and draw about 500 lines. The drawing time is very high - around 200 ms which is bad, but acceptable.
Now I need to add 500 lines more and the time grows significantly. What is the fastest way to do this? Do I need to use OpenGL? and How? What is the best approach?
Turning off anti-aliasing will speed things up a lot. Be sure to profile your code to make sure rendering is the place where the time is actually going. Once you have optimized things and the majority of time is spent in rendering and you have made the rendering as simple as possible, the next step you'll have to take is to move to OpenGL.
I need some help with this simple animation on my Android phone. I'm a newbie with animation and graphics.
I'm graphing accelerometer data as a sliding time series window. As new accelerometer data is read, its data is plotted on the right, pushing previous data to the left, as shown below:
My program is running pretty smoothly, but I would like some help optimizing the animation. Here are my main concerns:
My current implementation reads all the accelerometer data in one thread and keeps the data in a fixed-size FIFO queue to capture the width of the time series window. I then use Timer.scheduleAtFixedRate() to plot out the entire contents of the queue so that the whole graph is re-drawn every 50 milliseconds. Can I improve upon this? Do I really need to re-draw the graph so often like this? In another similar program I've seen, each pixel column is copied to one pixel to the left, rippling down the graph; the newest data's column is drawn on the far-right pixel column. Is this better?
I redraw the legend (in the upper left) in the drawing thread that runs the draw function every 50 milliseconds. Is there any way to "keep" that legend in place instead of having to constantly re-draw it?
Any other help would be appreciated. I have heard of optimizations like double-buffering but am clueless if that would help me.
If the legend and the cross hairs only need to be drawn once, then you should place it into a buffer bitmap. For your graph line maybe try using the Path object to plot the lines. When it gets time to draw the lines just drawLine to the appropriate point and then translate the canvas left appropriately.If
I want to draw a graph that updates in real time (grows from the right). The most efficent way I can think of to do that would be to copy everything from x[0 .. width-2] left by 1 pixel, then draw the new value at x[width-1].
I have little experience with Android, but from what I can tell, Canvas doesn't operate on it's contents at all. Do I need to repaint the entire screen each time? This involves scaling and smoothing so I'm worried it will be slow.
Should I draw into a byte[][] then use this to paint to the screen (shifting the contents of my buffer left each time) ?
If your graph is bounded, try rendering all of it once to an Image, and then blit the relevant parts from that Image to your Canvas. Try to avoid actually "moving" pixels in the buffer, as that might introduce dependencies between your reads and writes and could really kill the performance. It might actually be better to copy from 1 buffer to another and alternate which one gets blitted to the screen. Finally, if you end up having to manually work on pixels, make sure you run on the image in lines rather than columns and that you start from the beginning of the line to help with the caching.
Regarding performance, without profiling we cannot say.
It may be that line drawing is hardware accelerated on your target phone, and you should draw the graph from scratch using line-drawing primitives each frame.
On the other hand, the straightforward pixel manipulation of an image buffer would be:
Create an image that is the right size and clear it to a "background_color". This image needs to have setpixel() functionality.
Have an array of values that record the y of each x time, so for any column you know where you last plotted your graph.
Treat this "chart_image" and "chart_array" as a circular buffer. For each time step:
Y = ...;
X = time_since_start % chart_width;
chart_image.setpixel(X,chart_array[X],background_color); // clear previous line
chart_array[X] = Y;
chart_image.setpixel(X,chart_array[X],foreground_color); // draw new plot
And now you need to blit it. You need to blit the image twice:
X = time_since_start % chart_width;
// the newest data is on the left of the chart_image but gets drawn on the right side of the output
blit(out_x+X,out_y, // destination coordinates
chart_image,
0,0, // top left of part of chart_image to blit
X,chart_height); // bottom right of chart_image part
// the oldest data is on the right of the chart_image but gets drawn on the left side of the output
blit(out_x,out_y,
chart_image,
X,0,
chart_width,chart_height);
Things get more tricky if you want to use lines rather than individual pixels, but a drawline() instead of a setpixel() can make that work with this approach too.
(Apologies for not knowing the Android APIs; but the approach is generic.)
Just a thought, which you may have considered already, but I wouldn't shift the contents of the buffer - I'd just try using it like a circular buffer. Keep an index to the current column and once you've wrapped around to the left-most column again you can draw to the destination in two segments - what is on the right side of the current column and then what is to the left, including the most recently filled column. This way you'll not have to shift anything around, and each screen refresh is just two blits (bitmap copies) for the two segments. If that bit's too slow you could still always paint those into a second off-screen buffer before blitting the whole thing to the screen in one go. Surely one large blit to the screen is fairly quick, no?
Since i can take as granted that you are storing the graph data in memory, redrawing it shouldn't be a problem. It's not intensive at all to redraw a set of points every frame. Shifting memory would be intensive, it's moving everything versus just painting only what you need.
Worst case scenario, since it's a function of time, only one value per column of the display, aprox 800 pixels/values in landscape that the system has to draw. It's trivial.
Have you profiled this?
EDIT: Remember, it's not that the system has to draw each point, it only draws on memory, then makes the use of it's primitives. Don't think like it iterates drawing the point, dumping to the video memory, then again.