RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4]

[John Hendrikx]

On Wed, 21 Jan 2026 12:54:51 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > 1. Pulse starts
> > 2. Pre-layout listeners called
> >    
> >    * View controls add/remove children, call `updateItem` based on their current size
> >      
> >      * `updateItem` can do whatever it wants, including modifying styles, adding/removing children, user code need not worry about layout semantics
> > 3. CSS pass
> > 
> > LAYOUT STARTS -- refrain from doing "more" work besides positioning/sizing
> > 
> > 4. Sizes get computed (by `resizeRootToPreferredSize`) down to leafs
> > 5. Layout methods are called (according to dirty status) down to leafs
> > 
> > LAYOUT ENDS
> > 
> > 6. Either during layout or in a post-layout listener, the View class discovers it did not have enough cells, it asks for a new layout
> > 7. After post layout listeners have run, check if another layout is needed immediately, go to step 2 (unless limit exceeded)
> > 8. Pulse ends
> > 
> > In this way we can prevent unnecessary layouts, and also prevent doing dangerous things during layout.
> 
> Could we streamline this process with e.g. a new protected method (initially empty / delegating to `skinBase`) that is called (instead of setting pre-layout listeners everywhere). Something like `prelayout()`. We then can start shifting update logic there for `Controls`, together as an Umbrella Task? 

I'm not sure having a `prelayout` method would be better. If we'd have to call it on the whole hierarchy (cascading down similar to `layout`) that could be a lot of calls.  If it would be limited to only `NEEDS_LAYOUT` nodes, then `prelayout` isn't quite equivalent (but perhaps sufficient).  I only expect the more complicated controls to need a pre-layout listener (the View classes).

Listeners are reasonably efficient (and targetted), they only suffer from one problem: removal can be slow if the amount of listeners on a single target is large (but IMHO that's a solvable problem).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3778625700