Proposal: Invalidation mechanism for redrawing/recalculating in custom components

[Tom Eugelink]

On 2012-12-17 23:39, Richard Bair wrote:
>> What the invalidateDisplayList method exactly does is schedule a call to
>> the updateDisplayList method during the next frame, therefore avoiding
>> multiple calls to updateDisplayList when setSelectedItem and setDefault are
>> being called right after each other.
>> This mechanism becomes even more useful when part of the redraw code is
>> being shared between _selectedItemChanged and _defaultChanged.
> Internally we do a similar thing in many cases -- batch changes up until the next pulse. Sometimes this leads to confusion (for example, CSS is applied once per pulse, so people are surprised when they ask for the size of a Button and find it is 0x0 -- because CSS / Layout haven't happened yet, until after the first pulse when it magically gets a size). But we have a JIRA I think about exposing the pulse listener mechanism for batching things up. Another option is an AnimationTimer which fires off once per pulse.
>

As I understand it:

This will only become a problem when things are involved that are triggered in a pulse. In case of the example (selected and changed) both properties are "autonomous"; they are set, events are fired and reacted upon, other properties are set, and the whole logic can be completed before the next pulse. In the next pulse the visual consequences are rendered, all at once.

It becomes a different scenario where the properties slide into the drawing area and the pulse itself triggers events, which with lazy properties is not uncommon or with the size like described above. Then a pulse itself will lead to events and modifications, which may trigger changes that are drawn in the next pulse, etc. As I understand it, this is the reason why JavaFX itself does not use binding a lot, but rely on "old fashion" chained rendering code, so as many properties as possible are updated in the same run. Maybe this pulse stumbling behavior should get a name.

So there is a trade off. In JFXtras' Agenda binding is used, because it makes the code cleaner and it uses absolute layout (less by the pulse calculated values). And I figure that such a control is not use in high speed animations, where such a pulse stumbling would be a problem.

So as I understand it, your problem is already tackled by the pulses, but replaced with another.

Tom