jfx
jfx copied to clipboard
8334900: IOOBE when adding data to a Series of a BarChart that already contains data
This PR is a fix for another IOOBE that I discovered while working on #1476.
The PR simplifies the code for adding a series that already contains data by adding the data points one-by-one. As far as I can see no attempt was previously made to optimize the bulk operation except for some trivial O(1) operations, so this should have no noticable performance impact.
Accidentally this fixes another bug related to the missing "negative" style class when negative data values are added.
Also, the PR aligns the handling of duplicate categories with the behavior clarified in #1476, when there are duplicates in the data that was already in the series before the series was added to the chart.
Note a change was made to the createTestSeries() test method, letting it start at index 1, avoiding the duplicate data items resulting from multiplying by 0.
Without this change testSeriesRemoveAnimatedStyleClasses would fail because it counts the number of plot children, where the duplicates are now removed.
Progress
- [ ] Change must be properly reviewed (1 review required, with at least 1 Reviewer)
- [x] Change must not contain extraneous whitespace
- [x] Commit message must refer to an issue
Issues
- JDK-8334900: IOOBE when adding data to a Series of a BarChart that already contains data (Bug - P4)
- JDK-8334901: Style class "negative" is not always added for new BarChart data with negative value (Bug - P4)
Reviewers
- Michael Strauß (@mstr2 - Committer)
Reviewing
Using git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1488/head:pull/1488
$ git checkout pull/1488
Update a local copy of the PR:
$ git checkout pull/1488
$ git pull https://git.openjdk.org/jfx.git pull/1488/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1488
View PR using the GUI difftool:
$ git pr show -t 1488
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1488.diff
Webrev
:wave: Welcome back mmack! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.
/issue add JDK-8334901
@drmarmac This change now passes all automated pre-integration checks.
ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.
After integration, the commit message for the final commit will be:
8334900: IOOBE when adding data to a Series of a BarChart that already contains data
8334901: Style class "negative" is not always added for new BarChart data with negative value
Reviewed-by: mstrauss, angorya
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.
At the time when this comment was updated there had been 3 new commits pushed to the master branch:
- a8f7850503043f616703fdfc8d0a26a00f47b7c8: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set
- dc8f607e4ce95e348bb812a1c942e4321c00f0f8: 8336941: Update libxslt to 1.1.42
- 00c74ebf96cbe24b833cb51d2ee533e69396c846: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image
Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mstr2, @andy-goryachev-oracle) but any other Committer may sponsor as well.
➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).
@drmarmac
Adding additional issue to issue list: 8334901: Style class "negative" is not always added for new BarChart data with negative value.
Webrevs
@drmarmac this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:
git checkout fixes/bar-chart-add-nonempty-series
git fetch https://git.openjdk.org/jfx.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push
@drmarmac You need to merge the latest upstream master and fix the merge conflicts before this can proceed.
Reviewers: @andy-goryachev-oracle @mstr2
/reviewers 2
@kevinrushforth The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).
I've updated to the current master branch.
I don't see the 'negative' style added to negative bars. I do see BarChart:261 being hit, but nothing in the scene graph.
Tested with the Monkey Tester and double checked with Scenic View 11.0.2:
good catch, that was another situation where the "negative" style class was not added when adding a series that already contains data (which is the situation when the IOOBE occured). I fixed this in the relevant place, did some more code deduplication, and added another unit test.
I am going to ask this question - unrelated to this PR, but in the context of this PR.
Consider the case of a context menu, where the application needs to know the data point from the screen/local coordinates.
Currently, we can get the Node from the Data instance (XYChart.Data.node property), but not the other way around - that is, given the chart, and given the PickResult of a MouseEvent, it is impossible to get the data point corresponding to a Node. In other words, we have the model->view path but not the view->model one.
In theory, the app developer could monitor the node property of Data and use Node.getProperties() map to set the Data instance on the node, or they could iterate through all the visible data points, matching the node with the data point, so it is not a big issue.
I am interested in your opinion. What do you think?
I've added asserts verifying that the "negative" style class is added to the relevant tests, plus a new test to assert it is removed when data is changed.
I am going to ask this question - unrelated to this PR, but in the context of this PR.
Consider the case of a context menu, where the application needs to know the data point from the screen/local coordinates.
Currently, we can get the Node from the Data instance (XYChart.Data.node property), but not the other way around - that is, given the chart, and given the PickResult of a MouseEvent, it is impossible to get the data point corresponding to a Node. In other words, we have the model->view path but not the view->model one.
In theory, the app developer could monitor the
nodeproperty of Data and useNode.getProperties()map to set the Data instance on the node, or they could iterate through all the visible data points, matching the node with the data point, so it is not a big issue.I am interested in your opinion. What do you think?
Good question, I'd say it is easy enough to loop through the chart's data items to find the correct node in that case, so I don't see a need to add this on the jfx side. Also, currently Data.getNode() just returns an opaque Node, so I don't see a good place where to expose that without either changing that API. Adding an Node.getProperties() entry should probably be done only by application developers.
/integrate
@drmarmac Your change (at version ed5d9c2a50d02fb1eb3d974b4a81da6ca035a7ba) is now ready to be sponsored by a Committer.
/sponsor
Going to push as commit 338b1f3a1cff64f8eceb140015fec232f21234eb.
Since your change was applied there have been 3 commits pushed to the master branch:
- a8f7850503043f616703fdfc8d0a26a00f47b7c8: 8289174: JavaFX build fails on Windows when VS150COMNTOOLS is not set
- dc8f607e4ce95e348bb812a1c942e4321c00f0f8: 8336941: Update libxslt to 1.1.42
- 00c74ebf96cbe24b833cb51d2ee533e69396c846: 8333919: [macOS] dragViewOffsetX/dragViewOffsetY are ignored for the dragView image
Your commit was automatically rebased without conflicts.
@mstr2 @drmarmac Pushed as commit 338b1f3a1cff64f8eceb140015fec232f21234eb.
:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.