On Tue, 4 Aug 2026 20:59:32 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/layout/Measurable.java > line 202: > >> 200: * The 'alphabetic' (or 'roman') baseline offset from the element's >> top boundary >> 201: * that should be used when this element is being vertically >> aligned by baseline with >> 202: * other elements. By default this returns {@link >> #BASELINE_OFFSET_SAME_AS_HEIGHT} for resizable elements > > -> "By default, ..." Yeah, it was poorly worded in the original. Can adjust :) > modules/javafx.graphics/src/main/java/javafx/scene/layout/RenderScaleContext.java > line 37: > >> 35: * ratio of device pixels to logical pixels on the Y axis >> 36: */ >> 37: public record RenderScaleContext(double snapScaleX, double snapScaleY) { > > minor: just `RenderScale` maybe? or do you plan to add more context? No, no further plans. I see this type as a way to provide facts about the rendering surface that are relevant for layouts. If we ever did want to extend it with additional details, the name would be better more generalized to allow for that later, so instead of `RenderScale` or `RenderScaleContext` it could be `RenderContext`, allowing for future extension. However, I did some exploration here, and I don't see anything we could possibly add here that are "facts" about the display that would interest layouts. I investigated: touch screens, screen rotations, LCD pixel order, etc, none of which I think is something layouts need or should know about. So, I'm happy to keep its name scale specific (`RenderScale` or `RenderScaleContext`) but also fine to make it more generic (just in case). ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2241#discussion_r3717706131 PR Review Comment: https://git.openjdk.org/jfx/pull/2241#discussion_r3717702949
