I use achartengine in a fragment with a view pager. It works great, but if I put a lot of value (100~200) into my series swiping is a bit slow. It's weird because, when I touch the page title, fragment changing is very fast, I only have this problem during slow swiping. How should I solve this?
Additional information:
- linechart with only one series
- y values from 0 to 100
- x values currentTimeInMillis
A solution we recently implemented is to save the view using the chart engine as a Bitmap and display the bitmap, only re-calculating the chart when values change.
Displaying a bitmap is much cheaper than displaying a chart, your swipe won't lag.
To do it, simply follow this thread.
Related
I am currently using MPAndroidChart to display real-time data. I have been able to add points to a line chart and update a radar chart with the data. However, I am having issues with implementing smooth animations when updating the charts.
So, for example, instead of just redrawing the line chart to include a new point of data, I would like the line to gradually extend to a new data point, sliding to the right if an old data point is being replaced (when outside of the visible axis range). And in the radar chart, if a point of data changes from, say, 20 to 60, I would like the point on the chart to smoothly move from the 20 to 60 instead of the chart being completely redrawn.
At the moment, I have found the animateX, animateY, and animateXY methods in the library. However, these only seem to be for initially creating the chart. I need there to be animations while data is continually added to an existing chart. Is it possible with this library? What kinds of tweaks would I need to make?
I have an android app that collects data and I need to graph that data. The dataset could be a few hundred samples, to tens of thousands. The X axis is time. The Y axis can have 1 to 15 different sets of data.
I've looked into some graphing libraries such as achartengine, but they all seem to expect that your graph will have a fairly compact dataset that fits nicely in a screen. With 20k samples, my graph will be much wider than it is tall. Actually I never really want the Y axis taller than the screen, the zoom should zoom only in the X axis.
My ideal interface is basically like a sideways listview that you can just fling left or right to scroll the really wide graph. Zoom will simply compress or expand the time scale.
In any case, my question is what are the best practices when trying to do something like this? I can find graphing tutorials, but nothing that addresses this problem specifically. It would seem very wasteful to try and render the whole graph at once. But I want the slide navigation to be smooth. Will drawing a screen at a time to the canvas be fast enough for a smooth scroll? Or will I have to go to openGL?
Thanks.
I hear users of AChartEngine mentioning that they add tens of thousands of data values in the model and AChartEngine still handles and displays them fine.
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 need your advice on the best way to implement a scrollable playing field in a simple game. The field consists of multiple rows, with 9 cells in each row. The rows can be dynamically added and removed during the course of the game. Each cell has a digit in it, and optionally several overlayed images, like selection, selector over, crossed out, etc. (see the pic below). The user should be able to click on individual cells of a row to select/deselect/cross the touched cells. At any point in the game there can be from 0 to 3000 cells (0 to about 333 rows). The field should scroll up and down smoothly.
I was thinking about having a ListView with its each row being a row on the field. That way i could add/remove rows dynamically during the game. However, how exactly should i implement a row: have one bitmap representing a row, and then when the user touches it -- get the coordinates of the touch area, and find out what cell was affected, and then act upon that. Is it possible to get the touch coordinates of a row in ListView? If not, should I place 9 dummy image placeholders in each row, and then act on user touching those? What about performance?
Or should I have one huge bitmap / canvas representing the entire field, place it inside a ScrollView and then calculate all the coordinates and update it as the user interacts with it? Is it going to be faster or slower than the ListView?
Any other solutions?
I prefer it to be a "regular" app type game, not a loop-based game, as I don't think I really need to redraw 30 times a second.
I am pretty new to Android. Thank you for your suggestions.
You can easily make that kind of setup run quickly with a "game loop" / SurfaceView combination. That means no ListView, only custom drawing and event handling. Luckily the event handling isn't that difficult, and you'll win later on because you'll have much greater control over the interface than if you had gone with a bunch of customized views and layouts.
I'd avoid that www.droidnova.com tutorial, it uses HashMaps unnecessarily, which will only cost you in performance.
Here's how I'd go about it:
Create an object to hold your cell data. For this example, I'd use an object with an id (to print), and an x and y for where to draw on the screen.
Decide on a board size which will fit on your screen without scrolling, say 10x10. You'll add the scrolling later.
Create a 2-dimensional array of cell objects with lengths boardSize x boardSize. Fill the objects with id and x and y position on the screen.
In your custom onDraw, iterate through each "row" and "column" of your single array and draw the object at its stored x and y value.
So now you've got a grid of objects displaying on your screen. Now you want to restrict the number of rows currently displayed and add some functionality to change which rows are visible. This is done as follows:
During initialization, set up some global ints as mCurrentRow = 0 and mNumVisibleRows = 3. These define your "view window".
Modify your drawing code to only draw rows starting at mCurrentRow and ending at mCurrentRow + mNumVisibleRows. The result of this should be that you only ever see mNumVisibleRows rows, and which group of rows you see depends on what you set mCurrentRow to.
Add some triangles to the right of your grid drawing and have tap touch events in those areas map to increments/decrements of mCurrentRow. Obviously, you should not allow that value to go outside your row count bounds.
If you want to get classy, draw a line between your triangles for a scroll area, and map touch events there to something like newCurrentRow = (touch.y / canvas.height()) * boardSize; That needs some tweaking, but you get the idea.
This approach has the downside of only showing a full set of rows at a time, so scrolling wouldn't be smooth. However, you have complete control over your canvas and what you draw, so with a little more math you could implement a smooth scrolling mechanism which would offset by a fractional row height in the y-direction instead of whole rows.
I dont know if you can create a game like you described with good performance. I would look into basic tile game programming.
But by avoiding the standard view components are have to write all the logic yourself requires quite some work. Things like handling "click" events on different rows needs to be calculated by the tile position relative to the game camera. So theres alot of new stuff in learning to develop game at a lower level.
You also have to take the rendering of your game into your own hands by developing a game loop that constantly updates and draw's your tiles from a background thread to reflect the scroll / state of your game.
You can get more infomation on the basics of a game loop at:
http://www.rbgrn.net/content/54-getting-started-android-game-development
If you want to learn more you should see the following keynotes from android.
http://developer.android.com/videos/index.html#v=U4Bk5rmIpic
http://developer.android.com/videos/index.html#v=7-62tRHLcHk
Those give you a very good insight in developing games for andriod at a low level where you can fine tune for performance.
I'm new to Android application development and I'm currently experimenting with various UI ideas. In the image below, you can see a vertically scrolling list of horizontally scrolling galleries (and also textviews as you can see). I'm also doing some matrix and camera transformations which I will come to in a minute.
For the background of the list elements, I use green. Blue is the background of the galleries, and red is the background for the images. These are just for my benefit of learning.
The galleries being used are extended classes where I overrode the drawChild method to perform a canvas scale operation in order for the image closest to the center (width) to be larger than the others.
The list view going vertically, I overrode the drawChild method and used the camera rotations from lack of depth dimension in the canvas functionality. The items in the list are scaled down and rotated relative to their position's proximity to the center (height).
I understood that scrolling and clicking would not necessarily follow along with the image transforms, but it appears as though the parent Gallery class's drawing is constrained to the original coordinates as well (see photo below).
I would love to hear any insight any of you have regarding how I can change the coordinates of the galleries in what is rendered via gallery scroll and the touch responsiveness of said gallery.
Images in the gallery are not same dimensions, so don't let that throw you in looking at the image below
Thanks in advance!
Ben
link to image (could not embed)
-- Update:
I was using my test application UI and noticed that when I got the UI to the point of the linked image and then I touched the top portion of the next row in the list, the gallery updated to display the proper representation. So, I added a call to clearFocus() in the drawChild method and that resulted in more accurate drawing. It does seem a tad slower, and since I'm on the Incredible, I'm worried it is a bloated solution.
In any event, I would still appreciate any thoughts you have regarding the best way to have the views display properly and how to translate the touch events in the gallery's new displayed area to its touchable coordinates so that scrolling on the actual images works when the gallery has moved.
Thanks!
As I updated earlier, the issue of the graphics of the gallery not fully refreshing was resolved by calling clearFocus in drawChild method for the ListView extending class.
The problem with registering the touch events turned out to be where I had used an example for the basis of my experimental program which called a pre-translation on the matrix used for painting. Once I removed that call and adjusted the post-translate call to compensate not having the pre-translate call any longer, I was able to scroll through the galleries regardless of their position, size or rotation (around x axis).