JDK-8166847 : NumberAxis: sticked numbers sometimes
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
segregating from JDK-8163486
Win. 7, JDK9 b136
Please run the attached test code and try to resize the stage => sometimes the x-axis coordinate labels are sticked (see "nok.png") making the coordinate values unreadable
Approved to backport to 8u-dev for 8u122.
I'd like to backport this to 8u.
Backport applies cleanly.
Please review this fix:
The first part is reverting the part of the fix for JDK-8097501, that is checking for overlap for individual labels.
Instead as before that fix we calculate maximum label size and check if the total labels size (as if all of them are maximum size) exceeds the length of the axis.
If it is, then we throw away every n-th label.
I've also simplified that code so we call setPosition while creating tick marks, there is only one loop, and the logic dependent on which side is the axis was extracted to the double measureTickMarkSize(T value, Side side) method.
The second part addresses the issue mentioned in the last couple of comments in the JDK-8097501, where overlapping would be possible if bounds are not integer, but the tick unit is.
So there can be a situation where we have lower bound tick (and label) and the next integer tick and they can overlap.
So I introduced the isTickLabelsOverlap method and I only use it to check bounds labels.
I can say that it is in fact reproducible on 8u starting from 8u20
[~avstepan] If this is the result of the fix for JDK-8097501 then it should also reproduce in a recent JDK 8u version. Can you check and comment?
if the issue is a result of the fix for JDK-8097501 (mentioned in JDK-8163486 comments), then at least some part of the changes should probably be reverted to return to the normal state