Sounds interesting! I'm a bit busy these days, but I'll try to take a closer look tomorrow.

I think I like this change!
While #24 is labeled as a bug, I'd be inclined to consider this more as an enhancement rather than a bug fix, so I don't think we'd need to backport this to v2.1. Especially if we are considering making MinimumMajorIntervalCount=2 by default (which I think would be a sensible idea).

Some other thoughts:

• Could MaximumMajorIntervalCount get another name that conveys its 'not-hard-maximum' nature? Something like DesiredMaximumIntervalCount, though that is quite a mouthful...
• One issue I found while playing around: With very short axes, something like this can happen:
  (Axis Examples > Tick Style = Outside, MinimumMajorIntervalCount=2, window dragged very small):
  
  Mind you, this is still better than MinimumMajorIntervalCount=0, which shows just the tick 100. But I think it would be more sensible to display only major ticks 50 and 100 here. On some zoom/pan levels this is the case, but for others we get more ticks than necessary I think (like in this example).

I like the symmetry in the names at the moment, but prefixing Desired would probably be a clearer.

I can't repro the small-axis issue: can you provide the exact code you were using? I agree what you describe would be better and is what I see when I set the min and leave the max free:

It would be nice to add this as a non-breaking change now and change the defaults later, but I in terms of wanting to get 2.1 out the door, I think you are right and we should hold off adding more complexity.

I can't repro the small-axis issue: can you provide the exact code you were using?

For me it happens every time when I

• open the example mentioned above
• drag the window small (the exact size doesn't matter)
• zoom in once with the mouse wheel
• pan the axis such that both 50 and 100 should be in range

Let me know if you can reproduce it this way, if not I'll try and come up with some code that reproduces it.

Ah, yeah, I remember this now (can repro also). I thought I'd addressed, but I can't think how, so I guess I didn't.

It's caused by the range changing slightly when panning: if the range is 100, then when it considers an interval of 50 it projects the number of ticks as being 100/50=2, and it is happy with that. But when you pan, the range can end up slightly either side of 100, and if it goes below 100, it rejects an interval of 50 (because for a range of <100, it is possible there could be only 1 tick depending on the offset).

This is an unsolvable problem in the sense that there will always be a range where it could go either way. We could ask GetTickValues to determine the actual number of ticks, but that make the behaviour more 'bouncy', as the number of ticks depends heavily on the offset.

I'm tempted to say we should merge this. The range issue is still there, but even the new behaviour is arguably better than the old behaviour (a single tick is completely useless), and we may have a better idea about how to handle edge cases if we see it working in reality.

Agree this can be merged. Even though this one particular point could be improved in the future, this is definitely an improvement to the current behavior.

I'll not merge right away, I don't really have an overview over other open PRs this might interfere with. I'll try and catch up with the PRs in the coming days, but feel free to merge yourself!