RFR: 8185886: Improve scrolling performance of TableView and TreeTableView

yosbits github.com+7517141+yososs at openjdk.java.net
Tue Mar 10 06:10:34 UTC 2020


On Mon, 2 Mar 2020 11:47:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>>> 
>>> 
>>> I think that a starting point would be to decide on a spec for the listener notification order: is it specified by
>>> their registration order, or that is it unspecified, in which case we can take advantage of this for better
>>> performance. Leaving is unspecified and restricting ourselves to having it ordered is losing on both sides.
>> 
>> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time
>> (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically,
>> we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing
>> it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin
>> has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal
>> code does it ..
>
>> technically true - but the implementation was linear with a fixed sequence since-the-beginning-of-java-desktop-time
>> (and sometimes, for good ol' beans properties, even exposed as api to access the array of listeners). So technically,
>> we could go the path of explicitely spec'ing that the order is unspecified. Pretty sure that doing so and implementing
>> it will break tons of application code that's subtly relying on fifo notification (f.i. register before or after skin
>> has its own is a simple wide-spread trick) .. which all did it wrong and might deserve it ;-) But then if even internal
>> code does it ..
> 
> So we can choose to specify it as ordered.
> 
> These are the 2 options I mentioned:
> 1. Not specify the behavior and change the implementation in favor of performance. This could break applications as
> you've mentioned. 2. Specify that the order is preserved and keep the ordered implementation behavior. This will allow
> applications to rely on the behavior safely.
> Right now we're losing on both sides. We keep a promise and we don't tell anyone about it. The only reason for this is
> if we intend to change the behavior in the future, in which case we should add a doc comment saying that the order is
> unspecified and is planned to change in the future, so there will be at least some warning.  Once we choose what to do
> here it will make sense to continue to review the code with that decision in mind.

In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce
the performance improvement. I have attached a test program in my PR(#125)

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

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


More information about the openjfx-dev mailing list