-
Notifications
You must be signed in to change notification settings - Fork 11.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix padding of horizontal axes when labels are rotated #6021
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
5aa6c63
use same heigth for horizontal axes in step 4 thats used in steps 5/6
kurkle abe74a6
a little refactoring
kurkle 5362045
renumbering, some minimization
kurkle 0345c93
Better minification (and certainly performance)
kurkle 075e61a
revert numbering, add a TODO in Step3
kurkle cd260d0
fix comment
kurkle File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason this used
horizontalBoxHeight
is that the sum of the heights of all the horizontal boxes needs to be capped atchartHeight / 2
so that there is room for the chart. Is it possible now to have the axes take up more space because we measure them at a bigger size?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its been like that for a long time already (
couldn't find the original change,more than 3 years ago from #1837)Also visible in both of the attached images, axes take more space than the chart.
Because that
horizontalBoxHeight
is not actually used in the final layout:Chart.js/src/core/core.layouts.js
Line 272 in abe74a6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me quite awhile to understand that
minSize
was anILayoutItem
and not anumber
. Maybe we could rename it to something clearer likeminBox
.chartHeight / 2
seems wrong. What if there are multiple axes? Does this value actually represent the minimum height or is ignored? Could we fix the oldhorizontalBoxHeight
rather than removing it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree there's room for improvement in these names.
It represents maximum height available for box, but I agree it seems wrong.
However, this was not something I was fixing, just the padding issue. I tried using
horizontalBoxHeight
instead in both places (makes more sense to me), but then issue #1766 reappears.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Basically we are now figuring out the minimum size of the horizontal box by using same maximum height available as in the final fit (=
chartHeight / 2
). I'd rather not change thechartHeight / 2
now, unless there is a issue that relates to it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be
chartHeight / 2 / verticalBoxes.length
though? I don't understand why we can start ignoring how many axes there areThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had the same concern as @benmccann, but the vertical boxes include the title and legend boxes, and they don't always require
horizontalBoxHeight
, so the calculation of the label rotation might not work as expected if we usehorizontalBoxHeight
asmaxHeight
inupdate
. With the proposed solution, if there are multiple axes and each axis has long labels, the total height might exceed the chart height. I wonder if we can say it's an ignorable edge case.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could ignore that edge case for now. When I wrote this code the first time I wasn't considering the case of multiple horizontal axes and mostly wanted to support multiple vertical axes since that was a common use case. I think that also explains
chartHeight/2
more because with 1 horizontal axis splitting the height in 2 seemed like a reasonable step.In v3 I think I'd like to explore splitting the
fit
function into 2 separate methods:measure
andarrange
. This matches the patterns I've seen in a number of other systems, such as WPF and it means we can keep a difference between callingfit
to get a size and callingfit
to actually setup the internals.If the split into 2 separate methods goes well and we could get
measure
performing well, we could rethink the core layout algorithm. Having 2 passes was a compromise between a slow iterative algorithm that kept looping until boxes didn't change much in size and a single pass algorithm that just assigned sizes based on heuristics.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That 2-pass approach makes a lot of sense to me. I'm fine with the solution in this PR for now, and the refactoring is so good.