RFR: 8185886: Improve scrolling performance of TableView and TreeTableView

[dannygonzalez]

On Thu, 16 Apr 2020 07:34:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Looking at the commit  https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd
>>  it seems that the long listener lists are actually part of the `Scene`'s `Window` property and the `Window`'s `Showing`
>>  property.  Each `Node` registers itself on those and so the listener lists for those properties would scale with the
>>  number of nodes.
>> 
>> A test case showing this problem would really be great as then the patch can also be verified to solve the problem, but
>> I suppose it could be reproduced simply by having a large number of Nodes in a scene.  @dannygonzalez could you give us
>> an idea how many Nodes we're talking about?  1000? 10.000?  It also means there might be other options, do Nodes really
>> need to add these listeners and for which functionality and are there alternatives?  It would also be possible to
>> target only these specific properties with an optimized listener list to reduce the impact of this change.
>
> The listeners added by `Node` are apparently internally required for internal properties `TreeShowing` and
> `TreeVisible`, and are used to take various decisions like whether to play/pause animations.  There is also a couple of
> listeners registering on these properties in turn (in `PopupWindow`, `SwingNode`, `WebView` and `MediaView`).  A lot of
> the checks for visibility / showing could easily be done by using the `Scene` property and checking visibility /
> showing status from there.  No need for so many listeners.  The other classes mentioned might register their own
> listener, instead of having `Node` do it for them (and thus impacting *every* node).  Alternatively, `Node` may lazily
> register the listeners for Scene.Window and Window.Showing only when needed (which from what I can see is for pretty
> specific classes only, not classes that you'd see a lot in a TableView...)

If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the ExpressionHelper.removeListener is using
61% of the JavaFX thread whilst running our application.

[snapshot-1587024308245.nps.zip](https://github.com/openjdk/jfx/files/4485728/snapshot-1587024308245.nps.zip)

If you show only the JavaFX Application thread, press the "HotSpot" and "Reverse Calls" button you can take a look to
see which classes are calling the removeListener function.

![Screenshot 2020-04-16 at 09 16
11](https://user-images.githubusercontent.com/6702882/79432046-2f788800-7fc3-11ea-930a-98fed0190628.png)

-------------

PR: https://git.openjdk.java.net/jfx/pull/108