Created attachment 888 [details] Output of java -jar jogamp-fat.jar > jogamp-fat-01.log 2>&1 NewtCanvasJFX canvases always seem to render from the origin the underlying window region. It does not seem to respect placements with a y-offset. (I suspect x-offsets are also a problem, but that does not affect my use case.) When a NewtCanvasJFX is placed as the only child of a Group, the OGL render appears correctly in the screen space. If the NewtCanvasJFX is a second or third child of a VBox, the canvas appears to ignore the offset. It renders from the origin (0, 0) of the underlying region (e.g. Stage). This over-writes the top elements in the VBox, and leaves a large gap between the bottom of the canvas and bottom element of the VBox. --- Based on further research and tracing with the available debug output, I have strong suspicions about the NewtCanvasJFX constructor. That constructor installs listeners for several properties, including size, visibility, and scene change. However, it does not install listeners for layoutX or layoutY. As a consequence, the native window does not get relocated when a containing Node is layed out. If a NewtCanvasJFX is "reparented" to a layed out Node, the canvas will use the y offset of a parent at construction/creation time. But all other changes to layout y are ignored. Since layout is generally very late, parent nodes nearly always have zero as the y-offset. This initial offset for the native window cannot be changed. --- This issues was initially discussed in JogAmp Forum thread https://forum.jogamp.org/Placing-a-NewtCanvasJFX-within-other-JavaFX-layout-elements-tc4043329.html That thread includes some images that demonstrate the problem. --- --- The sample application is based on JGouesse's "JavaFx et JOGL". In the simplest variation (branch base), the NewtCanvas is merely moved from the only child of a Group into the second child of a VBox. The NewtCanvas should not overwrite the first Label in the VBox. The sample is build with the prepackaged jogamp-fat.jar. Probably not important, but the sample app packages the JogAmp library within a Java "Automatic Module". This provides access to the JOGL primitives from a modularized Java application. Source code is available at https://github.com/leeca/JavaFx_JOGL. Other branches demonstrate variations in the problem, mostly based on placing a NewtCanvasJFX withiin a TabPane. With a viable JVM available (Java 17+), the entire application should run from a command shell via $ ./gradlew run
Created attachment 889 [details] Possible repair for NewtCanvasJFX layout problems I've been unable to build this patch, but it seems like a likely cause of the problems.