New IColorAxis implementation - StopColorAxis

Feb 24, 2014 at 7:52 PM
I had a requirement for a different type of IColorAxis implementation that didn't currently exist.

The new IColorAxis implementation, named StopColorAxis, allows you to create a colour scale with specific colors at specific values (stops). Colours for values not at specific stops are interpolated from the nearest stops (upper and lower).

For example, suppose you have a StopColorAxis with a stop of Red (RGB[255, 0, 0]) at 0 and a stop of Green (RGB[0, 255, 0]) at 1. The colour returned for 0.5 would be halfway between red and green i.e. RGB[127, 127, 0]

This style of colour axis does not have a specific palette. Therefore the current IColorAxis interface methods (OxyColor GetColor(int paletteIndex) and int GetPaletteIndex(double value)) proved problematic. However, nearly all of the code base utilised the extension method OxyColor GetColor(double value) which has a signature more suited to my needs.

Therefore I modified IColorAxis to have a single method OxyColor GetColor(double value) and migrated all of the current implementations (leaving the extension method redundant).

The only issue I encountered was in ScatterSeries that utilised the original two methods of IColorAxis. In this case it was utilising the paletteIndex int as a key in a couple of dictionaries. As OxyColor is implemented as a struct and not a class it was trivial to change ScatterSeries to utilise the OxyColor as the key.

My question, is this the correct direction? You can view the modifications at my CodePlex fork on the StopColorAxis branch.

If this is the correct direction then I will add the appropriate examples and documentation before issuing a pull request.

Otherwise any suggestions to allow integration of an IColorAxis of this style would be appreciated.
Feb 25, 2014 at 10:17 AM
This sounds like a nice improvement! Could LinearGradientColorAxis be a better name? (cf.

I think the ScatterSeries try to improve performance by drawing all items with equal color together, but it could be a good idea to change this to a dictionary. Please test that performance is not significantly reduced. Then a change of IColorAxis as you suggest should be ok. I will have a look at the fork soon!
Feb 25, 2014 at 10:26 PM
LinearGradientColorAxis sounds okay to me.

I'll take a look at how the Render method in ScatterSeries operates more closely and perform some testing/profiling. I have a feeling that the current implementation is optimised for a reasonable sized palette. The proposed LinearGradientColorAxis essentially has an unlimited palette size (actually 32-bit assuming ARGB) which is less likely to get multiple points with the same colour.
Feb 27, 2014 at 7:38 PM
Good! Can you also add an issue on this before making the pull request. I would like all pull requests to be connected to an issue from now on.
I think the issue description should explain the difference between the current LinearColorAxis and the LinearGradientColorAxis.