JDK-8101458 : TableView perf when scrolling up and down
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: fx2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2011-06-06
  • Updated: 2016-09-30
  • Resolved: 2011-08-15
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.
Other
fx2.0Fixed
Related Reports
Relates :  
JDK-8166956 - JavaFX TreeTableView slow scroll performance
Description
 I did a quick test with the TableView: I created a table with 30 columns and 10000 lines, full of values. When I scroll up and down, the table has trouble keeping track of the current position and drawing appropriately. I can see that it is eating up CPU as well. Doing the same thing with a swing JTable, this was completely fluid. This leads to several questions:
- if I was not using prism, why is the JTable still looking better than the TableView? Is that a problem of optimization in the TableView
- is that a goal for the GA to optimize it in such a way that it (out?)performs at least to the level of the JTable?
- if I was using prism, will the TableView then compete with the JTable?

In short, what I have seen in terms of performance was disappointing, and I am wondering if this is just a matter of not using GPU, or if this is a problem with the control itself, or both. I would hope to have decent performances even without prism, because there old configurations out there, and I cannot tell everybody to change their graphic cards just to do some scrolling ion a table...
see comments: http://fxexperience.com/2011/06/indeterminate-checkbox/comment-page-1/#comment-20840

I attached a simple application that shows this issue
Comments
As i see for Win7, build 44, HelloTableView/Performance test behaves itself enough well. And there were no comments here for enough time, so i close this bug.
02-09-2011
Performance in TableView is considerably improved now. Further improvements can of course be considered for future releases - I have created RT-15975 to act as a catch-all for optimisation suggestions that can be targeted at Lombard (the next major release of JavaFX after JavaFX 2.0 / Presidio).
15-08-2011
A number of performance improvements were put into the b40 build that will become publicly available in the next few weeks.
09-08-2011
A lot of work throughout the JavaFX codebase has been going on recently to improve performance in situations such as those outlined in this report. Given the timing of this work and its pending integration into the mainline development branch, the results should start becoming visible in public builds around about b40 I would imagine. I'll post another comment here when there is more information.
22-07-2011
On behalf of Vince: Hi, I do not know if you need it, but here is the swing application I used to compare performances. It shows that 10000 rows by 30 lines is extremely fluid, as far as scrolling is concerned. even with just 4 columns, the javafx table is still a bit more sloppy than the full swing table. the sorting of the javafx table is slow too. to compare, I used this time a JXTable from the swing X project (version 0.9.1). the source is almost the same, except for those 2 lines: JXTable table = new JXTable(model); table.setSortable(true); regards.
07-06-2011
Performance is being severely impacted by the impl_processCSS(reapply) call occuring in TableCellSkin. Overriding and no-op'ing this method hugely improves performance. I will investigate this issue further with my team mate responsible for the CSS engine. Whilst researching this issue, I have also applied a number of smaller optimisations that help performance, but are neglible compared to the CSS issue mentioned previously.
07-06-2011
Thank you for such a good quality test app - it is clear that you've got a good grasp on both Java, and the newly released JavaFX 2.0 APIs. I can confirm that I can recreate the issue here, and after an initial inspection, can confirm that my initial thoughts were correct: the slow down is a function of the number of columns present in the Table. As the number of TableColumns increases, performance suffers. In fact, you can comment out the code responsible for populating each cell (the setDataRetriever call) - and performance is still poor. This matches my expectations: the peformance degradation is due specifically to the burden of laying out so many cells (each row consists of N columns and 1 row). There are clearly some inefficiencies here, and so I will now look into ways of improving this layout code to be more efficient. Thanks again.
07-06-2011
Another test case related to performance is resizing the pane with Windows "Show window contents while dragging" turned on. I updated the javafx application so that the table occupies the entire stage. resizing is smooth in swing, unlike in javafx. The root cause of the performance penalty is probably the same, but I thought it was worth mentionning. Regards, Vince
07-06-2011