Skip to content

much faster default tickFormatter() #50

merged 1 commit into from Jul 10, 2012

4 participants

klaemo commented Jun 27, 2012
@dnschnur dnschnur was assigned Jun 29, 2012
@dnschnur dnschnur merged commit e3c7a05 into flot:master Jul 10, 2012
@dnschnur dnschnur added a commit that referenced this pull request Jul 10, 2012
@dnschnur dnschnur Fixed mistake in code from pull request #50
- The faster toFixed alternative now returns a string, as tickFormatter
is expected to do

I'm curious... this pull request has both a performance benefit, and a behavioural side effect (as referenced in pull request #57 - issue 541).

Before: [0.0, 2.5, 5.0, 7.5, 10.0]
After: [0, 2.5, 5, 7.5, 10]

It seems like there is argument both to mirror precision if precision is detected, or ignore precision if a tick is an integer regardless of whether or not other ticks might have precision.

Perhaps there should be an option on the yaxis/xaxis to apply precision if detected? Also, would a better default be to mirror precision, or ignore precision on integers?


@sanakhet thanks to point me out there.

This is causing the issue number 732 that I reported on google code.

@dnschnur dnschnur added a commit to dnschnur/flot that referenced this pull request Nov 22, 2012
@dnschnur dnschnur Fixed axis.tickDecimals that were broken by #50.
Pull request #50 inadvertently broke the behavior of axis.tickDecimals,
which previously added precision up to the given value.  The broken code
effectively ignored the setting for values with less precision.  This
fix brings back the old behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.