On Tue, 4 Aug 2026 22:11:21 GMT, Andy Goryachev <[email protected]> wrote:
>> This PR shows how virtual layouts could be implemented, as discussed on the >> mailinglist: >> https://mail.openjdk.org/archives/list/[email protected]/thread/PLNSQ3ZI63AVKEFKNT5GT6WHAD2GYMPC/ >> >> It would work by making new non-Node containers called Layouts which can >> contain a mix of either Nodes or other Layouts. Allowing Layouts to nest >> makes it possible to create a substructure similar to how nesting >> StackPane/HBox/VBox etc works today. An example is a simple control that has >> a graphic with a title and subtitle stacked vertically next to it: >> >> >> +-------------+-----------------------------------------+ >> | | | >> | | Title | >> | | | >> | Graphic +-----------------------------------------+ >> | | | >> | | Subtitle | >> | | | >> +-------------+-----------------------------------------+ >> >> For a control to model this, it would need a VBox containing the Title and >> Subtitle, and an HBox containing the Graphic and the VBox. The two >> containers are heavy-weight Nodes and this incurs sufficiently large memory >> and performance penalties that most standard JavaFX controls will opt to >> instead roll their own layout code to avoid paying the cost for these. >> >> With virtual layouts, the control could make use of non-Node containers. The >> control would add its three children (Graphic, Title and Subtitle) as direct >> children for display in the scene graph, but would offload their positioning >> to a virtual layout. This roughly looks like this: >> >> >> public class TitledGraphic extends Region { >> private final HBoxLayout root; >> >> public TitledGraphic(Node graphic, String titleText, String >> subtitleText) { >> // Flat scene graph: >> getChildren().addAll(graphic, title, subtitle); >> >> // Create virtual layout: >> root = HBoxLayout.of(graphic, VBoxLayout.of(title, subtitle)); >> } >> >> @Override >> protected void layoutChildren() { >> root.resizeRelocate(0, 0, getWidth(), getHeight()); >> } >> >> @Override protected double computeMinWidth(double height) { return >> root.minWidth(height); } >> @Override protected double computeMinHeight(double width) { return >> root.minHeight(width); }... > > modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 522: > >> 520: >> 521: @Override >> 522: public RenderScaleContext >> getRenderScaleContext(Scene scene) { > > minor: would it make sense to combine `Snapper` and `RenderScaleContext` -> > `RenderContext`? I think it is best not to (I went back and forth a lot on this while building it). The reason I think we're better off this way is that I feel that providing a Layout with render scale information is a better fit than providing it with a way it should adjust its calculations (layouts should be able to determine themselves how they want to deal with device pixels). Where render scale is a simple fact of the rendering surface (ratio of logical to device pixels), snapper is just a potential way to deal with that. I also think (when this becomes public API) that `RenderScaleContext` or `RenderScale` is a nicer API to have users deal with than `Snapper`. `Snapper` can still become public API if you feel that we should provide this to Layout creators so they don't have to roll their own -- it is just not required for a minimal implementation. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2241#discussion_r3717664363
