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
