JDK-8163486 : NumberAxis: inaccurate rendering of ticks when tick unit is low
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8u20,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-08-09
  • Updated: 2020-01-31
  • Resolved: 2016-09-29
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.

To download the current JDK release, click here.
JDK 8 JDK 9
8u152Fixed 9Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Just a minor renderung issue.

JDK9 b129 + Windows 7, 10

Please run the attached test code. The ticks (y-axis) may look a bit irregular, especially when resizing the window (see the screenshot attached - "ticks_nok.png").

Please see also a notable gap before 100 for x-axis.

When setting some greater tick unit value (e.g., 10) the ticks look as expected
Comments
Changeset: b57ea923acdb Author: vadim Date: 2016-09-27 18:04 +0300 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/b57ea923acdb
29-09-2016

Approved to backport to 8u-dev for 8u122.
29-09-2016

+1
28-09-2016

The backport applies cleanly.
28-09-2016

We might consider a backport to 8u.
28-09-2016

I am fine with this change as it seems the earlier fix caused more problems than it solved. I do want to hear Jonathan's take on this. +1
28-09-2016

please see JDK-8166847
28-09-2016

Alexander, I'd like to address it in a separate bug if possible, it's unrelated issue and a result of another fix as I noticed above.
28-09-2016

should the fix affect not only the ticks but also the major tick labels (i.e. numbers)? because for now the numbers even for "3-good.png" (x-axis) look a bit sticked. "ticks_nok_2.png" is an example of the totally invalid behaviour. the expectation is the same: if the distance before the neighbouring numbers cannot be made adequate => do not render some labels (numbers)
28-09-2016

"a notable gap before 100 for x-axis." is a result of JDK-8097501 which is also debatable and should be fixed in another bug if desired. Before that fix the gaps were more even.
28-09-2016

I want to backout JDK-8094228. First, no minor tick marks looks better than the current situation. Second, if we are hiding some of them this may be seen as a contradiction to the minorTickCount property. http://cr.openjdk.java.net/~vadim/8163486/webrev.00/ I'm also attaching some screenshots. 1-base - this is how the chart looks when there are enough space for minor tick marks, which is identical in both version. 2-bad - decreased size of the chart shows the bug 3-good - after the backout
28-09-2016

Actually this was made by Martin on purpose in JDK-8094228. I'm not quite sure what is better - no minor tick marks if there are no space for all of them, or reducing the number of them. For me previous behavior was better.
27-09-2016

Thanks. So updating the goldens if the current BG color is correct.
11-08-2016

It's unclear for me if golden images are correct. I've checked attached test case with JDK 8 GA and the background is identical with jdk-9+130.
11-08-2016

please note also that background for the chart changed: test-expected.png (old golden): the BG's rgb is (255, 255, 255) test.png - the BG's rgb is (244, 244, 244) is it an expected change?
11-08-2016

the issue is even more notable on HiDPI: please see "HiDPI.png" - the scales are irregular here: x: 0, 2.5, 5, 7.5, 10, 15, 20, 25... y: 0, 25, 40, 55, 70, 85, 100 - this looks strange
09-08-2016

the issue is also reproducible on OS X 10.10. please compare also attached "test.png" and "test-expected.png" (golden image) - it seems that earlier the sub-ticks were probably not displayed when the scene dimensions are too low; so it could be a regression.
09-08-2016