Good to know that the problems I described don't apply to your use case. Regards, Tomas
On Thu, Nov 7, 2013 at 5:28 PM, John Hendrikx <hj...@xs4all.nl> wrote: > On 7/11/2013 14:08, Tomas Mikula wrote: >> >> On Thu, Nov 7, 2013 at 11:58 AM, John Hendrikx<hj...@xs4all.nl> wrote: >>> >>> Hm, I found it googling, and since it showed up here: >>> >>> >>> http://docs.oracle.com/javafx/2/api/javafx/scene/Scene.ScenePulseListener.html >>> >>> I figured it was public, but I just noticed the class is defined package >>> private. >> >> Although not part of the public API, you can use >> >> import com.sun.javafx.tk.TKPulseListener; >> import com.sun.javafx.tk.Toolkit; >> >> Toolkit.getToolkit().addSceneTkPulseListener(new >> TKPulseListener(){...}) >> >> >> Anyway, I don't think deferring property invalidation until the next >> pulse is very useful in general, for the following reasons: >> >> 1) It can lead to inconsistent observable state of your objects. >> Consider an object with properties p, q, where the value of q depends >> on the value of p, and consider changing the value of p. Now, right >> after >> p.set(x); >> returns, the state of the object is inconsistent until the next pulse, >> and this inconsistency is observable to the outside world. > > Well, in my case the properties being modified can immediately be queried > back (so appear consistent) -- there are no "dependent" properties > publically visible. What you donot see is that the underlying controls > (that you cannot access directly) will only get updated on the next pulse. > So my "TreePane" has two properties you can play with, and will either > immediately or on the next pulse update a child control (a TreeView). Since > you cannot access this TreeView directly you will not be able to see that > the update was deferred. > >> 2) It doesn't (in general) avoid recalculations. Consider properties >> p, q, r, s, whose invalidation listeners are deferred until the next >> pulse, with bindings >> p<- q<- r<- s >> p<- s >> and consider changing the value of p in pulse 0. The invalidation >> listeners will fire as follows: >> pulse 1: p >> pulse 2: q, s >> pulse 3: r >> pulse 4: s >> As you see, the listeners of s are called twice, causing potentially >> expensive recalculation. > > Not in this case -- the calculation I'm trying to avoid is the updating of > the internal TreeView -- modifying the externally visible properties > multiple times would trigger a recalculation each time in a simplistic > implementation as you have to update the underlying controls after each > modification. What I want to do is to avoid this and allow these external > properties to be modified as often as a user likes, but only update the > hidden underlying controls on each Pulse (when needed). This reduces the > number of calculations to one per pulse, instead of one per property > modification. > > --John > >
