Fixes sharp edges on the line chart #3764

stokatyan · 2018-12-01T01:44:43Z

Issue Link 🔗

Goals ⚽

This fixes the sharpness to some of the connected data points for the line charts.

Implementation Details 🚧

When a line is drawn, vertices need to be extended to account for sharp angles, to avoid the long vertices the app needs to draw each line 1 at a time (the way it already does for line charts with more than 1 color for their lines).

Note that existing users may have to update their line cap type to rounded because when each line is drawn 1 at a time there can be very small open space between connected lines (this already exists for line charts with more than 1 color)

Testing Details 🔍

-----Before-----

-----After-----

…for the data set

liuxuan30 · 2018-12-04T02:10:49Z

wow thanks for solving the old issue. the change is much bigger than I thought.
We need to spend time to review this.. please allow us to take a longer time than you could think.

and, could you explain a little more? I'm confused why you said it's about the number of colors ?

stokatyan · 2018-12-05T17:43:19Z

At the actual drawing level, the sharp edges are caused because there is only one line connecting the points. Charts uses only one line when there is only one color, and that causes the sharp edges.

The reason for sharp edges when there is one line is because the line is completely connected at every point, and has the same width at every point. That makes sense for line segments and smooth (differentiable) curves. However, you can’t really make sense of the width of a line at a vertex.

The picture attached shows what is going on. The red lines are line segments, and the gray lines are continuous (not differentiable / not smooth) lines.

Line 1(c) uses 2 line segments with a rounded line cap to make it look like the lines are connected.

anton-filimonov · 2018-12-08T18:53:00Z

@stokatyan @liuxuan30 seems like absolutely the same result could be reached by just calling context.setLineJoin(.round) and it seems to be less tricky. Another solution could be to set line join to .bevel, or set miterLimit to less then circleRadius/lineWidth. Actually, I suppose the best way to solve this is to provide some more properties to users to control these values (I mean add lineJoin and miterLimit properties to LineChartDataSet).
P.S.: Can make pull request with this solution if you agree with me.

stokatyan · 2018-12-10T18:37:48Z

@anton-filimonov I think that is a good suggestion. Although, I think we should make that a separate PR and still get this one merged.

The reason I would like that change to be a separate PR is because it will change functionality for existing users (having to consider how lines are joined). The current PR didn't introduce any tricks, it just treats lines with one color the same way it was already treating lines with two colors.

liuxuan30 · 2018-12-11T01:35:09Z

@stokatyan so this PR implement like what 1(b), 2(b), and 1(c) did? My understanding is you use round line cap so 1(b) and 2(b) become 1(c)?

liuxuan30 · 2018-12-11T01:35:55Z

@petester42 @jjatie I would like to add this PR in next release soon. But Need your help to review this. This is a big change. Do you have time to do it?

liuxuan30 · 2018-12-11T01:41:47Z

@anton-filimonov are you saying your approach could solve the same issue as this PR did?
@stokatyan If it's true, I might consider not to merge this, as we only need one neat solution. If we merged this and later @anton-filimonov add more control and solve the same issue simultaneously, it's over kill then.

anton-filimonov · 2018-12-11T07:02:16Z

@stokatyan you are right that this PR does not introduce any new tricks. My english is not good enough so probably I used incorrect sentences. I'm sorry if so. I think that the way the renderer handles case with multiple colors is tricky. Unfortunately this looks good only when lineCap is set to .round. For example, it looks like this for lineCap == .butt:

That's why I don't think that it's a good idea to use that same trick also for case with one color.
If we want to fix this concrete issue without adding changes for users - we can just set lineJoin to .round but probably not all the users will like this. What if there are people, who like current behaviour. We also have an option to add new properties and set default value for them to .miter because this way those people, for whom current behaviour is ok will not feel the difference, and those who want to change it - can do it with new properties

anton-filimonov · 2018-12-11T07:09:09Z

@liuxuan30 Yes, such approach could fix the same issue by letting the user to decide how the line joins should be drawn. But this change will work only for one-color line.

jjatie · 2018-12-11T09:53:27Z

@lixuan30 I’ll take a look today or tomorrow

jjatie

I like the change; it never made sense to me to calculate the line in two different ways. My only question is how does this impact performance? My understanding is that we had a potential performance problem with drawing only one path at steep vertices (Overlapping lines in a single path are more difficult to compute which could happen at the vertices depending on the stroke width). This potential performance hit is now gone.

My only requested change is to implement a performance test to measure see if there is a meaningful difference between the two calculations.

stokatyan · 2018-12-11T18:59:20Z

@stokatyan so this PR implement like what 1(b), 2(b), and 1(c) did? My understanding is you use round line cap so 1(b) and 2(b) become 1(c)?

1(b) becomes 1(c), and 2(b) would behave similar to 1(c), but would have a different path.

@anton-filimonov @jjatie Got it, I will add the default lineCap parameter and include a performance test when I get a chance. If I can't get it done during the week I should be able to make the updates over the weekend.

Update: I didn't get a chance the past weekend, will try for this coming weekend.

anton-filimonov · 2018-12-24T02:51:47Z

@jjatie added another PR for this issue. It uses Core Graphics lineJoin parameter to solve the issue that's why to me it seems to be more natural. But that PR is exclusive with this one because this PR leaves no more line joins for single color line (for multicolor line this already is an issue as I showed in previous comments)

jjatie · 2018-12-25T04:16:44Z

I disagree with #3797. It adds surface area to the API that doesn't completely solve the issue.

This PR unifies the drawing logic for single/multi-colour lines. Fixing the line cap to .round provides the only reasonable line to expect and resolves the issue. Assuming there is no meaningful performance hit in large data sets, this is definitely the preferred option.

anton-filimonov · 2018-12-25T05:29:55Z

@jjatie well, I have some reasons "pro":

Since library is based on Core Graphics seems to be good and pretty much natural to give user the ability to set as much properties provided by Core Graphics for line as possible. So there are already line width, line color, line cap, line dash pattern and phase. And additional line join and miter limit seem to be good addition to this set. But fixing line cap to .round on the other hand would reduce this flexibility.
Yes this option will not work for multicolored line but actually line with more than one color works only for .linear and .stepped mode and also since there's no such functionality for line drawing in Core Graphics, seems like there's more than one way to implement this feature and depending on the concrete user the way that feels 'natural' would differ. For example to me the more 'natural' way to implement many colors would be similar to how recently added gradient line works, i.e. clip to path outline and then draw rectangles of corresponding colors. So seems like multicolored line looks much more like the feature to be implemented by user himself the way that is good for him and imho trying to clean up the renderer it's better to remove part drawing multicolored line and maybe give some options on drawing many colors
I bet it's better not to change the default behaviour because for some users it could be pretty much correct

liuxuan30 · 2019-01-22T01:35:29Z

any update on this? @stokatyan
I'm checking if we can merge this within this week or early next week

stokatyan · 2019-01-24T02:43:38Z

@liuxuan30 I'm not sure what else is needed for this PR. I don't see any existing performance tests to reference for the test that @jjatie is requesting. If you want a performance test please be more specific about what is tested and what should be defined as a pass or fail.

I agree with jjatie regarding @anton-filimonov suggestions, so this PR looks done to me.

liuxuan30 · 2019-01-28T01:52:27Z

not sure why but this had a conflict now. please have a look

liuxuan30 · 2019-01-28T01:55:29Z

@jjatie

My only requested change is to implement a performance test to measure see if there is a meaningful difference between the two calculations.

Can you add the details for what @stokatyan asked?

codecov-io · 2019-01-30T02:59:05Z

Codecov Report

Merging #3764 into master will increase coverage by 0.1%.
The diff coverage is 85.29%.

@@            Coverage Diff            @@
##           master    #3764     +/-   ##
=========================================
+ Coverage   32.71%   32.81%   +0.1%     
=========================================
  Files         114      114             
  Lines       10775    10723     -52     
=========================================
- Hits         3525     3519      -6     
+ Misses       7250     7204     -46

Impacted Files	Coverage Δ
Source/Charts/Renderers/LineChartRenderer.swift	`65.72% <85.29%> (+4.07%)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d38438...55a9cc8. Read the comment docs.

stokatyan · 2019-02-06T17:38:14Z

@liuxuan30 @jjatie is there anything left to do for this PR?

liuxuan30 · 2019-02-08T01:45:40Z

I have none. @jjatie

jjatie · 2019-02-08T09:14:17Z

None

@IBOutlet

* Added delegate callback to detect when panning is finished, to potentially allow users to manually reset the hightlight values once panning is complete * Changed the part of the code where the delegate gets called * Make NSUIAccessibilityElement initializer public. * Add Parameters Section ``` (\n[ ]+)(((/// - parameter \w+:.*\s+)(///((\s+)|( \s+.+\s+)))?)*/// - parameter \w+:.*) ``` ``` $1/// - Parameters:$1$2 ``` * Remove parameter prefix ``` /// - parameter (\w+):(.*)(\s+///(\n))*(\s+) ``` ``` /// - $1:$2$4$5 ``` * Remove property’s `returns` section ``` /// - returns: (.+\s+((override|@IBOutlet|@objc|weak|unowned|lazy|static|class|open|public|private|fileprivate|internal)($set$)? )*(var|let)) ``` ``` /// $1 ``` * Add missing `-` ``` /// (note|return|parameters|throws): ``` ``` /// - $1: ``` * Sort sections ``` ((///)[ ]+[^-\n]+(\s+))?(((((/// - Parameters:\s+(/// (( - \w+:)|([^-]{1})).*\s+)+)\s+)|(/// - Returns:.*\s+(/// [^-]{1}.*\s+)*)|(/// - Note:.*\s+(/// [^-]{1}.*\s+)*)|(/// - Throws:.*\s+(/// [^-]{1}.*\s+)*))(///\n\s+)?)+) ``` ``` $1$2$3$15$7$17$13 ``` * Uppercased the section title * fix function groupBars document error * Remove duplicated section * Update ChartViewBase.swift Updated documentation in the code based on feedback * Add missing empty line between Summary and other section manually * fix wrong assignment to axisMaxLabels property * Remove meaningless comment * improvements in barRect height calculation (ChartsOrg#3650) * fixed barRectCaculation * fixed offset calculation * Fix the mess caused by the setting the min&min value of the y-axis by error : Just simply swap their values * Fix the mess caused by the setting the min&min value of the y-axis by error * Revert "Fix the mess caused by the setting the min&min value of the y-axis by error" This reverts commit 526a73a. * Fix the mess caused by the setting the min&min value of the y-axis by error * update offset calculation * update code style * update code style * update offset calculation * keep barRect calculation untouched try to simply the calculation. keep barRect calculation untouched * After the correction of min and max , they should be assigned back to _axisMinimum and _axisMaximum * add demo for bar chart unit test * update unit test * revert last commit * update unit test * make sure max is greater than min & turnoff record mode for barchartest * add new UT and fix some issues. 1. add more bar chart UT 2. code style fix 3. manually add chart.notifyDataSetChanged() - some old UT and new ones forget to call this method, leading the test images to be wrong. Notice: some test images diff shows slight pixel shift, not sure why, but both old and new image seems drawing correctly * update tvOS images * update tolerance to 1% & more swift-y * update tvOS images, removing "Description Label", (not rendered anymore) changing tolerance will trigger "Description Label" detection * update iOS test images, "Description Label" no longer rendered. * fixed offset calculation in some cases. moved those codes into the for loop. because the offset of each bar may be different. (detail in comments) * Update Source/Charts/Renderers/BarChartRenderer.swift Co-Authored-By: potato04 <shiww@outlook.com> * Add missing properties to copy(with:) methods (ChartsOrg#3715) * ChartsOrg#3578 Add missing properties to copy(with:) methods * Add NSCopying conformance * Fix legend offset bug for horizontal bar chart (Fixes ChartsOrg#3301) * Fix applying lineCap value for line chart data sets (Fixes ChartsOrg#3739) DataSets for line chart have lineCap property which is supposed to be applied to the chart line. But it was applied only if dataSet is drawn in linear/stepped mode. This commit makes lineCap work for any existing mode. * Update README.md (ChartsOrg#3737) Replace a confusing sentence with a clear one. Fix grammatical errors. * fix ChartsOrg#3719 * add call chartScaled() after double tap (ChartsOrg#3770) * Remove delegate method call for translation when no translation really occured * Removed use of `values` where appropriate * Fixed `addEntry` implementation * Deprecated direct usage of values * BarLineScatterCandleBubbleRenderer.XBounds conformance to RangeExpression and Sequence Sequence conformance simplifies for-in loops Looking forward to when data types conforming to Collection, RangeExpression conformance by XBounds allows for slicing of the collections further simplifying algorithms on data/datasets. * Draws the line chart the same way regardless of the number of colors for the data set (ChartsOrg#3764) * Multiple colors for valueline (Fixes ChartsOrg#3480) (ChartsOrg#3709) * Multiple colors for valueline (Fixes ChartsOrg#3480) This change adds a flag matchValueLineColorToPieSlice to PieChartDataSet and IPieChartDataSet protocol. When enabled, valuelines will have the same color as slices they attached to. matchValueLineColorToPieSlice is set to false by default, so colors won't be changed in old projects that use Charts. * Changed variable name from matchValueLineColorToPieSlice to valueLineAutoColor * Changed variable name from valueLineAutoColor to useValueColorForLine * Changed variable name from valueLineAutoColor to useValueColorForLine * fix code style fix code style * Changed check for useValueColorForLine with suggested * fix code style * Added name DrawLine: to do{} section * bump version to 3.2.2 * update change log * Renamed `values` to `entries` to reflect the property's type Removed arbitrary setter access to `entries` to encourage use of `Collection` mechanics Added `replaceEntries` * Fixed tests * Create "chartViewDidEndAnimate" callback function in "ChartViewBase" that is called when Animator stops animating * Update protocol function description * Improve HorizontalBarChart offset calculation for negative value labels (Fixes ChartsOrg#3850) * Replace AnyObject with Any This is in line with how Objc interfaces are now imported * Fixed target on NSUIDisplayLink * Removed unnecessary #if statements and unified style to align with Xcode's indentation * Velocity samples calculation (ChartsOrg#3883) * Updated `PieRadarChartViewBase.sampleVelocity(touchLocation:)` algorithm. * Updated `PieRadarChartViewBase.calculateVelocity` algorithm * Updated naming for `_velocitySamples` * A fix for ChartsOrg#3848. Use a stock iterator instead of a custom one. (ChartsOrg#3891) * Migrating to built-in algorithms (ChartsOrg#3892) * Align `ChartLimit.LabelPosition` naming with `UIRectCorner` (ChartsOrg#3846) * Align `ChartLimit.LabelPosition` naming with `UIRectCorner` * Fixed Demos * fix indent after replacing if with guard * reverted mistaken changes * Removed unused #if statements * add animator reference to animatorDidStop ChartViewBase delegate callback. * Minor updates for Swift 5 (ChartsOrg#3874) * Minor updates for Swift 5 Need FBSnapshotTestCase to be updated * Updated testing Framework for Swift 5 bumped minimum deployment version to 8.4 * Bumped Travis Xcode version * Fix test failures. add a new extension to only use 64bit arch. This is the companion commit that only has code change regards fixing test failures. * delete unused test images with specific screen size. this is a companion commit to only have deleted files * rename the in-use test images. this is a companion commit to only have renamed files. * change image diff to 0.001 tolerance make clipValuesToContentEnabled to true to fix BarTests:testPositiveValuesWithCustomAxisMaximum() failure * 1. merge master to fix xBounds iterator() to match the behavior of `stride(from: _xBounds.min, through: _xBounds.range + _xBounds.min, by: 1)` this fix issues from ChartsOrg@2a1ecb4 2. revert clipValuesToContentEnabled to false by default. but enable it for bar chart test - testPositiveValuesWithCustomAxisMaximum() 3. update tvOS test image for testPositiveValuesWithCustomAxisMaximum. After changing tolerance to 0.001, it fails while the same iOS test pass. I looked into the image diff, it shows the intersect of bar top edge and axis line at value 50 has diff, but I suppose the image is the same. safe to merge. * fix ChartsOrg#3860. maxHeight didn't count the last label * Reassess convenience initializers (ChartsOrg#3862) * Reassess convenience initializers The only data required to initialize an entry is an x and y value (or y in the case of Pie and Radar). All other data can easily be updated by initializing and assigning properties on the entry. Therefor, those initializers should be the ones marked as convenience. Made initializer declarations consistent. * Modernize BarChartDataEntry internal calculations * Style updated for PR * Fix horizontal bar chart not drawing values and add unit tests (ChartsOrg#3906) * fix horizontal bar chart drawValues not correctly drawing and add testNotDrawValueAboveBars UT * add unit tests for horizontal bar chart, including default tests and drawValues and drawValuesAboveBars default data entries included positive and negative values * add tvOS test images * add stacked bar tests for bar chart unit tests * fix typo * change to guard statement for shouldDrawValues * update test images to match master branch * Data as any (ChartsOrg#3863) * `ChartEntry.data` is now of type `Any` There is no need to restrict `ChartEntry.data` to `AnyObject`. This PR loosens that restriction. As a result we cannot compare `data`, though this should never have been the case in the first place. * Updated `ChartDataEntry` initializers to accept `Any` for `data` * Updated test * bump version to 3.3 * update change log * update gemfile * correct 3.3 to 3.3.0. * For ChartsOrg#3917. make init(label: String?) convenient initializer (ChartsOrg#3973) * fix ChartsOrg#3917. make `init(label: String?)` to be a convenient init to enable auto inheritance. * add UT for default dataSet label

liuxuan30 · 2019-08-07T06:50:02Z

@stokatyan sorry to bring this up again. I was tracking an issue for line x axis animation in #4093, and after fix I found that the linear animation will have an unexpected dash line like below:

you can see at first it already have a dash line, with circle on the left while missing the right circle, indicating the animation is not reaching the second point, so this dash line should not be drawn.

I compared the linear code, it looks you choose to use

context.strokeLineSegments(between: _lineSegments)

rather than addLine + strokePath way to draw linear. Do you remember why you do so? In old code base, strokeLineSegments is used for multiple colors only.

The old code is using addLine + strokePath so no additional dash line during animating.

I suspect this dash line is a bug in strokeLineSegments code path, but not sure if addLine + strokePath is causing the sharp edge? If not, I would like to see if I can use addLine + strokePath to fix the dash line bug, or I have to fix it in strokeLineSegments

@IBOutlet

* Avoid passing NaN to CoreGraphics API (Fixes ChartsOrg#1626) * Added delegate callback to detect when panning is finished, to potentially allow users to manually reset the hightlight values once panning is complete * Changed the part of the code where the delegate gets called * Make NSUIAccessibilityElement initializer public. * Add Parameters Section ``` (\n[ ]+)(((/// - parameter \w+:.*\s+)(///((\s+)|( \s+.+\s+)))?)*/// - parameter \w+:.*) ``` ``` $1/// - Parameters:$1$2 ``` * Remove parameter prefix ``` /// - parameter (\w+):(.*)(\s+///(\n))*(\s+) ``` ``` /// - $1:$2$4$5 ``` * Remove property’s `returns` section ``` /// - returns: (.+\s+((override|@IBOutlet|@objc|weak|unowned|lazy|static|class|open|public|private|fileprivate|internal)($set$)? )*(var|let)) ``` ``` /// $1 ``` * Add missing `-` ``` /// (note|return|parameters|throws): ``` ``` /// - $1: ``` * Sort sections ``` ((///)[ ]+[^-\n]+(\s+))?(((((/// - Parameters:\s+(/// (( - \w+:)|([^-]{1})).*\s+)+)\s+)|(/// - Returns:.*\s+(/// [^-]{1}.*\s+)*)|(/// - Note:.*\s+(/// [^-]{1}.*\s+)*)|(/// - Throws:.*\s+(/// [^-]{1}.*\s+)*))(///\n\s+)?)+) ``` ``` $1$2$3$15$7$17$13 ``` * Uppercased the section title * fix function groupBars document error * Remove duplicated section * Update ChartViewBase.swift Updated documentation in the code based on feedback * Add missing empty line between Summary and other section manually * fix wrong assignment to axisMaxLabels property * Remove meaningless comment * improvements in barRect height calculation (ChartsOrg#3650) * fixed barRectCaculation * fixed offset calculation * Fix the mess caused by the setting the min&min value of the y-axis by error : Just simply swap their values * Fix the mess caused by the setting the min&min value of the y-axis by error * Revert "Fix the mess caused by the setting the min&min value of the y-axis by error" This reverts commit 526a73a. * Fix the mess caused by the setting the min&min value of the y-axis by error * update offset calculation * update code style * update code style * update offset calculation * keep barRect calculation untouched try to simply the calculation. keep barRect calculation untouched * After the correction of min and max , they should be assigned back to _axisMinimum and _axisMaximum * add demo for bar chart unit test * update unit test * revert last commit * update unit test * make sure max is greater than min & turnoff record mode for barchartest * add new UT and fix some issues. 1. add more bar chart UT 2. code style fix 3. manually add chart.notifyDataSetChanged() - some old UT and new ones forget to call this method, leading the test images to be wrong. Notice: some test images diff shows slight pixel shift, not sure why, but both old and new image seems drawing correctly * update tvOS images * update tolerance to 1% & more swift-y * update tvOS images, removing "Description Label", (not rendered anymore) changing tolerance will trigger "Description Label" detection * update iOS test images, "Description Label" no longer rendered. * fixed offset calculation in some cases. moved those codes into the for loop. because the offset of each bar may be different. (detail in comments) * Update Source/Charts/Renderers/BarChartRenderer.swift Co-Authored-By: potato04 <shiww@outlook.com> * Add missing properties to copy(with:) methods (ChartsOrg#3715) * ChartsOrg#3578 Add missing properties to copy(with:) methods * Add NSCopying conformance * Fix legend offset bug for horizontal bar chart (Fixes ChartsOrg#3301) * Fix applying lineCap value for line chart data sets (Fixes ChartsOrg#3739) DataSets for line chart have lineCap property which is supposed to be applied to the chart line. But it was applied only if dataSet is drawn in linear/stepped mode. This commit makes lineCap work for any existing mode. * Update README.md (ChartsOrg#3737) Replace a confusing sentence with a clear one. Fix grammatical errors. * fix ChartsOrg#3719 * add call chartScaled() after double tap (ChartsOrg#3770) * Remove delegate method call for translation when no translation really occured * Removed use of `values` where appropriate * Fixed `addEntry` implementation * Deprecated direct usage of values * BarLineScatterCandleBubbleRenderer.XBounds conformance to RangeExpression and Sequence Sequence conformance simplifies for-in loops Looking forward to when data types conforming to Collection, RangeExpression conformance by XBounds allows for slicing of the collections further simplifying algorithms on data/datasets. * Draws the line chart the same way regardless of the number of colors for the data set (ChartsOrg#3764) * Multiple colors for valueline (Fixes ChartsOrg#3480) (ChartsOrg#3709) * Multiple colors for valueline (Fixes ChartsOrg#3480) This change adds a flag matchValueLineColorToPieSlice to PieChartDataSet and IPieChartDataSet protocol. When enabled, valuelines will have the same color as slices they attached to. matchValueLineColorToPieSlice is set to false by default, so colors won't be changed in old projects that use Charts. * Changed variable name from matchValueLineColorToPieSlice to valueLineAutoColor * Changed variable name from valueLineAutoColor to useValueColorForLine * Changed variable name from valueLineAutoColor to useValueColorForLine * fix code style fix code style * Changed check for useValueColorForLine with suggested * fix code style * Added name DrawLine: to do{} section * bump version to 3.2.2 * update change log * Renamed `values` to `entries` to reflect the property's type Removed arbitrary setter access to `entries` to encourage use of `Collection` mechanics Added `replaceEntries` * Fixed tests * Create "chartViewDidEndAnimate" callback function in "ChartViewBase" that is called when Animator stops animating * Update protocol function description * Improve HorizontalBarChart offset calculation for negative value labels (Fixes ChartsOrg#3850) * Replace AnyObject with Any This is in line with how Objc interfaces are now imported * Fixed target on NSUIDisplayLink * Removed unnecessary #if statements and unified style to align with Xcode's indentation * Velocity samples calculation (ChartsOrg#3883) * Updated `PieRadarChartViewBase.sampleVelocity(touchLocation:)` algorithm. * Updated `PieRadarChartViewBase.calculateVelocity` algorithm * Updated naming for `_velocitySamples` * A fix for ChartsOrg#3848. Use a stock iterator instead of a custom one. (ChartsOrg#3891) * Migrating to built-in algorithms (ChartsOrg#3892) * Align `ChartLimit.LabelPosition` naming with `UIRectCorner` (ChartsOrg#3846) * Align `ChartLimit.LabelPosition` naming with `UIRectCorner` * Fixed Demos * fix indent after replacing if with guard * reverted mistaken changes * Removed unused #if statements * add animator reference to animatorDidStop ChartViewBase delegate callback. * Minor updates for Swift 5 (ChartsOrg#3874) * Minor updates for Swift 5 Need FBSnapshotTestCase to be updated * Updated testing Framework for Swift 5 bumped minimum deployment version to 8.4 * Bumped Travis Xcode version * Fix test failures. add a new extension to only use 64bit arch. This is the companion commit that only has code change regards fixing test failures. * delete unused test images with specific screen size. this is a companion commit to only have deleted files * rename the in-use test images. this is a companion commit to only have renamed files. * change image diff to 0.001 tolerance make clipValuesToContentEnabled to true to fix BarTests:testPositiveValuesWithCustomAxisMaximum() failure * 1. merge master to fix xBounds iterator() to match the behavior of `stride(from: _xBounds.min, through: _xBounds.range + _xBounds.min, by: 1)` this fix issues from ChartsOrg@2a1ecb4 2. revert clipValuesToContentEnabled to false by default. but enable it for bar chart test - testPositiveValuesWithCustomAxisMaximum() 3. update tvOS test image for testPositiveValuesWithCustomAxisMaximum. After changing tolerance to 0.001, it fails while the same iOS test pass. I looked into the image diff, it shows the intersect of bar top edge and axis line at value 50 has diff, but I suppose the image is the same. safe to merge. * fix ChartsOrg#3860. maxHeight didn't count the last label * Reassess convenience initializers (ChartsOrg#3862) * Reassess convenience initializers The only data required to initialize an entry is an x and y value (or y in the case of Pie and Radar). All other data can easily be updated by initializing and assigning properties on the entry. Therefor, those initializers should be the ones marked as convenience. Made initializer declarations consistent. * Modernize BarChartDataEntry internal calculations * Style updated for PR * Fix horizontal bar chart not drawing values and add unit tests (ChartsOrg#3906) * fix horizontal bar chart drawValues not correctly drawing and add testNotDrawValueAboveBars UT * add unit tests for horizontal bar chart, including default tests and drawValues and drawValuesAboveBars default data entries included positive and negative values * add tvOS test images * add stacked bar tests for bar chart unit tests * fix typo * change to guard statement for shouldDrawValues * update test images to match master branch * Data as any (ChartsOrg#3863) * `ChartEntry.data` is now of type `Any` There is no need to restrict `ChartEntry.data` to `AnyObject`. This PR loosens that restriction. As a result we cannot compare `data`, though this should never have been the case in the first place. * Updated `ChartDataEntry` initializers to accept `Any` for `data` * Updated test * bump version to 3.3 * update change log * update gemfile * correct 3.3 to 3.3.0. * For ChartsOrg#3917. make init(label: String?) convenient initializer (ChartsOrg#3973) * fix ChartsOrg#3917. make `init(label: String?)` to be a convenient init to enable auto inheritance. * add UT for default dataSet label * Added a safety check before an unsafe array operation * Update Info.plist * Update License Changed year in license file * fixed stacked chart bug when there are different stacks on columns. (ChartsOrg#4029) fix ChartsOrg#3659 * fixed stacked chart bug when there are different stacks on columns. * added empty array check

@IBOutlet

* Avoid passing NaN to CoreGraphics API (Fixes ChartsOrg#1626) * Added delegate callback to detect when panning is finished, to potentially allow users to manually reset the hightlight values once panning is complete * Changed the part of the code where the delegate gets called * Make NSUIAccessibilityElement initializer public. * Add Parameters Section ``` (\n[ ]+)(((/// - parameter \w+:.*\s+)(///((\s+)|( \s+.+\s+)))?)*/// - parameter \w+:.*) ``` ``` $1/// - Parameters:$1$2 ``` * Remove parameter prefix ``` /// - parameter (\w+):(.*)(\s+///(\n))*(\s+) ``` ``` /// - $1:$2$4$5 ``` * Remove property’s `returns` section ``` /// - returns: (.+\s+((override|@IBOutlet|@objc|weak|unowned|lazy|static|class|open|public|private|fileprivate|internal)($set$)? )*(var|let)) ``` ``` /// $1 ``` * Add missing `-` ``` /// (note|return|parameters|throws): ``` ``` /// - $1: ``` * Sort sections ``` ((///)[ ]+[^-\n]+(\s+))?(((((/// - Parameters:\s+(/// (( - \w+:)|([^-]{1})).*\s+)+)\s+)|(/// - Returns:.*\s+(/// [^-]{1}.*\s+)*)|(/// - Note:.*\s+(/// [^-]{1}.*\s+)*)|(/// - Throws:.*\s+(/// [^-]{1}.*\s+)*))(///\n\s+)?)+) ``` ``` $1$2$3$15$7$17$13 ``` * Uppercased the section title * fix function groupBars document error * Remove duplicated section * Update ChartViewBase.swift Updated documentation in the code based on feedback * Add missing empty line between Summary and other section manually * fix wrong assignment to axisMaxLabels property * Remove meaningless comment * improvements in barRect height calculation (ChartsOrg#3650) * fixed barRectCaculation * fixed offset calculation * Fix the mess caused by the setting the min&min value of the y-axis by error : Just simply swap their values * Fix the mess caused by the setting the min&min value of the y-axis by error * Revert "Fix the mess caused by the setting the min&min value of the y-axis by error" This reverts commit 526a73a. * Fix the mess caused by the setting the min&min value of the y-axis by error * update offset calculation * update code style * update code style * update offset calculation * keep barRect calculation untouched try to simply the calculation. keep barRect calculation untouched * After the correction of min and max , they should be assigned back to _axisMinimum and _axisMaximum * add demo for bar chart unit test * update unit test * revert last commit * update unit test * make sure max is greater than min & turnoff record mode for barchartest * add new UT and fix some issues. 1. add more bar chart UT 2. code style fix 3. manually add chart.notifyDataSetChanged() - some old UT and new ones forget to call this method, leading the test images to be wrong. Notice: some test images diff shows slight pixel shift, not sure why, but both old and new image seems drawing correctly * update tvOS images * update tolerance to 1% & more swift-y * update tvOS images, removing "Description Label", (not rendered anymore) changing tolerance will trigger "Description Label" detection * update iOS test images, "Description Label" no longer rendered. * fixed offset calculation in some cases. moved those codes into the for loop. because the offset of each bar may be different. (detail in comments) * Update Source/Charts/Renderers/BarChartRenderer.swift Co-Authored-By: potato04 <shiww@outlook.com> * Add missing properties to copy(with:) methods (ChartsOrg#3715) * ChartsOrg#3578 Add missing properties to copy(with:) methods * Add NSCopying conformance * Fix legend offset bug for horizontal bar chart (Fixes ChartsOrg#3301) * Fix applying lineCap value for line chart data sets (Fixes ChartsOrg#3739) DataSets for line chart have lineCap property which is supposed to be applied to the chart line. But it was applied only if dataSet is drawn in linear/stepped mode. This commit makes lineCap work for any existing mode. * Update README.md (ChartsOrg#3737) Replace a confusing sentence with a clear one. Fix grammatical errors. * fix ChartsOrg#3719 * add call chartScaled() after double tap (ChartsOrg#3770) * Remove delegate method call for translation when no translation really occured * Removed use of `values` where appropriate * Fixed `addEntry` implementation * Deprecated direct usage of values * BarLineScatterCandleBubbleRenderer.XBounds conformance to RangeExpression and Sequence Sequence conformance simplifies for-in loops Looking forward to when data types conforming to Collection, RangeExpression conformance by XBounds allows for slicing of the collections further simplifying algorithms on data/datasets. * Draws the line chart the same way regardless of the number of colors for the data set (ChartsOrg#3764) * Multiple colors for valueline (Fixes ChartsOrg#3480) (ChartsOrg#3709) * Multiple colors for valueline (Fixes ChartsOrg#3480) This change adds a flag matchValueLineColorToPieSlice to PieChartDataSet and IPieChartDataSet protocol. When enabled, valuelines will have the same color as slices they attached to. matchValueLineColorToPieSlice is set to false by default, so colors won't be changed in old projects that use Charts. * Changed variable name from matchValueLineColorToPieSlice to valueLineAutoColor * Changed variable name from valueLineAutoColor to useValueColorForLine * Changed variable name from valueLineAutoColor to useValueColorForLine * fix code style fix code style * Changed check for useValueColorForLine with suggested * fix code style * Added name DrawLine: to do{} section * bump version to 3.2.2 * update change log * Renamed `values` to `entries` to reflect the property's type Removed arbitrary setter access to `entries` to encourage use of `Collection` mechanics Added `replaceEntries` * Fixed tests * Create "chartViewDidEndAnimate" callback function in "ChartViewBase" that is called when Animator stops animating * Update protocol function description * Improve HorizontalBarChart offset calculation for negative value labels (Fixes ChartsOrg#3850) * Replace AnyObject with Any This is in line with how Objc interfaces are now imported * Fixed target on NSUIDisplayLink * Removed unnecessary #if statements and unified style to align with Xcode's indentation * Velocity samples calculation (ChartsOrg#3883) * Updated `PieRadarChartViewBase.sampleVelocity(touchLocation:)` algorithm. * Updated `PieRadarChartViewBase.calculateVelocity` algorithm * Updated naming for `_velocitySamples` * A fix for ChartsOrg#3848. Use a stock iterator instead of a custom one. (ChartsOrg#3891) * Migrating to built-in algorithms (ChartsOrg#3892) * Align `ChartLimit.LabelPosition` naming with `UIRectCorner` (ChartsOrg#3846) * Align `ChartLimit.LabelPosition` naming with `UIRectCorner` * Fixed Demos * fix indent after replacing if with guard * reverted mistaken changes * Removed unused #if statements * add animator reference to animatorDidStop ChartViewBase delegate callback. * Minor updates for Swift 5 (ChartsOrg#3874) * Minor updates for Swift 5 Need FBSnapshotTestCase to be updated * Updated testing Framework for Swift 5 bumped minimum deployment version to 8.4 * Bumped Travis Xcode version * Fix test failures. add a new extension to only use 64bit arch. This is the companion commit that only has code change regards fixing test failures. * delete unused test images with specific screen size. this is a companion commit to only have deleted files * rename the in-use test images. this is a companion commit to only have renamed files. * change image diff to 0.001 tolerance make clipValuesToContentEnabled to true to fix BarTests:testPositiveValuesWithCustomAxisMaximum() failure * 1. merge master to fix xBounds iterator() to match the behavior of `stride(from: _xBounds.min, through: _xBounds.range + _xBounds.min, by: 1)` this fix issues from ChartsOrg@2a1ecb4 2. revert clipValuesToContentEnabled to false by default. but enable it for bar chart test - testPositiveValuesWithCustomAxisMaximum() 3. update tvOS test image for testPositiveValuesWithCustomAxisMaximum. After changing tolerance to 0.001, it fails while the same iOS test pass. I looked into the image diff, it shows the intersect of bar top edge and axis line at value 50 has diff, but I suppose the image is the same. safe to merge. * fix ChartsOrg#3860. maxHeight didn't count the last label * Reassess convenience initializers (ChartsOrg#3862) * Reassess convenience initializers The only data required to initialize an entry is an x and y value (or y in the case of Pie and Radar). All other data can easily be updated by initializing and assigning properties on the entry. Therefor, those initializers should be the ones marked as convenience. Made initializer declarations consistent. * Modernize BarChartDataEntry internal calculations * Style updated for PR * Fix horizontal bar chart not drawing values and add unit tests (ChartsOrg#3906) * fix horizontal bar chart drawValues not correctly drawing and add testNotDrawValueAboveBars UT * add unit tests for horizontal bar chart, including default tests and drawValues and drawValuesAboveBars default data entries included positive and negative values * add tvOS test images * add stacked bar tests for bar chart unit tests * fix typo * change to guard statement for shouldDrawValues * update test images to match master branch * Data as any (ChartsOrg#3863) * `ChartEntry.data` is now of type `Any` There is no need to restrict `ChartEntry.data` to `AnyObject`. This PR loosens that restriction. As a result we cannot compare `data`, though this should never have been the case in the first place. * Updated `ChartDataEntry` initializers to accept `Any` for `data` * Updated test * bump version to 3.3 * update change log * update gemfile * correct 3.3 to 3.3.0. * For ChartsOrg#3917. make init(label: String?) convenient initializer (ChartsOrg#3973) * fix ChartsOrg#3917. make `init(label: String?)` to be a convenient init to enable auto inheritance. * add UT for default dataSet label * fix ChartsOrg#3975. if we disable highlight for pie chart data set, we still need to render without a shift. * Added a safety check before an unsafe array operation * Update Info.plist * Update License Changed year in license file * fixed stacked chart bug when there are different stacks on columns. (ChartsOrg#4029) fix ChartsOrg#3659 * fixed stacked chart bug when there are different stacks on columns. * added empty array check * fix ChartsOrg#4093, also close ChartsOrg#3960 1. change XBounds iterator to use self.min + self.range rather than self.x 2. align drawLinear, drawCubicBezier to new XBounds iterator. 3. fix unexpected dash line during linear animation due to reading the next entry point * Fix Swift Package Manager compile issue Signed-off-by: Ryne Cheow <rynecheow@gmail.com> * Unspecify library type Signed-off-by: Ryne Cheow <rynecheow@gmail.com> * Fix gitignore to ignore .swiftpm as a directory Signed-off-by: Ryne Cheow <rynecheow@gmail.com> * Apply Xcode11 changes automatic remove warnings detected by Xcode11 * bump to iPhone 8 as iPhone 7 has been dropped out * bump to test framework to 6.1 * chart types that are not affected by formatter change * tests affected by formatter change of `minimumIntegerDigits` from 0 to 1 * regenerate bar chart tests * rebuild tvOS test images * Fixes ChartsOrg#4099: Line renderer did not render lines if their coordinates fell outside of the viewport. (ChartsOrg#4100) * Fixed ChartsOrg#4099: Line renderer did not render lines if they coordinates fell outside of the viewport, even though they might intersect the viewport. * Updated inline documentation. * Implemented code review feedback and removed unnecessary checks for performance reasons. * Simplified and clarified the linear function to check for collisions with the left, top and bottom edges of the view port, and commented out the unecessary logic that checks for collision with the right edge of the view port. * Updated in-line documentation. * Update ViewPortHandler.swift add a check for vertical line and a few comments change * bump to 3.4.0 * fix change log format * fix pod build and update gems * introduce gracefully degrading abstractions for dark mode for ios and… (ChartsOrg#4171) * introduce gracefully degrading abstractions for dark mode for ios and macos and use them to draw text * it's .labelColor not .label on NSColor

Draws the line chart the same way regardless of the number of colors …

aecd7f0

…for the data set

jjatie requested changes Dec 11, 2018

View reviewed changes

liuxuan30 mentioned this pull request Dec 24, 2018

Add lineJoinType and miterLimit parameters to LineChartDataSet (fixes #2180 ) #3797

Closed

liuxuan30 added this to To do in 3.3 via automation Jan 22, 2019

3.3 automation moved this from To do to In progress Jan 26, 2019

jjatie approved these changes Jan 26, 2019

View reviewed changes

Merged with upstream master

55a9cc8

jjatie merged commit d73b552 into ChartsOrg:master Feb 10, 2019

3.3 automation moved this from In progress to Done Feb 10, 2019

liuxuan30 mentioned this pull request Aug 7, 2019

Line chart x axis animation is broken #4093

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixes sharp edges on the line chart #3764

Fixes sharp edges on the line chart #3764

stokatyan commented Dec 1, 2018

liuxuan30 commented Dec 4, 2018 •

edited

Loading

stokatyan commented Dec 5, 2018

anton-filimonov commented Dec 8, 2018

stokatyan commented Dec 10, 2018

liuxuan30 commented Dec 11, 2018

liuxuan30 commented Dec 11, 2018

liuxuan30 commented Dec 11, 2018

anton-filimonov commented Dec 11, 2018

anton-filimonov commented Dec 11, 2018

jjatie commented Dec 11, 2018

jjatie left a comment

stokatyan commented Dec 11, 2018 •

edited

Loading

anton-filimonov commented Dec 24, 2018

jjatie commented Dec 25, 2018

anton-filimonov commented Dec 25, 2018

liuxuan30 commented Jan 22, 2019

stokatyan commented Jan 24, 2019

liuxuan30 commented Jan 28, 2019

liuxuan30 commented Jan 28, 2019

codecov-io commented Jan 30, 2019 •

edited

Loading

stokatyan commented Feb 6, 2019

liuxuan30 commented Feb 8, 2019

jjatie commented Feb 8, 2019

liuxuan30 commented Aug 7, 2019 •

edited

Loading

Fixes sharp edges on the line chart #3764

Fixes sharp edges on the line chart #3764

Conversation

stokatyan commented Dec 1, 2018

Issue Link 🔗

Goals ⚽

Implementation Details 🚧

Testing Details 🔍

liuxuan30 commented Dec 4, 2018 • edited Loading

stokatyan commented Dec 5, 2018

anton-filimonov commented Dec 8, 2018

stokatyan commented Dec 10, 2018

liuxuan30 commented Dec 11, 2018

liuxuan30 commented Dec 11, 2018

liuxuan30 commented Dec 11, 2018

anton-filimonov commented Dec 11, 2018

anton-filimonov commented Dec 11, 2018

jjatie commented Dec 11, 2018

jjatie left a comment

Choose a reason for hiding this comment

stokatyan commented Dec 11, 2018 • edited Loading

anton-filimonov commented Dec 24, 2018

jjatie commented Dec 25, 2018

anton-filimonov commented Dec 25, 2018

liuxuan30 commented Jan 22, 2019

stokatyan commented Jan 24, 2019

liuxuan30 commented Jan 28, 2019

liuxuan30 commented Jan 28, 2019

codecov-io commented Jan 30, 2019 • edited Loading

Codecov Report

stokatyan commented Feb 6, 2019

liuxuan30 commented Feb 8, 2019

jjatie commented Feb 8, 2019

liuxuan30 commented Aug 7, 2019 • edited Loading

liuxuan30 commented Dec 4, 2018 •

edited

Loading

stokatyan commented Dec 11, 2018 •

edited

Loading

codecov-io commented Jan 30, 2019 •

edited

Loading

liuxuan30 commented Aug 7, 2019 •

edited

Loading