[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: 8185886: Improve scrolling performance of TableView and TreeTableView
From:       yosbits <github.com+7517141+yososs () openjdk ! java ! net>
Date:       2020-02-27 3:19:27
Message-ID: mT-H7MSOQZbeF7YK0OWJBkaRGs7VW-UF-tMjK8EmdUo=.713e44d9-68d8-47c9-b07f-6425d7a57b44 () github ! com
[Download RAW message or body]

On Wed, 26 Feb 2020 10:07:02 GMT, Jeanette Winzenburg <fastegal@openjdk.org> wrote:

> > Hmm .. personally, I would consider changing such a basic (and probably highly \
> > optimized) implementation used all over the framework is a very high risk change \
> > that at the worst outcome would detoriate internal and external code. So before \
> > going that lane, I would try - as you probably have, just me not seeing it :) - \
> > to tackle the problem from the other end: 
> > > I know that in our application, the **thousands of listeners** unregistering \
> > > when using a TableView was stalling the JavaFX thread. 
> > 
> > .. sounds like a lot. Any idea, where exactly they come into play?
> 
> > 
> > 
> > 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 ..

In use cases where a large number of listeners are being discarded, it may be better \
to first consider changing the design to receive event notifications on nodes whose \
listener registrations are not frequently discarded.

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

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


[prev in list] [next in list] [prev in thread] [next in thread]