[GH-ISSUE #121] Support anchoring or lazy-resize of the Y axis #81

Closed
opened 2026-03-03 16:22:11 +03:00 by kerem · 4 comments
Owner

Originally created by @mum4k on GitHub (Feb 13, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/121

Discussion started in #55.

This is useful for linecharts that continuously pipe data in. By default the scale of the Y axis continuously adjusts according to the currently available min and max value in the presented data set. This can be visually unpleasant and disturbing.

Two options to consider:
Option 1
We could provide an option that let's the caller specify the min and max values of the Y axis, effectively fixing the scale.

Advantages:

  • Easy to implement.

Disadvantages:

  • Requires the caller to know all the data that is to come, which might be impossible for monitoring. If values outside of the specified range arrive, the line showing the series would become invisible.

Option 2
We could implement sort of a "lazy increase" on the Y axis. The scale would still be dynamic, but after the linechart was created it will only increase when it encounters a larger maximum or a smaller minimum. It would never decrease and would be stable for values that fall within the adjusted min-max.

Advantages:

  • While giving visual stability, the linechart is still able to display new maximums and minimums.

Disadvantages:

  • For long-running linecharts, the min and max range will just keep increasing, eventually being so large that we lose all visible details on the line showing the series.

Thoughts? Other options?

Originally created by @mum4k on GitHub (Feb 13, 2019). Original GitHub issue: https://github.com/mum4k/termdash/issues/121 Discussion started in #55. This is useful for linecharts that continuously pipe data in. By default the scale of the Y axis continuously adjusts according to the currently available min and max value in the presented data set. This can be visually unpleasant and disturbing. Two options to consider: **Option 1** We could provide an option that let's the caller specify the min and max values of the Y axis, effectively fixing the scale. Advantages: - Easy to implement. Disadvantages: - Requires the caller to know all the data that is to come, which might be impossible for monitoring. If values outside of the specified range arrive, the line showing the series would become invisible. **Option 2** We could implement sort of a "lazy increase" on the Y axis. The scale would still be dynamic, but after the linechart was created it will only increase when it encounters a larger maximum or a smaller minimum. It would never decrease and would be stable for values that fall within the adjusted min-max. Advantages: - While giving visual stability, the linechart is still able to display new maximums and minimums. Disadvantages: - For long-running linecharts, the min and max range will just keep increasing, eventually being so large that we lose all visible details on the line showing the series. Thoughts? Other options?
kerem 2026-03-03 16:22:11 +03:00
Author
Owner

@keithknott26 commented on GitHub (Feb 14, 2019):

Would it be possible to combine option 1 and option 2? Where the user can set the min/max up front but then if a higher value is encountered the scale would change dynamically, currently (and formerly with termUI based termeter) I was defeating the auto scaling similar to option 1 by simply injecting the max value (of all values) as the first value in the series so that the graph wouldn't encounter a higher value (and continually redraw the scale). In my case, I am recreating the series over and over to move the graph from right to left so it would be ideal if the linechart could accept a specified max value but also "learn" the value for streaming applications.

I can definitely see the value in both methods. As it turned out it was difficult to see overall data trends when the graph was scrolling right to left, when the scale was continually changing. Keeping track of the max or min value would be pretty easy to implement outside of the line chart too, provided the linechart had that option. In most cases, I'll know the maximum value but when streaming data as you point out, the max value wouldn't be known but it could be estimated. If I don't specify the max value, I am facing the problem you mention where the scale adjusts too frequently (since the series changes so often).

Hope this helps!

<!-- gh-comment-id:463437120 --> @keithknott26 commented on GitHub (Feb 14, 2019): Would it be possible to combine option 1 and option 2? Where the user can set the min/max up front but then if a higher value is encountered the scale would change dynamically, currently (and formerly with termUI based termeter) I was defeating the auto scaling similar to option 1 by simply injecting the max value (of all values) as the first value in the series so that the graph wouldn't encounter a higher value (and continually redraw the scale). In my case, I am recreating the series over and over to move the graph from right to left so it would be ideal if the linechart could accept a specified max value but also "learn" the value for streaming applications. I can definitely see the value in both methods. As it turned out it was difficult to see overall data trends when the graph was scrolling right to left, when the scale was continually changing. Keeping track of the max or min value would be pretty easy to implement outside of the line chart too, provided the linechart had that option. In most cases, I'll know the maximum value but when streaming data as you point out, the max value wouldn't be known but it could be estimated. If I don't specify the max value, I am facing the problem you mention where the scale adjusts too frequently (since the series changes so often). Hope this helps!
Author
Owner

@mum4k commented on GitHub (Feb 14, 2019):

Thank you for providing the opinion, I think your solution is the best.

This too is fairly simple to implement, so I can target it into the the next release.

<!-- gh-comment-id:463473349 --> @mum4k commented on GitHub (Feb 14, 2019): Thank you for providing the opinion, I think your solution is the best. This too is fairly simple to implement, so I can target it into the the next release.
Author
Owner

@mum4k commented on GitHub (Feb 15, 2019):

This is now available in the devel branch.

<!-- gh-comment-id:463903027 --> @mum4k commented on GitHub (Feb 15, 2019): This is now available in the devel branch.
Author
Owner

@mum4k commented on GitHub (Feb 15, 2019):

To be noted - this came with a breaking change to the LineChart API, the constructor now also returns an error.

Related to #111

<!-- gh-comment-id:463911181 --> @mum4k commented on GitHub (Feb 15, 2019): To be noted - this came with a breaking change to the LineChart API, the constructor now also returns an error. Related to #111
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/termdash#81
No description provided.