XYChart works slow with huge amount of data

[GoogleCodeExporter]

You need to replace ArrayList<Double> in XYSeries.java on TreeMap<Double, 
Double> and do every consequent action. 

The only visible part of chart should be drawn. Now it paints all the chart, no 
matter if you can only see 5% of the chart by zooming.

I replaced array lists by maps. Before it started to work slow after 2000 
points. Now no matter how many points there are there, it works as same as in 
the beginning. Here's the code http://pastebin.com/JHnaLUsB

it's not perfect, but you can get the main idea.

Original issue reported on code.google.com by alexande...@gmail.com on 31 Jan 2011 at 9:09

[GoogleCodeExporter]

pay attention on lines 33 and 358, those are places i replaced

Original comment by alexande...@gmail.com on 31 Jan 2011 at 9:12

[GoogleCodeExporter]

btw, good library thanks for it :) I'm gonna use it in my program. Just correct 
it a bit :)

Original comment by alexande...@gmail.com on 31 Jan 2011 at 9:12

[GoogleCodeExporter]

You can eventually send me some code patches.

Original comment by dandrome...@gmail.com on 3 Feb 2011 at 12:34

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

i'll send you the patches soon. I can't give you well tested code due to lack 
of time, but the main improvement will be there, so you will be able just to 
correct it a bit.
Now i'm using the library with Maps instead of Arrays. It works very fast 
displaying graphs of three accelerometer axises, even when the number of points 
reaches 100 000 for each axis.

Original comment by alexande...@gmail.com on 3 Feb 2011 at 12:47

[GoogleCodeExporter]

I've just downloaded the fresh version from repository and fixed 
XYChart.java
XYSeries.java

There are those files and diffs in attachment. When you apply those patches two 
errors occur in BarChart and RangeBarChart since there is no more method 
series.getY.
I didn't fix them as I don't know the library internals so well. For you it 
will not take a lot of time.

The library is really good so i think it should switch to Maps instes of Lists 
as Maps are much faster with huge amount of data. If you have some questions 
about application of these fixes, feel free to contact me (sky___pe  
alexander.ponomarev.0 )

Original comment by alexande...@gmail.com on 12 Mar 2011 at 9:37

Attachments:

• XYSeries.diff.zip

[GoogleCodeExporter]

Does anyone have an update on this issue? I'm considering repeating this same 
work, unfortunately, and I'm not excited to re-invent a wheel if someone has 
one they like to share :)

Original comment by candrews...@gmail.com on 16 Jun 2011 at 7:56

[GoogleCodeExporter]

I can share my version of the library with you, it's 2 moths old though. 

Original comment by alexande...@gmail.com on 19 Jun 2011 at 3:25

Attachments:

• achartengine-read-only.zip

[GoogleCodeExporter]

If there is anyone that managed to apply this change, can you please provide an 
up to date patch?

Original comment by dandrome...@gmail.com on 27 Jul 2011 at 3:59

[GoogleCodeExporter]

I sent you diffs and the source before, sorry now I just have no time 
completely to make a fresh patch. Just replace your lists with maps and it 
starts work really fast with any amount of data: millions of points.

Original comment by alexande...@gmail.com on 28 Jul 2011 at 12:07

[GoogleCodeExporter]

Anyone have this merged?  I did a cursory review, and the code looks 
substantially changed since alex put together the diff...

This would be really useful -- my XY chart is slow as well.

Original comment by matth...@gmail.com on 27 Sep 2011 at 9:18

[GoogleCodeExporter]

Hello, I have just fixed this problem. I will send patch files to Dan during 
this weekend. The performance is now perfect :)

Original comment by stevo....@gmail.com on 30 Sep 2011 at 2:51

[GoogleCodeExporter]

I wish I could buy you a beer, stevo.  Looking forward to this patch!

Original comment by matth...@gmail.com on 30 Sep 2011 at 3:00

[GoogleCodeExporter]

Well, its working for almost all charts now, i just have to fix the last one. I 
hope i will patch it soon.

Original comment by stevo....@gmail.com on 3 Oct 2011 at 7:13

[GoogleCodeExporter]

So, I found the problem. The range chart put 2 points with the same x value 
into the rangeSeries. So it is not possible to use Map with it. 

I don't use range chart in my project at all and all the other charts works 
fine and fast. So i can send you changed library if you want to.

Original comment by stevo....@gmail.com on 6 Oct 2011 at 10:27

[GoogleCodeExporter]

Sweet.  I just use a bunch of different XYSeries in my project.  That is not 
rangeSeries, correct?  Users slide the graph view to the left or right and it 
gets real stuttery.

Original comment by matth...@gmail.com on 6 Oct 2011 at 2:09

[GoogleCodeExporter]

I'm looking at this today - I'm basically pumping data into the graph in 
realtime and rerendering each time. When the chart has to display 3-4 series of 
2000-3000 points, the renders are taking forever and getting super choppy.

If i can help find a working solution to the map issue, let me know.

Original comment by Matthew....@gmail.com on 7 Oct 2011 at 3:20

[GoogleCodeExporter]

Ok so this is my modification of the library.
It is very fast now because it renders only the points which are visible on the 
screen. 
This modification works great if you put your data to the x axis on the regular 
interval.

It means it works great for example for these x axis values 
- 1,2,3,4,5,7,8,10 or 
-0.2, 0.5, 0.6, 0.9 or 
-100, 200, 320, 400, 510

But it is not so good for values like this 
-1,2, 100, 102, 1000

So simply, if you put data with approximately same X interval this modification 
is for you.

Original comment by stevo....@gmail.com on 8 Oct 2011 at 8:52

Attachments:

• fast-achartengine.zip

[GoogleCodeExporter]

The second modification works bit slower then the first one, but it doesn't 
depend on the x-axis interval.

The reason for these two modifications is that NavigableMap which would be 
great to use is available since android API 9.

Enjoy :)

Original comment by stevo....@gmail.com on 8 Oct 2011 at 9:05

Attachments:

• fast-achartengine.zip

[GoogleCodeExporter]

I don't think Dan is going to check in a commented block of code followed by 
'holllllaaa'  :)

Original comment by Matthew....@gmail.com on 10 Oct 2011 at 2:02

[GoogleCodeExporter]

:)) i couldn't find this file ... because i have 100 different copies of 
aChartEngine, so this was my mark (but i eventually forgot to remove it, sorry)

Original comment by stevo....@gmail.com on 10 Oct 2011 at 2:30

[GoogleCodeExporter]

Hi.

I tried to use fast-achartengine but if I  pul like 16k of data into TimeChart 

Intent intent = 
ChartFactory.getTimeChartIntent(context,buildDateDataset(titles, x, values), 
renderer,"H:mm:ss");

It doesn't launch the intent... If there are smaller values then it does....

Any suggestions?

Thanks, Toni

Original comment by toniabc@gmail.com on 25 Oct 2011 at 4:33

[GoogleCodeExporter]

Sorry, I didn't test all chart types. Actually i don't use TimeChart, i use 
LineChart which works very fast even with 100k data. 

Original comment by stevo....@gmail.com on 25 Oct 2011 at 5:50

[GoogleCodeExporter]

Does anybody have a clue how to implement maptree to timechart?

Thank you

Original comment by toniabc@gmail.com on 9 Nov 2011 at 8:48

[GoogleCodeExporter]

Hi,
   i am drawing timechart with 10K data but it takes 10-15 seconds to draw chart so how  i can make it fast?

Original comment by Sawan.Da...@alphabricks.com on 24 Nov 2011 at 6:30

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here is a patch against trunk for the changes in comment #18.

Original comment by timpam...@gmail.com on 27 Nov 2011 at 9:27

Attachments:

• fast-achartengine.patch

[GoogleCodeExporter]

SVN rev. r317 includes the patch.
It is a great work, but please note that it breaks the range bar chart. If 
someone gets a chance to take a look and fix it, please do.

Original comment by dandrome...@gmail.com on 10 Dec 2011 at 2:12

[GoogleCodeExporter]

Original comment by dandrome...@gmail.com on 10 Dec 2011 at 2:12

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Good work but there are now issues with clickable areas. If you pan your XY 
chart and click on a point on the graph, then the value for this point is not 
the correct one.

See: public SeriesSelection getSeriesAndPointForScreenCoordinate(final Point 
screenPoint) and more specifically pointIndex

Original comment by d4rxh...@gmail.com on 23 Dec 2011 at 2:50

[GoogleCodeExporter]

Well, this is one of the reasons why I did't make the patch.
Using maps instead of Lists changed a logic little bit. 

The problem is that with maps you have always indexes from zero to max screen 
value. 
Even if you pan your chart and you see lets say values from 10 .. 20, the 
indexes are still 0 .. 10.

I have hacked that by holding the leftmost value and i add selected index to 
it. So in the above case with values 10 .. 20 i add 10 to selected index. So if 
I clicked lets say on 13 column, i get index 3 but i add 10 and 10 + 3 = 13.

Original comment by stevo....@gmail.com on 23 Dec 2011 at 3:20

[GoogleCodeExporter]

I think we should fix these issues. Otherwise I will have to drop all these 
changes and return to the old Lists that may be slow, but don't bring so many 
issues.

Original comment by 4viewsoft@gmail.com on 26 Dec 2011 at 2:15

[GoogleCodeExporter]

IMHO there is a simple way to solve this. Instead of using mDataset in 
getSeriesAndPointForScreenCoordinate method to retrieve series value of each 
clickableArea, it is  simplier to retrieve these values directly from these 
clickableAreas. 'clickableAreas' must therefore hold values by changing Rect[] 
with ClickableArea[] (where ClickableArea is a private class holding Rect and 
x/y values). Here's a patch.

Original comment by d4rxh...@gmail.com on 28 Dec 2011 at 9:57

[GoogleCodeExporter]

Original comment by d4rxh...@gmail.com on 28 Dec 2011 at 10:09

Attachments:

• clickable_areas.patch

[GoogleCodeExporter]

I included the patch, but it was not fun. The patch was for rev. 183 and we are 
now at 324.

Original comment by dandrome...@gmail.com on 4 Jan 2012 at 8:27

[GoogleCodeExporter]

Now there is still the issue with the range bar chart before we can declare 
victory on this.

Original comment by dandrome...@gmail.com on 4 Jan 2012 at 8:28

[GoogleCodeExporter]

Thanks for including my patch. And sorry for the revision mess, it was of 
course unintended.

Original comment by d4rxh...@gmail.com on 5 Jan 2012 at 2:10

[GoogleCodeExporter]

Did several fixes here, so we can declare victory on this one.
Hopefully the community will benefit after this collective effort.

Original comment by dandrome...@gmail.com on 5 Jan 2012 at 8:27

• Changed state: Fixed