gmmoraesbr / flot

Automatically exported from code.google.com/p/flot
0 stars 0 forks source link

Very difficult to hover/click points when using axis transform #334

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
When using the axis.transform and inverseTransform to achieve a log axis,
it becomes very difficult to hover over points. 

see the attached html (edited basic example for a minimal case where this
happens). try to hover over any of the points. if you comment out the
transform, it works fine.

Original issue reported on code.google.com by ofri.ra...@gmail.com on 19 Apr 2010 at 4:28

Attachments:

GoogleCodeExporter commented 8 years ago
I ran into this too - I think it is because the log transform is lossy due to 
floating point math. If you use a transform function which is perfectly 
reversible (say, adding a fixed offset) then problem does not occur. 

Original comment by possi...@gmail.com on 24 Jun 2010 at 7:58

GoogleCodeExporter commented 8 years ago
I am experiencing this as well. The reason for it is not the lossy floating 
point math, though. The reason is that findNearbyItem() calculates the distance 
in terms of data points. You will notice that on a logarithmic scale the points 
on the lower end work fine, while the ones at the upper end are very hard to 
hover over.

The attached patch fixes the problem, by calculating the distance in terms of 
pixels. The only drawback of this is, that it makes the code in 
findNearbyItem() slower than before, because inverseTransform() needs to be 
applied repeatedly. 

I didn't have problems with performance, but if anyone is concerned about that 
it might be necessary to only apply inverseTransform() if it would actually 
make a difference - such as with a logarithmic scale, where different areas of 
the graph have a different 'density'.

Original comment by j...@uos.de on 2 Mar 2011 at 5:09

Attachments:

GoogleCodeExporter commented 8 years ago
Issue 467 has been merged into this issue.

Original comment by olau%iol...@gtempaccount.com on 10 Mar 2011 at 8:08

GoogleCodeExporter commented 8 years ago
Thanks for the patch - in fact, the bottom part of the algorithm actually was 
measuring pixels, it was just the optimization before that, the maxx/maxy stuff 
that was broken as you correctly identified. It turns out that without it, a 
plot of 14000 points gets a bit slow on my machine. So I've fixed it by just 
disabling the maxx/maxy optimization per axis so you only take the full hit if 
you change both.

A further optimization might be to precompute the inverse numbers and store 
them alongside the others or something like that. But in general, 
findNearbyItem isn't super clever, so I guess that can wait.

Again, thanks for reporting and commenting!

Original comment by olau%iol...@gtempaccount.com on 11 Mar 2011 at 9:55

GoogleCodeExporter commented 8 years ago
Thanks.

Original comment by tom.pa...@gmail.com on 12 Mar 2011 at 1:29