search

piaoyongren / core-plot

Automatically exported from code.google.com/p/core-plot
0 stars 0 forks source link

Issue (possibly bug) when CPAxisLabelingPolicyAutomatic is specified #148

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
There's an issue with positioning minorTicks when specifying 
CPAxisLabelingPolicyAutomatic for 
the axis. See attached screen shot.

On the Y axis, minor Ticks appear shifted upwards by the size of the 
majorTicksLength. The axis 
policy is Automatic, there are 3 minor ticks per interval in this case.

Thanks,

Joan

Original issue reported on code.google.com by carbon...@gmail.com on 29 May 2010 at 3:23

Attachments:

GoogleCodeExporter commented 8 years ago 
Just to compliment my last post. The issue can also be seen in the CPTestApp 
app. You will see it if you drag the 
graph upwards to make the gridlines and minor ticks show (well, not actually) 
in the lower part of the Y axis.

Thanks,

Joan

Original comment by carbon...@gmail.com on 29 May 2010 at 3:35

GoogleCodeExporter commented 8 years ago 
It's not a duplicate, but this might be related to issue #124.

Original comment by eskr...@mac.com on 29 May 2010 at 5:15

GoogleCodeExporter commented 8 years ago 
Hi, 

I believe issue #124 as it is described must be exactly the same as this one. 
With no padding on the 
plotAreaFrame (the default) the bug just shows as some missing gridlines as 
described in #124. However, if you 
set paddings then you'll see that the actual problem is a misalignment of the 
gridlines and that the missing ones 
are just drawn above or right (depending on the axis) of the plot area.

Original comment by carbon...@gmail.com on 30 May 2010 at 8:04

GoogleCodeExporter commented 8 years ago 
The attached changes in CPAxis.m should solve the issue.

Joan.

Original comment by carbon...@gmail.com on 1 Jun 2010 at 6:44

GoogleCodeExporter commented 8 years ago 
I pushed this change in f705dbf9a858
It seems to fix this particular issue, but there are still issues with grid 
lines. Perhaps you can take a look, given 
you are already working in this code.

I'm attaching a screenshot which seems to show an extra major grid line in 
CPTestApp, as well as missing minor 
ticks and grid lines at the top of the y range.

Original comment by drewmcco...@mac.com on 1 Jun 2010 at 8:16

Attachments:

GoogleCodeExporter commented 8 years ago 
Joan, can you email me off list? I want to ask you something.

Original comment by drewmcco...@mac.com on 1 Jun 2010 at 8:25

GoogleCodeExporter commented 8 years ago 
I pushed a change to CPAxis.m in the Performance branch that should solve all 
the issues. I basically took a slightly different approach to 
autoGenerateMajorTickLocations, which should properly deal with all the edge 
conditions. I left the previous method commented out in the file, just for 
reference.

Joan

Original comment by carbon...@gmail.com on 9 Jun 2010 at 6:49

GoogleCodeExporter commented 8 years ago

Original comment by eskr...@mac.com on 18 Jul 2010 at 2:41

GoogleCodeExporter commented 8 years ago 
I believe the very last change causes a memory leak. We should release 'range' 
somewhere after copying it.

Other than that, I think it is not mentioned elsewhere that the original fix 
that I introduced in the performance branch did not support NSDecimal accuracy, 
which is the reason why it stayed there for a while. This is also true for the 
fix now in the default branch, so just wanted to let users know that the issues 
are solved but they must be aware that the implementation is with doubles, not 
NSDecimals.

So if you need full NSDecimal accuracy do not use CPAxisLabelingPolicyAutomatic.

Joan.

Original comment by supp...@sweetwilliamsl.com on 18 Jul 2010 at 8:58

GoogleCodeExporter commented 8 years ago 
The memory leak is now fixed.

I'm not sure there's any way around the part that uses the power and log 
functions. We could refactor it to call the fixed interval method once the new 
limits are determined.

Eric

Original comment by eskr...@mac.com on 18 Jul 2010 at 9:52

GoogleCodeExporter commented 8 years ago 
It's some time since I proposed that change, so I would have to check it again, 
but I believe that we may be can find a wise combination of doubles and 
NSDecimals in the implementation that could prevent any precision loss on the 
result. I will think on it when I have some time.

Also, some time ago I thought that it would be a nice addition to the library 
to have a way to make it use either NSDecimals or doubles as a whole, and a way 
to make it switchable at compile time.

I still think that this would be nice because NSDecimals are really slow on the 
iPhone and iPod touch. With the last additions to the performance branch, which 
prevent a lot of unnecessary rendering, performance has been improved by a very 
noticeable amount (specially on a iPod touch). There is possibly still 
something more to do, (for example tweaking how clipping is implemented) before 
going down to NSDecimals, but after that, NSDecimals and NSDecimalNumbers will 
be the next thing to look at if we want to make it even faster, for example to 
use the library for real real-time data monitoring. Unfortunately I am very 
busy these days, but I will come out with something sometime in the future.

Joan

Original comment by carbon...@gmail.com on 19 Jul 2010 at 8:28