Possible approaches to JDK-8185886: Improve scrolling performance of TableView and TreeTableView

[John Hendrikx]

I just want to quickly mention that option 3 
(https://github.com/openjdk/jfx/pull/185) is no longer a WIP -- all 
functionality is working all tests pass.

The PR creates a TreeShowingExpression class which encapsulates the tree 
showing logic that was in Node class.  This class is then only used by 
ProgressIndicatorSkin and PopupWindow.  This effectively means that 
instead of registering a listener on Window and Scene for all nodes 
they're only registered for those classes that need to know the showing 
status of a Scene.

--John

On 27/08/2020 02:17, Kevin Rushforth wrote:
> Sorry for the badly formatted html. Here it is again.
>
> I see some progress being made on the {Tree}TableView performance issue.
> To summarize where I think we are:
>
> There are currently 2 different approaches under review:
>
> 1. https://github.com/openjdk/jfx/pull/108 : optimization in javafx.base
> to make removing listeners faster
> 2. https://github.com/openjdk/jfx/pull/125 : optimization in TableView
> to reduce the number of add / removes
>
> In addition, the following is a WIP PR that the author thinks could be a
> 3rd approach:
>
> 3. https://github.com/openjdk/jfx/pull/185 : optimization in scene graph
> to avoid install treeShowing listeners on Window and Scene for all nodes
>
> Jose has proposed a 4th approach as a comment to PR #108, and as I
> understand it, he will propose a PR shortly.
>
> 4. Don't clear the list of children in a VirtualFlow when the number of
> items changes.
>
> So the first thing that is needed is to evaluate the approaches and
> decide which one to pursue.
>
> Options 1 and 3 are more broad in their scope, option #2 is more
> targeted (to TableView), but within that area is a larger change. Option
> #3 would remove the (internal) treeShowing property as a generally
> available concept and only use it for controls like ProgressIndicator
> that really need it. Option #4 affects only controls that use
> VirtualFlow (ListView, TableVIew, TreeTableView), and seems not to be a
> large change (presuming we can verify that no leak is introduced).
>
> I note that these fixes are not mutually exclusive, but I do think we
> need to settle on a primary approach and use that to fix this issue. If
> there are still performance problems after that fix, we can consider one
> (or more) of the others.
>
> Comments?
>
> -- Kevin
>