RFR: 8370498: Improve how Node detects whether a layout property change requires a new layout pass [v4]
John Hendrikx
jhendrikx at openjdk.org
Tue Oct 28 23:14:22 UTC 2025
On Tue, 28 Oct 2025 17:00:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:
> > Also, the CPU cost is still there
>
> that's true, but the cost will be there anyway - but now we are skipping the rendering and removing the flicker. So it's a win-win, as long as the layout converges.
If nothing else happens in the scene, then it would also save a rendering pass yes.
> One example is when the layout must further change based on the current layout pass, such as when the scroll bar appears or disappears.
That should not be the case because of how the layout pass is split into the `compute` calls and the `layoutChildren` calls.
The scene or any layout root needs to know what size things will be, and so will use the `prefWidth` (etc) calls (that delegate to the `compute` calls) before doing any `layoutChildren` call. These calls cascade down as deep as necessary through-out most of the scene graph (even parts not needing layout), and this would be expensive if they weren't also aggressively cached.
The `compute` calls don't need to be a `one call = one result` deal. Often additional calls are done for more complex layouts (like for biased controls where the opposite `compute` call is done first so the related size can be passed to the wanted `compute` axis). And this can also happen for `ScrollPane` which can look at the result of a `compute` call then decide it needs a scroll bar, redo the computation of how much space is available for the content (which may cause the other scroll bar to also be needed). It can then position its children correctly in one pass.
See `ScrollPaneSkin#layoutChildren` code where you can see it do several checks in a row to determine the correct size when scrollbars must appear, all in one pass :)
Also of note is that it always creates and adds the scroll bars, and just keeps them invisible until needed, as creating them on demand would be too late and cause flicker (unless you do this in a prelayout listener).
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1945#issuecomment-3458912490
More information about the openjfx-dev
mailing list