<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">I also like the idea.<br>This is indeed something I also saw when debugging JavaFX. </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">And something I saw when looking into the VirtualFlow, which is the only class (beside Region) that uses setNeedsLayout(..) to improve the performance (and I was wondering why it only used there).<br>I really wonder if this will improve performance for Controls like (Tree)TableView, which can be quite complex and therefore slow under some circumstances. <br>Looking forward to the PR!</span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;"> </span></div>
<div style="font-family: 'verdana'; font-size: 12px; color: #000;"><span style="background-color: #ffffff;">-- Marius</span></div>
<div id="sub-body-container" style="margin: 10px 5px 5px 10px; padding: 10px 0px 10px 10px; border-left: 2px solid rgb(195, 217, 229);">
<div style="margin: 0px 0px 10px;">
<div><strong>Gesendet: </strong>Montag, 14. April 2025 um 17:56</div>
<div><strong>Von: </strong>"John Hendrikx" <john.hendrikx@gmail.com></div>
<div><strong>An: </strong>"openjfx-dev@openjdk.org" <openjfx-dev@openjdk.org></div>
<div><strong>Betreff: </strong>Unnecessary layouts; TLDR; new method "requestLocalLayout"</div>
</div>
I've been writing a container that does layout, and I've been using it<br>extensively in my latest project.<br><br>I noticed that many skins and controls will call requestLayout(), not<br>realizing that this will mark the current node + all parent nodes with<br>`NEEDS_LAYOUT`.  This causes all those containers to call `compute`<br>methods and execute their `layoutChildren`, even though your control may<br>only have changed something that does NOT change its layout bounds (like<br>a color, background, alignment or even things like a cursor shape or<br>position).  These computations are expensive, involving querying of all<br>children of each container to find out their min/pref/max sizes, do<br>content bias calculations, splitting space over each control and many<br>many snapXYZ calls -- all leading to no visual layout change...<br><br>For example, a TextArea or TextField will call requestLayout on every<br>character typed, every cursor movement, and every text content change. <br>None of those affects their bounds (at least, in my experience, these<br>controls are not continuously resizing themselves when I scroll or type<br>things...).  TextField will even change its cursor shape every time its<br>value is updated, even if that value is simply bound to a Slider and the<br>field doesn't have focus at all -- this field will then trigger layout<br>on itself and all its ancestors even if it is in a completely unrelated<br>area of the UI (not close to the slider).<br><br>It seems that in many cases these controls and skins just want their<br>layoutChildren method to be called, as their main layout logic is<br>located there -- duplicating this logic partially for every minor<br>property change that doesn't affect its bounds is error prone, so I can<br>completely follow this reasoning.  However, using requestLayout to get<br>layoutChildren called is very expensive.<br><br>There is a better way: call setNeedsLayout(true) -- this is a protected<br>method that any Node has access to, and basically will only call<br>layoutChildren on your own Node.  It marks all the parent nodes as<br>`DIRTY_BRANCH`, which means that on a layout pass it will traverse down<br>to see which nodes actually needs layout (it won't call layoutChildren<br>for each ancestor, which is a big win).<br><br>Because of its protected nature (and its required parameter which must<br>be true), it is a bit hard to use.  I'm thinking it might be a good idea<br>to introduce a new method here, a request layout call that schedules a<br>Node for layout without forcing all ancestors to do the same. This way<br>Skin and Control designers can clearly see the two options and choose<br>what is required:<br><br>     requestLayout -- my bounds likely have changed (font change,<br>border/padding change, spacing change), so please call compute methods<br>and redo the entire layout<br><br>     requestLocalLayout -- my bounds have not changed (color changes,<br>background changes, content changes within a ScrollPane, cursor changes,<br>cursor position changes, alignment changes)<br><br>What do you think?<br><br>--John<br><br><br><br></div>