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

heuristic to prevent tick occlusion #75

Closed
wants to merge 1 commit into from
Closed

heuristic to prevent tick occlusion #75

wants to merge 1 commit into from

Conversation

Fil
Copy link
Contributor

@Fil Fil commented Dec 23, 2020

Addressing #74: when we have too many ticks on an axis, occlusion makes the whole axis unreadable. This heuristic tries to skip ticks when there are too many of them.

In the first iteration of this PR there is no way to disable the function—but maybe we should avoid anything "smart" if the ticks are set explicitly?

Related: #72

The magic numbers (1.5 and 6.5) were chosen so that that select a value of about 10 pixels between lines (on a yAxis).

Some examples :

Enregistrement.de.l.ecran.2020-12-23.a.17.19.27.mov

Capture d’écran 2020-12-23 à 17 20 30

Capture d’écran 2020-12-23 à 17 20 24

Capture d’écran 2020-12-23 à 17 21 46

@Fil Fil changed the title an heuristic to prevent tick occlusion heuristic to prevent tick occlusion Dec 23, 2020
@mbostock
Copy link
Member

mbostock commented Dec 27, 2020

I appreciate you taking a crack at this. I was thinking of something simpler (dumber) and more targeted for #74. Specifically:

I want only to address the issue with ordinal scales; for quantitative scales, you can already adjust the number of ticks easily, and it has a reasonable default strategy based on the plot width. The issue with ordinal scales — or at least, categorical scales — is that the axis may no longer be meaningful if you only show a subset of ticks. For example, imagine in the video you posted the bars are sorted by descending length; if you only labeled every other bar, there’d be no way to tell what the unlabeled bars mean. Whereas with a quantitative scale, you can infer the meaning from the adjacent ticks. Further, showing labels for some arbitrary ordinal values would make them more important than the unlabeled values.

I’d also prefer to have the heuristic based solely on the number of ticks, without looking at the text itself. Eventually we may want to consider occlusion, but I want to get as far as we can with simpler approaches.

Here’s my suggestion for a simpler strategy: if x or y is an ordinal scale, and a fixed number of ticks are desired (the default per autoAxisTicks, i.e., no explicit array of tick values is specified), and the actual number of ticks is greater than 5 times this amount (or similar constant to be determined), then hide the tick labels. Note that this strategy implicitly provides a way to ensure that all ordinal ticks are shown by setting the desired tick count to infinity (or the cardinality of the domain).

@Fil
Copy link
Contributor Author

Fil commented Dec 28, 2020

Agree that looking at the text's width is premature: in particular, the text labels would often be rotated (by 45° or 90°), a situation which I didn't anticipate here.

I applied the logic at this very late stage because I thought it should be based on the actual space available (the bandwidth is decided only after the scale's range is set). But I'm fine with taking the simpler route to avoid "total clutter"—the more complex route can always be added with some sort of "callback" (either on the plot itself or with something like #67 ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants