A DESCRIPTION OF THE PROBLEM :
JavaFX currently does not provide an official, supported mechanism for embedding native OS-level rendering surfaces (i.e., components backed by their own native window or view such as HWND, NSView, or X11/Wayland surfaces) into the JavaFX scene graph.

This limitation prevents efficient integration of modern native rendering engines and UI toolkits that require ownership of a real native surface, such as Chromium Embedded Framework (CEF), GPU-accelerated media pipelines, and other native visualization or rendering libraries. Existing approaches rely on windowless or off-screen rendering and copying pixel buffers into JavaFX nodes (Canvas/ImageView), which introduces performance bottlenecks, increased latency, and functional limitations (e.g., native dialogs, developer tools, IME, focus handling).

In the absence of a supported API, developers resort to fragile workarounds based on internal Prism APIs, JNI hooks, or runtime bytecode manipulation to synchronize native surfaces with JavaFX layout and lifecycle. These approaches are inherently unstable and version-dependent.

An official API that allows embedding native OS-level surfaces as first-class nodes in a JavaFX Scene—with clearly defined lifecycle, layout, Z-order, focus, and clipping semantics—would eliminate the need for unsupported hacks and significantly improve JavaFX’s interoperability with native technologies. Even a constrained solution (for example, limited transforms or explicit Z-order rules) would be a major step forward and align JavaFX with long-standing capabilities available in other Java UI toolkits.