Use ScenePulseListener to avoid expensive recalculations?

[Tomas Mikula]

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 <hjohn at xs4all.nl> wrote:
> 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
>
>