Proposal: Invalidation mechanism for redrawing/recalculating in custom components

[Yennick Trevels]

@Richard yes, the prefWidth and prefHeight would be calculated in the
measure() method (so in a pulse) and requestLayout is like
invalidateDisplayList.
I knew there was some sort of pulse mechanism, but didn't know this was
something developers could use (i.e. it was more of an internal thing). So
if it's possible to manually schedule a pulse then this would probably
cover the problem I described.


On Tue, Dec 18, 2012 at 7:59 AM, Tom Eugelink <tbee at tbee.org> wrote:

>
> 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
>