On Sat, Jun 5, 2010 at 00:02, Rick <[email protected]> wrote: >>> I'm having a little bit of trouble with my axis labels. TAChart seems to >>> only want to display even numbers on the horizontal axis, for example. >>> Even when I use a custom source and set it to X values, it only shows >>> the even numbers. What am I missing? >>> >> >> I am not sure, seems to work for me. >> Can you post a project demonstrating the problem? >> > > Well since we're talking about it, let's take the line demo, for example. > The horizontal axis displays 0, 5, 10, ... What would I have to do to make > it display 0,1,2,3,4,5,6,7,8,9,10... ? > I've tried everything I can think of including giving the axis its own source > and changing the values, but it seems that something else is deciding what > numbers to actually print.
With linedemo: 1) Add TListChartSource component 2) Edit its DataPoints property, enter 1,2,...,10 on a separate lines 3) Set Marks.Source for bottom axis to that source 4) Set Marks.Style to smsXValue Of course, you can use UserDefinedSource instead for better efficiency. >> How many points per serie do you have? >> > Well this is what seems to make the difference. I have 10,240 points per > series. > I tried it with the line demo, as well. Throw a vertical line and drag tool > on the chart, then > drag the line around. Then click the button to add a bunch of series and try > dragging > the line. It starts to slow even at 1000 points per series, but panning and > dragging become > unacceptable at 10,000 points per series. (I just got your other email and > tried resizing the window. The slowdown is barely noticeable > at 1000pts per series, but quite obvious at 10,000 points) > > I did implement a user-defined series that manually retrieves the data and > draws the lines. > That works much better, but it's a lot wasted/duplicate effort. > It seems like data access might be at the heart of the issue, since the > problem scales with the > number of data points in the series. I wonder if a sorted data source that > does a binary search would be the ticket. On the one hand, that is ridiculously large dataset -- averaging more than five data points per x-axis pixel (!). On the other hand, you are not the first user who does this, so I guess there is some reason for such datatsets ;-) I have added simple time measurement to linedemo and performed some experiments. It turned out that the most expensive call is ACanvas.Line itself. Fortunately, I was able to transform drawing algorithm to split the series into a set of poly-lines, and then draw those. Unfortunately, it cost a lot of code complexity. The drawing time is reduced by approximately 3x. You can measure the speedup by comparing with 'Origin' line type, which does not benefit from that optimization. _Now_ the data access/transformation is indeed the most expensive operation remaining. I did another minor optimization to bypass transformation calls in trivial case, which gives another 10-15% speedup. Further optimization is possible by caching the poly-lines. However, the complexity will raise even further. So before we go there, please test the current version -- maybe it is already good enough? -- Alexander S. Klenin -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
