| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0034819 | Packages | TAChart | public | 2019-01-05 18:19 | 2019-02-07 01:45 |
| Reporter | Marcin Wiazowski | Assigned To | wp | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 2.0RC3 | Product Build | |||
| Target Version | 2.0.2 | Fixed in Version | |||
| Summary | 0034819: Series marks are sometimes invisible | ||||
| Description | Series marks are sometimes fully or partially invisible - the problem depends on: - MarkPositions setting of the series, - Range settings of the assigned Y axis. Please take a look at the attached animation and the sample application. Two charts are visible, that have identical settings, with one exception - the left chart doesn't use Range.Min for Y axis, the right one uses Range.Min = -1. By using a "Move Up" button multiple times, the problem can be seen: series marks should be fully visible in all cases - but they are not. The problem can be defined as (Lazarus 2.0.0 RC3): - Left chart: Range.Min is not used, so the mark (description) for the first series point is fully visible for Y in range (-INF, 0> (this is OK) and fully invisible for Y in range (0, +INF) (this is NOT OK) - Right chart: Range.Min is -1, so the mark (description) for the first series point is fully invisible for Y in range (-INF, -1) (this is OK), fully visible for Y in range <-1, 0> (this is OK), and partially invisible for Y in range (0, some positive value) (this is NOT OK) When compiled with Lazarus 1.8.4, left chart works fully properly, and the right one works improperly (but behavior is different than in 2.0.0 RC3). Note 1: Similar problem occurs also when setting MarkPositions of both series to lmpInside or lmpInsideCenter. Note 2: Same problem will probably occur also when using RangeMax and MarkPositions = lmpPositive (instead of RangeMin and MarkPositions = lmpNegative as it is now). Note 3: This bug can be used to limit height of a multiline mark's text (by using the case when the mark is partially invisible) - please see the attached "ThisBugCanBeUseful.png" image. Such a functionality is very useful - very long text doesn't occupy too much chart space, but still can bee seen when needed (by zooming in). I'm afraid that this (unintended) functionality will disappear after patching the bug - so maybe this functionality could be officially added (by adding some property to the series or marks)? This would be wonderful. Kind regards | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | |||||
| LazTarget | 2.0.2 | ||||
| Widgetset | Win32/Win64 | ||||
| Attached Files |
| ||||
|
|
Animation.gif (37,485 bytes) |
|
|
Reproduce.zip (3,539 bytes) |
|
|
ThisBugCanBeUseful.png (5,320 bytes) |
|
|
Began to redo the mark positioning routine and committed a preliminary version which has some improvement, but still some issues, in particular with rotated series. Uploaded my test program which covers a variety of cases like rotated and stacked line, bar and area series. I don't fully understand your idea in note 3. Do you want to display marks only partially? I don't like this, looks like an error. If your chart is too crowded you should display hint popups by means of the chart tools. Maybe you should turn off the series' Marks.AutoMargin and provide ample space for margins. Then your series marks will be truncated at the border. |
|
|
Please ignore my Note 3. I'm still not an expert in TAChart and I just wasn't aware of series' Marks.AutoMargins property. Thanks for your advice. Regards |
|
|
MarkPositions.zip (4,371 bytes) |
|
|
r60027 should handle the rotated series correctly now, and seems to work correctly for all cases. Still have to look at the case of your right chart where one end of the axis is "fixed" by means of the Range parameters. |
|
|
I think the right chart of your demo works correctly (at least in the present state). The Range of the axis is only one piece of the contributions merged to the final axis range: When the y values of all data points are larger than the LeftAxis.Range.Min then the axis minimum is defined by Range.Min. When y values are smaller than Range.Min then the axis is extended to show the full data range. If you really want to truncate the axis to the Range.Min you must set Chart.Extent.YMin. I am resolving now (merging to Laz 2.0-fixes is requested). Please close the report to remove it from the usual bugtracker screens. Or reopen if something is still wrong. |
|
|
I tested the last trunk version and - as far as I understand - there are still some problems for MarkPositions = lmpInsideCenter - please see the attached InsideCenterX.png images, and the Reproduce2 project. Note 1: Documentation says: "lmpInsideCenter -- between data point and zero level" - but all the marks, on all the InsideCenterX.png images, are located between data point and +INF. Note 2: On InsideCenterA.png: second data point on Chart 1 has a visible link to the mark (mark is invisible), while on Chart 2 link is not visible. Note 3: On InsideCenterA.png: some marks are partially invisible. Note 4: On InsideCenterB.png: one more mark is partially invisible. Note 5: On InsideCenterC.png: on Chart 3, labels on Y axis disappeared. Note 6: On InsideCenterD.png: on Chart 1, labels on Y axis also disappeared. Note 7: Merging to Laz 2.0-fixes failed due to conflicts. Regards |
|
|
InsideCenterA.png (11,374 bytes) |
|
|
InsideCenterB.png (11,674 bytes) |
|
|
InsideCenterC.png (11,395 bytes) |
|
|
InsideCenterD.png (11,098 bytes) |
|
|
Reproduce2.zip (3,757 bytes) |
|
|
> Note 7: Merging to Laz 2.0-fixes failed due to conflicts. Merged manually. |
|
|
I found two bugs in TBasicPointSeries.DrawLabels, and one possible improvement: Note 8: if not Stacked then g := GetGraphPoint(i, 0, si) y VARIABLE IS NOT INITIALIZED HERE !!!!!!!!!!!! else if si = 0 then y := Source[i]^.y - GetZeroLevel else begin y := Source[i]^.YList[si-1]; if IsRotated then g.X += AxisToGraphY(y) else g.Y += AxisToGraphY(y); end; gl := g; if FMarkPositions = lmpInsideCenter then begin BUT IS USED HERE !!!!!!!!!!!! if IsRotated then gl.X -= AxisToGraphX(y)/2 else gl.Y -= AxisToGraphY(y)/2; end; Note 9: There is: (Marks.YIndex = MARKS_YINDEX_ALL) or (Marks.YIndex = si) and but brackets should be added: ((Marks.YIndex = MARKS_YINDEX_ALL) or (Marks.YIndex = si)) and Note 10: There is: for i := 0 to Count - 1 do begin but this can be changed to: for i := FLoBound to FUpBound do begin so drawing will be much, much faster for large data sets; the same loop constraints (i.e. FLoBound and FUpBound) are already used in TBasicPointSeries.DrawPointers; in fact, it seems that - after introducing FLoBound / FUpBound functionality - it has been used in all places, but TBasicPointSeries.DrawLabels has been omitted, so it is still very slow. Regards |
|
|
Fixed Note 8 in r60058. Thanks for reporting, this fixed the issue with the inside-centered line series labels not being between data point and zero level. This centering mode, however, is thought to be used for "filled" series, such as TBarSeries and TAreaSeries, and thus does not affect TLineSeries. |
|
|
Fixed Note 10 in r60059. How did you notice that speed issue? I would not use series marks for large data sets because all labels would overlap. Which application case do you have in mind where this would have been an issue in practice? |
|
|
Fixed Note 9 in r60060. |
|
|
Remark on Notes 2-6: The option lmpInsideCenter is primarily thought to be used with bar or area series. It does not make much sense to use it with a line series where the ZeroLevel has no visual effect and the mark links do not point to the data points. I added some clarifying statements to the documentation in http://wiki.lazarus.freepascal.org/TAChart_documentation#Mark_positions_and_attachment. Notes 2-4: Related to a bug with lmpInsideCenter which I could not find so far: If the label is attached to the "center" (i.e. half-distance between data point and zero level), sometimes the upper end of a mark is ignored when calculating the upper margin which results in partially visible marks. Notes 5-6: The disappearing labels are related to the way how automatic label positioning was implemented: If labels extend the range covered by the data the margin of the chart is increased such that it can be used by the label. Since the height of the chart itself remains constant the part available for the data becomes smaller. The axis label finding algorithm, however, is determined by the this data part of the axis. It is the same as if you shrink the height of a normal chart more and more. You will observe that there will be less and less axis labels because the lower limit of the label distance becomes comparable to or even exceeds the chart height. I am not saying that this cannot be fixed, but I fear this can't be done without completely rewriting the series and/or axis labeling routines, and I won't do this by no means. Moreover, I think the issue does not have much practical importance: when the space occupied by the labels takes too much away from the data area then labels should not be used at all because the structure of the data distribution will be leveled out. Resolving again. Let's see if automatic merging to fixes works this time. Please test and close if ok, or re-open if you find something else related. Thanks for your efforts, by the way. |
|
|
> Fixed Note 10 in r60059. How did you notice that speed issue? I would not use series marks for large data sets because all labels would overlap. Which application case do you have in mind where this would have been an issue in practice? Please note that you can have 100000 points in series, but you can limit X axis range by using Axis.Range.Min/Max - so you effectively need to display only few points (and their marks don't overlap in this case). In my specific case, I'm creating an application that displays some event log, similarly to "ThisBugCanBeUseful.png" image (that is attached to this bug report). X axis range is set to 1 day or 1 week, and the user can navigate by using dedicated MovePrevPeriod / ModeNextPeriod buttons. There may be few events per day (so few points/marks to display), but thousands in the whole data set (events may be collected by years, and there is about 20 event kinds). I just realized, that drawing 3 marks takes as much time as painting 100000 marks, due to the "for i := 0 to Count - 1 do" statement. |
|
|
I'm afraid that there are still some problems... Note 11: First I must ask some question - please see the "Comparison.png" that I attached. In lmpInside mode, all marks are directed towards zero - and this is as designed and OK. As far as I understand, the only intentional change for lmpInsideCenter mode (when comparing to lmpInside mode) was to change the marks' starting points - from "y" to "y/2". But also other change has been introduced - all marks are directed towards +INF. This doesn't seem to be consistent with lmpInside mode, and "xxx" mark is truncated on the "Comparison.png" image (the mark is probably used in margin calculation as if it were directed towards zero - similarly to lmpInside mode). If the intention was really to direct all marks arbitrarily to +INF, I think that lmpInsideCenter should be renamed to something like lmpInsideCenterPositive, and also accompanying lmpInsideCenterNegative mode should be added. But if the intention was to retain same marks direction as for lmpInside, then - in TBasicPointSeries.GetLabelDirection method - "lmpInsideCenter: isNeg := false;" should be changed to "lmpInsideCenter: isNeg := AValue >= ref;" Note 12: Launch the attached Reproduce3 application - it uses TBarSeries this time, and all MarkPositions are set to lmpPositive. Initially, Chart 2 in not painted at all (this is definitely a bug) - but after you minimize and maximize the application's window (i.e. force chart redrawing), Chart 2 is finally painted - but in an extremely strange way. Interestingly, this behavior depends somehow on series' source - after editing ListChartSource12 by changing -21 value to -20, the problem doesn't occur. Note 13: Launch the Reproduce3 application and press the "Move Up/Down" button multiple times. Chart 2's behavior is extremely unexpected and strange. Regards |
|
|
Comparison.png (12,172 bytes) |
|
|
Reproduce3.zip (3,527 bytes) |
|
|
Reverted all major changes and merge with fixes due to 0034857. Obviously TBasicPointSeries.UpdateMargins is very critical since it interacts with axis labeling in an iterative process. Not clear at the moment whether this report can be fixed at all. Note 9: Reimplemented in r60069. Note 10: Remimplemented in r60070. Note 8: Will not be implemented again this way because there are other issues in that routine. Please check the current state after r60070 and report which notes are still valid. I am reporting related issues which I saw on the way: 0034861, 0034862, 0034863. |
|
|
Note 8 avoided by new code in r60071 |
|
|
Fixed the original issue in r60077 by reverting the changes introduced by r56492 for the lmpInsideCenter option for label positioning (in TBasicChartSeries.UpdateMargins). The drawback is that the margins are no longer adjusted when they reach out of the bar. But when somebody chooses the option lmpInsideCenter he/she usually wants the label to be centered within a bar of a BarSeries, and would set Marks.Distance to 0 and Marks.Attachment to maCenter (as is recommended in the wiki documentation). I do not fully understand the behavior of the right chart in which one end of the y axis is locked. As I noted above there are several factors which contribute to the behavior whether the axis is extended or not. But I think if the user locks the axes he does not expect the series labels to be displayed fully. If the current behavior is critical for your application you can also use the Extent of the chart to fix the axes which has the highest priority and does not allow the axis range to grow any more. So far I did not check for the other "notes" - I think these bugs are a consequence of the first commit for this subject. Please test carefully and close if ok. |
|
|
> The drawback is that the margins are no longer adjusted when they reach out of the bar. Note 14: I'm afraid this creates a huge problem, which can be easily seen for multiline marks (and probably also for single lines, having their font big enough). Please launch the attached Reproduce4 application and press the button eight times: Chart 1 and Chart 3 start to show nothing, Chart 2 and Chart 4 no longer display any marks. |
|
|
Reproduce4.png (8,896 bytes) |
|
|
Reproduce4.zip (3,612 bytes) |
|
|
I fear you are constructing here use cases which are not relevant in practice. TAChart is not a "super-intelligent" library which can handle every oddity automatically. If you push the component into a corner case for which it was not designed it may work in an unexpected way. The issues that you mention occur when all the area available for the data has been consumed by the labels - I had explained above that the space occupied by the highest and lowest label is added to the margins of the chart and reduces the size in which data can be plotted. In fact, it can be seen in your screenshot that the y axis even becomes inverted (negative values growing upward) - this demonstrates that the chart can handle this erroneous situation without crashing. The solution for the application is that the chart must be sufficiently large to allow for the highest label, or you must truncate the label at the maximum height that you can afford depending on the size of the chart. You could also display a short label only and keep a longer text for a popup hint which comes up when you move the mouse over the data point - this requires a DatapointHintTool. Or you could put the extended message texts into a grid component next to the chart and use another DatapointTool to scroll the grid to the row which contains the message of the data point underneath the mouse. Or you could consider using a completely different component for displaying the log messages of your application - I know of the planner components of TvPlanIt or the timeline components in JVCL, and probably there are some others. |
|
|
Well, I'm aware that there are always some limitations - and being defined as a bug or as a limitation may be just a matter of making a decision by the developer. I also don't think that the case described in Note 14 is a problem in practice; I just reported it to be sure, that it isn't something unexpected (since I'm not an expert in TAChart internals, I can't settle). I'll perform more detailed tests tomorrow and let you know. Regards |
|
|
Note 11: I removed the option lmpInsideCenter from MarkPositions and introduced a new property MarkPositionCentered (r60088) which is published only for bar and area series. Therefore, it is no longer possible to apply this feature to line series & co, and the direction of the label from the center point can be adjusted by using the remaining options in MarkPositions. The meaning of lmpOutside and lmpInside was changed: the label no longer points away from / towards the zero level but from the average value of the data point y values. Zero level is used only for bar and area series where it makes sense. |
|
|
> I removed the option lmpInsideCenter from MarkPositions and introduced a new property MarkPositionCentered Quite a good idea. I've been testing all the day. I need a bit more time. Stay tuned. |
|
|
> y axis even becomes inverted (negative values growing upward) By writing these words, you effectively found two bugs! To avoid mess here, I described them in 0034896. Regards |
|
|
To avoid mess here, I described some problems in 0034897 and 0034898. |
|
|
Note 15: Please take a look at Animation5 and Reproduce5 application. I understand direction of marks for bar series, but I'm not sure about line series. Documentation in http://wiki.lazarus.freepascal.org/TAChart_documentation#Mark_positions_and_attachment says about "zero level", but I couldn't find what the zero level is. For bar series, it is just 0 on the Y axis. But for line series, is this an average between the highest and the lowest point? And is this as designed? If so, maybe it would be good to add some explanation to the documentation. P.S. The documentation still says about "lmpInsideCenter". |
|
|
Animation5.gif (19,580 bytes) |
|
|
Reproduce5.zip (3,730 bytes) |
|
|
I thought I had changed that... (did not save?). Anyway, should be fixed now. > For bar series, it is just 0 on the Y axis. Not necessarily. The bar series is freely configurable as a property. It divides the values in two groups: the bars for larger values are drawn upward, those for smaller values are drawn downward. |
|
|
I performed thorough tests, as you asked: Original problem: FIXED. In Reproduce.zip, left chart works ideally. Right chart's behavior is: when first data point is in the requested Y range, i.e. in <-1, +INF), then it is taken into account in margin calculation. Since first point's mark has 3 lines of text (second's has 1 line of text - i.e. less), a margin for 3 lines of text is added below -1, so first mark is fully visible. When first data point is BELOW the requested Y range, i.e. is below -1, then it is NO LONGER taken into account in margin calculation. So only the second data point is used in margin calculation, thus a margin for only 1 line of text is added below -1. As a consequence, first mark becomes partially invisible. As long as aditional margin for marks is applied unconditionally - i.e. is applied even when without it all marks would be still visible - this cannot be done better. So: fixed. Original problem (Note 1): FIXED. For MarkPositions = lmpInside, bevavior is still similar as described above. The behavior on the right chart is: when first point is in <-1, +INF), it is used in margin calculation, so a margin for 3 lines of text is added ABOVE the chart. When first point is below -1, it is NO LONGER used in margin calculation - since the second point doesn't have its mark ABOVE it, a margin for 0 lines of text is added above the chart - i.e. nothing is in fact added. The lmpInsideCenter is no longer available, but changing line series to bar series and setting MarkPositionCentered to True doesn't change anything (except marks' origins, of course). As long as aditional margin for marks is applied unconditionally - i.e. is applied even when without it all marks would be still visible - this cannot be done better. So: fixed. Original problem (Note 2): FIXED. Same as in the "Original problem" above - only vertically flipped. Original problem (Note 3): TO IGNORE. This was my mistake. Note 1-4: FIXED. The lmpInsideCenter is no longer available, but: - after changing lmpInsideCenter to lmpPositive, everything works properly, - after changing lmpInsideCenter to lmpNegative, everything works properly, - after changing lmpInsideCenter to lmpInside, everything works properly, - after changing line series to bar series and setting MarkPositionCentered to True, everything works properly. Note 5-6: FIXED. In all tested cases, axis marks don't disappear anymore. Note 7: FIXED. This was just a merging problem in the repository. Note 8: FIXED. "y" variable is properly initialized now. Note 9: FIXED. The boolean expression is as it should be now. Note 10: FIXED. FLoBound and FUpBound are used now. Note 11: FIXED. The lmpInsideCenter mode has been removed. Current TBasicPointSeries.GetLabelDirection() implementation works properly. Note 12: FIXED. Chart painting works properly now. Note 13: FIXED. Chart works properly now. Note 14: FIXED. Multiline marks are handled properly now - in EnsureGuaranteedSpace() etc. Note 15: NOTHING TO FIX - WORKS AS DESIGNED. All other problems described above have been moved to separate bug reports. |
|
|
According to above, this topic can be closed, at last. Please close if you have no objections. |
|
|
Some of the patches are contained in Laz 2.0.0, the rest will be backported to 2.0.2. |
|
|
So can we close this report? If so, please feel free to do this. |
|
|
Didn't I resolve it? Anyway, it is resolved now. Please close it to remove it from the usual lists. |
