Use ScenePulseListener to avoid expensive recalculations?

[John Hendrikx]

On 7/11/2013 14:08, Tomas Mikula wrote:
> On Thu, Nov 7, 2013 at 11:58 AM, John Hendrikx<hjohn at 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