[announce] InhiBeans: mitigate redundant recalculations

Tom Eugelink tbee at tbee.org
Mon Dec 16 04:12:00 PST 2013

Point made.


On 2013-12-16 12:17, Tomas Mikula wrote:
> On Mon, Dec 16, 2013 at 7:56 AM, Tom Eugelink <tbee at tbee.org> wrote:
>> I understand what you are trying to do. I was wondering if a more coarse
>> grained approach would be preferable, so a central registration of whether
>> or not to postpone change events.
>> So:
>> Central.postponeAllChangeEvents()
>> Central.resumeAllChangeEvents()
>> Or maybe both:
>> p.postponeChangeEvents()
>> p.resumeChangeEvents()
>> I also foresee some unexpected behavior; suppose you have two properties
>> bound bidirectionally. You set 1 on the first and 2 on the second, in the
>> end both properties will be set to 2. Now you postpone change events and do
>> the same, the end value depends on the order in which the components are
>> resumed; if first component "2" is resumed its change event is fired before
>> "1" so in the end the properties will be set to 1. If there were a central
>> toggle and postponed events were registered to that central toggle, than
>> resuming events would "play back" the events in the same order they
>> happened.
>> Just some considerations.
>> Tom
> Hi Tom,
> global postpone/resume defeats the original goal of avoiding multiple
> change events. Consider
> Central.postponeAllChangeEvents();
> obj.setWidth(w);
> obj.setHeight(h);
> Central.resumeAllChangeEvents();
> Now, if the changes are replayed, the width change causes one change
> of the area property, and height change another one.
> You are right about the problem with bidirectionally bound properties.
> I don't know all the useful use cases for bidirectional bindings (I
> never used them personally), but it might as well be the case that the
> scenario you described never happens. InhiBeans are intended for
> internal implementation of a component. Only the component itself
> would call block()/release(). These methods aren't even available to
> the client of the component without downcasting the properties.
> Methods of the component can call block() internally, but should
> release() before returning.
> Regards,
> Tomas
>> On 2013-12-16 0:39, Scott Palmer wrote:
>>> Good stuff!   This is the sort of thing that might make a good
>>> contribution
>>> to extend the standard Bindings class.
>>> Scott
>>> On Sun, Dec 15, 2013 at 5:49 PM, Tomas Mikula
>>> <tomas.mikula at gmail.com>wrote:
>>>> On Sun, Dec 15, 2013 at 6:39 PM, Scott Palmer <swpalmer at gmail.com> wrote:
>>>>> Interesting idea.
>>>>> There is a case I have been curious about and wonder what the best
>>>> practices
>>>>> are for it.  Suppose you have a case when you are changing multiple
>>>>> different properties that will be used in a single calculation.  You
>>>> want to
>>>>> deal with a single change to all of them in one go.  E.g. imagine you
>>>> have
>>>>> an "area" property that is bound to both "width" and "height".  You want
>>>> to
>>>>> write code like:
>>>>> obj.setWidth(w);
>>>>> obj.setHeight(h);
>>>>> and have only ONE recalculation of the area property happen.  Currently
>>>> the
>>>>> way bindings work the area will be calculated twice.  The intermediate
>>>>> calculation is really not a value that you ever want to observe.
>>>> Hi Scott,
>>>> this is precisely the problem that I'm trying to address here. Now,
>>>> the question is whether you have control over the implementation of
>>>> obj.
>>>> If yes, then it is the same case as the AND gate "motivational
>>>> example" from InhiBeans page. You provide a method setSize(w, h) and
>>>> use block()/release() to implement it in a way that causes only one
>>>> change of the area property.
>>>> If you cannot change the implementation of obj, what you can do is to
>>>> bind an inhibeans.binding.DoubleBinding to the "area" value, call it
>>>> relaxedArea, and listen to that one for all your purposes.
>>>> Then you resize obj like this:
>>>> relaxedArea.block();
>>>> obj.setWidth();
>>>> obj.setHeight();
>>>> relaxedArea.release();
>>>> Only one change of relaxedArea is emitted.
>>>> Best,
>>>> Tomas
>>>>> Are there helpers for this sort of situation?  Are there guidelines in
>>>> the
>>>>> JavaFX docs somewhere?
>>>>> Regards,
>>>>> Scott
>>>>> On Sat, Dec 14, 2013 at 11:54 PM, Tomas Mikula <tomas.mikula at gmail.com>
>>>>> wrote:
>>>>>> Hello,
>>>>>> I just published a small extension of javafx bindings and properties
>>>>>> that can help you reduce redundant recalculations.
>>>>>> They provide two additional methods:
>>>>>> public void block();
>>>>>> public void release();
>>>>>> Call p.block() when you suspect your actions will lead to multiple
>>>>>> invalidations of p, and call p.release() when you are done and want to
>>>>>> deliver a single invalidation notification to p's observers.
>>>>>> https://github.com/TomasMikula/InhiBeans
>>>>>> Regards,
>>>>>> Tomas

More information about the openjfx-dev mailing list