I am working on allowing multiple axes in TAChart (issue 0013832). I am working with the idea to have multiple x and multiple y axes for line series.

At this moment the axes do not have minimum and maximum values (I've submitted issue 0015371). As far as I know, the minimum and maximum values moved to the chart (extent) recently. The axes have an offset and scale. The offset and scale however are quite difficult to use.

To allow multiple axes, a line series should know to which axes (vertical and horizontal) it must be drawn. The axis is then reponsible for scaling a point allong its length. However, only the chart knows how big the chart is on the screen and thus must be responsible for scaling the point to the screen. So, the axis must know its minimum and maximum values to allow scaling. The output of a scaling function in the axis would be a value betwen 0 and 1, which would be the input for the scaling function of the chart.

I don't know the impact of the above on the working of TAChart. Does it have impact on other chart types, etc? When reasoning, I think it would only have impact on vertical scaling of bar series and on the horizontal and vertical scaling of line series. Before I continue solving my own issues, I would like to know if I am on the right track. Why did the minimum and maximum values move from the axis to the chart? Are my ideas correct and should the scaling be distributed between axis and chart? Do we seek compatibility with the Delphi chart component? How would that compatibiltiy be guaranteed?

Regards,
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20091217/c03c6eed/attachment.html>

2009/12/18 Albert Zuurbier :

I am working on allowing multiple axes in TAChart (issue 0013832). I am working with the idea to have multiple x and multiple y axes for line series.

Sorry for the delay in my response -- the time I can spend on Lazarus is very limited lately.
Still, I have finally made some progress on the issue, although much is still left to be done.

As I said on the forum, first the source-element-to-graph-point translation must be abstracted out.
This is done in r23207 and r23211.

Then, the transformation itself should be introduced. This is relatively large change, done in r23214, r23217 and r23241. (BTW, thanks for fixing my stupid thinko, Paul).

It also includes (optional) binding of series to axes, although in a manner different from your patch.
(In the future, please post patches as unified diffs in the future. Simple diffs are rather hard to read.)

At this moment the axes do not have minimum and maximum values (I've submitted issue 0015371). As far as I know, the minimum and maximum values moved to the chart (extent) recently. The axes have an offset and scale. The offset and scale however are quite difficult to use.

It is not hard to simply create Min and Max properties instead of Scale and Offset,
but I do not think using them is really easier.
Calculating said properties automatically is indeed a good thing for some applications, but not for others.
Also do not forget e.g. logarithmic scale, which is often requested by users, (it is already implemented in r23217, but the implementation will likely change).

The solution is to create multiple Transformation types -- first step in that direction is
already done by extracting Transformation into a separate class. The second step, however, has met a roadblock
Currently, ObjectInspector seems to display only fields from the base class for class property even if it is actually assigned an object of some descendant class.
(As opposed to component editor, whose properties are changed dynamically).

So, I have a few choices:
1) Punt, and stuff everything into one giant Transformation class. Good: Trivial to implement.
Bad: Ugly and inefficient.
2) Implement each Transformation as a separate component, similar to ChartSources.
Good: Rather simple to implement, clean design.
Transformations may be shared among several axises and even charts. Bad: Component palette and form designer pollution. Slightly harder for novice to find.
Some transformations (like those auto-scaling ones you proposed) should not be shared, and sharing them may lead to non-obvious bugs.
3) Implement each Transformation as a separate class, with the custom property editor.
Good: Clean and efficient. May have intuitive interface, if designed properly. Bad: Hardest to implement (but the problem is in the editor, not in Transformation itself).
Transformations may not be shared among several axises.

For the meantime, I did (1) get something working fast. My preferred solution is (3), but that will take a while to implement properly.

So if anyone has other ideas, arguments for/against the choices above, or, better yet, property editor patches -- please share ;-)

Are my ideas correct and should the scaling be distributed between axis and chart?

Yes, it should, since not all scaling is linear.

Do we seek compatibility with the Delphi chart component?

No, we do not, except at "vaguely similar" level.
It is still a good thing to check Delphi implementation for overall concepts.