Skip to content
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 overlapping auto-generated ticks on time scale #6115

Merged
merged 4 commits into from
May 9, 2019

Conversation

kurkle
Copy link
Member

@kurkle kurkle commented Mar 6, 2019

Account for margins in getLabelCapacity

tick-overlap

Pen PR
Pen master

Fixes: #6109

@kurkle
Copy link
Member Author

kurkle commented Mar 6, 2019

Updated solution, use margins (provided here) instead of -1

@simonbrunel simonbrunel modified the milestone: Version 2.8 Mar 6, 2019
@simonbrunel simonbrunel requested a review from nagix March 6, 2019 11:09
src/core/core.scale.js Outdated Show resolved Hide resolved
@nagix
Copy link
Contributor

nagix commented Mar 6, 2019

#5961 addresses the same issue in

// Estimate the width of each grid based on the canvas width, the maximum
// label width and the number of tick intervals
maxWidth = Math.min(me.maxWidth, me.chart.width - maxLabelWidth);
tickWidth = options.offset ? me.maxWidth / ticks.length : maxWidth / (ticks.length - 1);
// Allow 3 pixels x2 padding either side for label readability
if (maxLabelWidth + 6 > tickWidth) {
tickWidth = maxWidth / (ticks.length - (options.offset ? 0.5 : 1));

@nagix
Copy link
Contributor

nagix commented Mar 6, 2019

I think it is difficult to get tickWidth without knowing the maximum width of tick labels because the left and right padding are added based on it.

@kurkle
Copy link
Member Author

kurkle commented Mar 6, 2019

Limited this change to getLabelCapacity, so we don't have overlap in PR's.

@nagix
Copy link
Contributor

nagix commented Mar 6, 2019

Well, I see... this is called before calculateTickRotation and timestamp ticks are generated so as not to overlap each other or to be rotated.

src/scales/scale.time.js Outdated Show resolved Hide resolved
@simonbrunel simonbrunel added this to the Version 2.9 milestone Mar 12, 2019
@kurkle kurkle closed this Apr 1, 2019
@simonbrunel
Copy link
Member

@kurkle this PR looks fine, should we get it merged?

@kurkle

This comment has been minimized.

@kurkle kurkle reopened this Apr 25, 2019
etimberg
etimberg previously approved these changes Apr 26, 2019
@benmccann
Copy link
Contributor

@kurkle this PR will need to be rebased

Copy link
Contributor

@benmccann benmccann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too many labels are currently being generated because padding is not being considered when generating the labels and then padding is calculated later.

The right solution to this is to probably to calculate those values together or set a maximum padding value and use that here. I don't think the solution is to use some other value in place of padding. It seems like we're just getting lucky that's working out, so I would want to see more explanation around why that's the right thing to do.

scaleMargin is defined as:

var scaleMargin = {
	left: Math.max(outerBoxSizes.left, maxPadding.left),
	right: Math.max(outerBoxSizes.right, maxPadding.right),
};

maxPadding isn't really correct because we should use the padding for this scale and not the maximum padding of all the scales. I think maybe maxPadding is 0 at this point in the code? outerBoxSizes is defined as helpers.options.toPadding(layoutOptions.padding); though the default layout.padding is 0 so it doesn't seem like that should have an effect either. The layout and tick generation/rotation code is quite convoluted and I'm afraid this is making it harder to understand

I have a branch on my machine locally that is replacing the whole autotick generation for the time scale as suggested by @simonbrunel and described in #4612. I think it would fix the issue this is addressing. I haven't been very motivated lately to open new PRs though because it seems like there's a backlog of unreviewed PRs and if I open new PRs it's just going to push my controller defaults PR further down the list and make it take longer to get it merged. In either case I still have a few more edge cases I need to fix before sending

exwm pushed a commit to exwm/Chart.js that referenced this pull request Apr 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Overlapping labels on x axis
6 participants